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.
I see that this issue is quite old with no recent activity. But I am having the same issue as OP.
Here is a code snippet that will reproduce the problem:
import javax.validation.constraints.Pattern;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.PutMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class TestController {
private static final Logger LOG = LoggerFactory.getLogger(TestController.class);
@PutMapping("log/pattern-validated/{enumValue}")
public void logValidatedEnum(@PathVariable final MyValues enumValue) {
LOG.info("Enum is already sanitized to only two possible values: {}", enumValue);
}
@PutMapping("log/enum-validated/{value}")
public void logPatternValidated(@PathVariable @Pattern(regexp = "^[A-Za-z0-9]+$") final String value) {
LOG.info("Value is pattern validated: {}", value);
}
public enum MyValues {
ABC, DEF
}
}
for your first example with enum, it’s fixed since SonarQube 8.5, I recommend updating your SonarQube instance, if it doesn’t solve this false positive, let us know.
for your second example with Pattern, I just created a ticket to not raise anymore when the user-controlled input is validated with a regex, I will inform you when it’s released.