False positive tainted input (JavaSecurity:S5145)

Versions used

  • SonarCloud : current
  • Maven Sonar plugin : latest

Issue

Sonar marks a logging statement with vulnerability javasecurity:S5145 (Logging should not be vulnerable to injection attacks) but input is either validated or cannot be invalid.

From the location of the logging statement, the argument is tracked back all the way from a processor class to the Spring MVC Controller where the input originates.
However, the vulnerability is on a request parameter which has an Enum type. Spring MVC automatically converts the String input to a valid enum instance, so it is not possible for this request parameter to have an unknown, or invalid, value.

Also, JSR303 annotations to validate the input seem also not taken into account. I specifically created a custom annotation to validate an input string cannot have any line breaks (\n, \r, \t).
I can image the analyser could not validate this code, but it is also not possible to somehow ‘untaint’ a value.
Annotating the MVC method with @SuppressWarnings(“javasecurity:S5145”) also still gives the same vulnerability in the processor class.

Lastly, I was also not able to mark this vulnerability as ‘resolve as false positive’ but maybe that’s a authorization issue in our SonarCloud setup.

Hi @Joost_den_Boer ! Thanks for this feedback.
There is a lot in your post, let’s decompose :

  • If I understand correctly you are in fact encountering two false positive due to some sources that cannot be user controlled.
    Could you share just the code snippet of those sources ?
    So the request parameter which is an Enum (method declaration with its parameter and annotation (and the corresponding types)) and the other one which is about a custom annotation validating some input.

  • The support of SuppressWarnings is indeed not supported for rules of javasecurity repository. I do understand the expectation for this to work but to be honest I am unsure if we really want to go that route and support it.

  • the resolve as FP feature is most probably due to your sonarcloud organization setup indeed.