Sensitive data

Question: Does the function log a password, token, key or personal data, or send internal error details to a remote client? Does an error handler send clients more than the program’s own messages and codes?

• Runs: when selected: --rule sensitive-data, --rule security or --rule all · Fails the check by default: no
• Right on projects JevGate was never tuned on: reviews 42% (10 of 24), considers 0 of 5 (how it is measured)
• Right on the projects it was tuned on: reviews 64% (41 of 64), considers 12 of 15
• Looks at: application functions with calls, built text or field assignments, and PHP page scripts
• Evidence unit: one function’s source or a PHP file’s top-level code; then its statements as sites and the message of each error it creates; one question per registered web error handler
• Acceptable: Logging record ids and messages; generic error responses with details kept in server logs
• Names: security/sensitive-data, sensitive-data, sensitive_data · Version: 9

When a finding is right

A finding says a function writes a password, token, key or personal data to a log, or sends internal error details to a remote client. It is right when a secret reaches a log, or when the text of a database or library error reaches someone outside the service, such as an API that returns an exception’s message to its users. It is wrong when only the operator or the person running the program reads the output, when the error text is a message the program wrote itself, or when the caller is the project’s own service. The commonest causes of findings labeled wrong or debatable were output only a local user reads, messages the program wrote itself, and callers that are the project’s own services.

An error-detail finding is asked who reads the error text, with the opening of the root README, and a log line that runs only when an operator turns on a setting meant for logging those values is a note.

Findings it got wrong

Labeled wrong by reading the code, on open-source projects the rules were tuned on.

LinkAce: viewBackupCodes

• Where: app/Console/Commands/ViewRecoveryCodesCommand.php:33 in Kovah/LinkAce at d682166.
• Finding (review): ViewRecoveryCodesCommand::viewBackupCodes writes a password, token, key or personal data to a log.
• Why it was wrong: 2fa:view-recovery-codes is an admin command whose purpose is to show a locked-out user’s recovery codes. $this->line($code) prints them to the operator’s terminal, not to a log; printing an identifier instead would defeat the command.
• Since: cleared in 0.21.0, which tells values a command-line tool shows its operator on purpose from what a log keeps (changelog).

WTF Dial: handleDialIndex

• Where: http/dial.go:66 in benbjohnson/wtf at 05bc90c.
• Finding (consider): Server::handleDialIndex puts the text of a library or database error into an error message, which likely reaches a remote client.
• Why it was wrong: The error goes to the project’s central Error helper, which sends the client a message the program wrote (such as “Dial not found.”) or “Internal error.” for any other error, and logs and reports internal errors. No SQLite error text reaches the client.
• Since: a note since 0.20.0: such a finding, in a function whose error message carries another error’s text, is a note, since a central handler often replaces that text; 1 of 28 such considers labeled was right (changelog).

Wild Workouts: MakeHourAvailable

• Where: internal/trainer/ports/grpc.go:29 in ThreeDotsLabs/wild-workouts-go-ddd-example at 8ecfcdf.
• Finding (review): GrpcServer::MakeHourAvailable sends internal error details to a remote client.
• Why it was wrong: The gRPC caller is the project’s own trainings service: the gRPC services accept only authenticated invokers, and the public HTTP port turns such errors into a generic “Internal server error”. The text never reaches an outside party.
• Since: not addressed; reported the same way from 0.19.0 through 0.25.0. Errors returned between a project’s own services are a known weak spot of this rule.