I have a class which extends java.sql.PreparedStatement - the extended class simply ensures all ResultSet accessors are null safe. That being said, SonarCloud identifies this as a problem when we pass the SQL statement to be prepared into a PreparedStatement - the vulnerability statement is Refactor this code to not construct SQL queries directly from tainted user-controlled data. That being said, this is something we are aware as not being a security threat and we would like to ignore this issue.
I have tried placing @SuppressWarnings({"javasecurity:S3649", "squid:S2077"}) at the class level, method level, and at the statement level. None of these methods worked.
My question is this. Does SonarCloud behave the same when applying SuppressWarnings annotations in Java or this is something SonarCloud does not support?
Is there a way to tell SonarCloud to ignore these method calls from being flagged? We have hundreds of them and having to go through the UI to mitigate each issue is something we are trying to avoid.
Before talking about how to suppress issues I would like to understand why you consider the issues raised as not expected. We may have ways to improve the rule and not raise these issues at all so that you don’t need to review / close them manually.
Can you share a reproducer and a screenshot of one of the issues (it would be great to see the call graph/nodes)?
Thank you so much for your reply.
Here is a picture of one of the incidents in this case. From the picture we can see the method prepare being flagged as potentially tainted input. The only thing prepare does is to check if that statement exists in a the cache; if it does, it returns it, otherwise it adds it to the cache and returns the new statement. As mentioned earlier `PreparedSafeNull is an extended class to provide null safe ResultSet accessors.
After deeper investigations performed on the source code of @springzen, I can confirm the issues raised by the rule S3649 should be closed as false-positives. The issues are wrongly raised because SonarCloud considers “Date” parameters of @RequestParam methods as sources of potential attacks whereas it can’t be the case.
Here is the (private) ticket we gonna use to fix that behaviour: SONARSEC-1252: [Java] “@RequestParam” should not consider “Date” objects as a SOURCE
Instead of using the @SuppressWarnings annotation to remove these issues, you should use the features coming with SonarCloud to mark issues as false-positives. See:
