Refactored to use parameterized SQL APIs

[pixee-standardchartered]

This change refactors SQL statements to be parameterized, rather than built by hand.

Without parameterization, developers must remember to escape inputs using the rules for that database. It's usually buggy, at the least -- and sometimes vulnerable.

Our changes look something like this:

- Statement stmt = connection.createStatement();
- ResultSet rs = stmt.executeQuery("SELECT * FROM users WHERE name = '" + user + "'");
+ PreparedStatement stmt = connection.prepareStatement("SELECT * FROM users WHERE name = ?");
+ stmt.setString(1, user);
+ ResultSet rs = stmt.executeQuery();

More reading

• https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
• https://cwe.mitre.org/data/definitions/89.html

I have additional improvements ready for this repo! If you want to see them, leave the comment:

@pixeebot next

... and I will open a new PR right away!

🧚🤖 Powered by Pixeebot

Feedback | Community | Docs | Codemod ID: pixee:java/sql-parameterizer

[sonarqubecloud]

Quality Gate failed

Failed conditions
E Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[pixee-standardchartered]

I'm confident in this change, but I'm not a maintainer of this project. Do you see any reason not to merge it?

If this change was not helpful, or you have suggestions for improvements, please let me know!

[pixee-standardchartered]

Some folks find the idea that a hacker could exploit their SQL to exfiltrate data fanciful. It's unfortunately not as difficult as you might think. It's consistently in the OWASP Top 10 in one form or another for a good reason.

Attackers don't need your schema or understand your query structure to terminate the existing query and run SQL functions like xp_cmdshell() to run a new system process and give themselves shell access.

Attackers can also can also introduce sleep() statements in combination with queries to your DB metadata in order to enumerate your schema remotely and make exfiltration of your customer data easy.

Attackers also don't really need to know how to do any of these things, because there are great automated tools that do all these things for them. The risk is real, as many real-life companies have found out the hard way.

If there are other concerns about this change, I'd love to hear about them!

[pixee-standardchartered]

This change may not be a priority right now, so I'll close it. If there was something I could have done better, please let me know!

You can also customize me to make sure I'm working with you in the way you want.