Preventing Oracle SQL injections in Java when you need to use variable table names

SonarQube Server / Community Build
,
1

Must-share information (formatted with Markdown):

    • Sonarqube 9.4 (build 54424)
  • how is SonarQube deployed: In a pipeline
  • Query an Oracle database connection with a variable table name but avoiding SQL injections.

Sonaqube won’t accept this (even if I know it’s safe because of the Pattern verification):

[code redacted]

Note: patternMinimumChaine = Pattern.compile("^[a-zA-Z][a-zA-Z0-9_]*$")

PreparedStatement doesn’t accept the ? in the table name part.

So, how can I make SonarQube happy using a variable which has the table name?

Thanks!

3

Hi,

Welcome to the community!

What rule is raising an issue on your code? Does the rule description not adequately explain why an issue is raised?

:warning: Also, make sure you upgrade to SonarQube v9.9 LTS soon, not only to benefit from our Best LTS Ever™, but because soon we will systematically ask users to upgrade when they ask questions about earlier versions of SonarQube, which are now considered unsupported. :smiley:

 
Ann

4

Hi,

I understand the explanation, but don’t agree because I do a data entry validation before, so this won’t happen.

How can I find out the rule in the GUI? This is what I see:

This use of java/sql/Connection.prepareStatement(Ljava/lang/String;)Ljava/sql/PreparedStatement; can be vulnerable to SQL injection (with JDBC)

URL: https://our.sonarqube.instance/project/issues?id=myProjectId&open=AYaevAp2pYeT21WE7HwE&resolved=false&types=VULNERABILITY

What if I choose the option “Resolve as false positive”?

5

Hi,

To get the rule ID, use the “Why is this an issue” link. It will look something like java:s###

Marking the issue as Won’t Fix is certainly an option. Marking is False Positive is an option too if you truly believe the code has been incorrectly analyzed. I wonder, though, if the issue will still be raised when you upgrade to 9.9…

 
Ann