False positive: Java: stack-trace-exposure

[RobbingDaHood]

Description of the false positive

The 'java/stack-trace-exposure'-rule triggers on the following sample java code line:

ResponseEntity.status(HttpStatus.NOT_FOUND).body(e.getMessage());

The message is usually not exposing a stack trace but a custom message in java: Contrary to 'toString()'

My only reason to pause is that this check seems so deliberate: I could not find any documentation on why this check were added or why it should be considered a error. So if I am wrong in this being a false positive, could we at least add better documentation on why it is a true positive? And consider moving the check out of 'java/stack-trace-exposure'-rule?

Code samples or links to source code

    import org.springframework.http.ResponseEntity;
    import org.springframework.http.HttpStatus;

...

    public void showFalsePositive() {
        RuntimeException runtimeException = new RuntimeException();
        ResponseEntity.status(HttpStatus.NOT_FOUND).body(runtimeException.getMessage());
    }

Link to query

https://github.com/github/codeql/blob/main/java/ql/src/Security/CWE/CWE-209/StackTraceExposure.ql

Remove:

or
getMessageFlowsExternally(DataFlow::exprNode(externalExpr), DataFlow::exprNode(errorInformation))

And then that removes the only use of getMessageFlowsExternally left, so that should also be cleaned up.

[Michael B. Gale]

Thanks for asking this question, @RobbingDaHood. If e.getMessage() doesn't print a stack trace here, then this is obviously a false positive. However, it's possible that the query assumes that there may be cases where getMessage() will show the stack trace for some types of exceptions. I am checking with the relevant team to see what their reasoning for this was when they implemented it.

That being said, fixing false positives isn't currently a product priority, so I can't make any promises about when this may get looked at.

[RobbingDaHood]

If this is confirmed to be a false positive and I can get #17061 fixed, then I would not mind making a PR on removing this :)

PS: I do not seem to be able to assign myself to issues, is that something that you could fix? @mbg

[RobbingDaHood]

Looks like a duplicate of: #16867

[RobbingDaHood]

I found the documentation: java/ql/src/Security/CWE/CWE-209/StackTraceExposure.qhelp

And it links to https://wiki.sei.cmu.edu/confluence/display/java/ERR01-J.+Do+not+allow+exceptions+to+expose+sensitive+information that goes way more into detail.

What I get from the read is:

1. Returning the .getMessage() is not exposing a stack trace
2. Returning the .getMessage() can still expose sensitive information
3. The linked resource suggests always mapping exceptions to texts that does not reveal any sensitive information: Both when returning data to the caller and when logging information.
4. Personally I think that seems very aggressive: This information is critical in debugging production issues: But who am I to question the "SEI CERT Oracle Coding Standard for Java" :D

java/ql/src/Security/CWE/CWE-209/StackTraceExposure.qhelp were missing a link to https://www.veracode.com/security/dotnet/cwe-209 even though the naming of the folder indicates a relation to this definition. What I get from that read is:

1. That they agree on the above.
2. That they allow logging sensitive information in contrast to the above.
   1. Personally I think that makes more sense, even though you have to be aware of how long you store logs or "how" sensitive the information is: But enough information to actually debug the program.

In the end then this issue is reduced from a false positive to a wrongly named query and likely with a difference severity.

I have no problem implementing that, just to get my feet wet on this project :)

To clarify:

1. Remove the query from java/ql/src/Security/CWE/CWE-209/StackTraceExposure.ql as suggested in the original post.
2. Add a new query in java/ql/src/experimental/Security/CWE/CWE-209/SensitiveDataExposureThroughErrorMessage.ql,
   1. Add https://www.veracode.com/security/dotnet/cwe-209 to the java/ql/src/experimental/Security/CWE/CWE-209/SensitiveDataExposureThroughErrorMessage.qhelp and some description.

[Michael B. Gale]

@RobbingDaHood I see you have opened a PR to deal with this issue, so it's probably best for the Java team to review that and decide how to progress with it there.

java/ql/src/Security/CWE/CWE-209/StackTraceExposure.qhelp were missing a link to https://www.veracode.com/security/dotnet/cwe-209 even though the naming of the folder indicates a relation to this definition.

I just wanted to note here that, if you aren't aware, CWE stands for Common Weakness Enumeration and is a system for cataloguing vulnerabilities. For example, you can find more general information about CWE-209 at https://cwe.mitre.org/data/definitions/209.html.

[RobbingDaHood]

@RobbingDaHood I see you have opened a PR to deal with this issue, so it's probably best for the Java team to review that and decide how to progress with it there.

java/ql/src/Security/CWE/CWE-209/StackTraceExposure.qhelp were missing a link to https://www.veracode.com/security/dotnet/cwe-209 even though the naming of the folder indicates a relation to this definition.

I just wanted to note here that, if you aren't aware, CWE stands for Common Weakness Enumeration and is a system for cataloguing vulnerabilities. For example, you can find more general information about CWE-209 at https://cwe.mitre.org/data/definitions/209.html.

Thx, that is great info. I were not aware :)

[RobbingDaHood]

@mbg do you agree this also solved #16867 ?