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

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):

if (ValidateurParams.patternMinimumChaine.matcher(nomTable).find())
	preparedStatement = connection.prepareStatement(
		String.format("select NUM_INSN, NUM_CAIS, NUM_FOLI, NUM_FOLI_MASQ, MASQ_DIGIT from %s", 
			nomTable));
else
	throw new IllegalArgumentException("NomTable n'est pas correct: " + nomTable);

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!

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

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://sonar.lc.az.nuagesdesjardins.com/project/issues?id=com.desjardins.caaseadm.tdm.fdm%3ADesjFormatFPE&open=AYaevAp2pYeT21WE7HwE&resolved=false&types=VULNERABILITY

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

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