Potential fix for code scanning alert no. 38: Query built from user-controlled sources

[davewichers]

Potential fix for https://github.com/aspectsecurity/TestCodeQL/security/code-scanning/38

In general, the problem is solved by using parameterized queries (prepared statements) instead of building SQL with string concatenation. User input should be bound as parameters so the JDBC driver sends data values separately from the SQL code, preventing injection.

For this specific code, the best fix without changing observable functionality is to (1) change the SQL string to use a placeholder (?) for the password instead of concatenating param, and (2) call a parameterized Spring JDBC method that binds param to that placeholder. JdbcTemplate already supports parameter binding, so we can reuse it rather than writing custom logic. Since the static helper DatabaseHelper.JDBCtemplate is used directly, we only need to adjust the sql definition and the call to queryForRowSet at lines 47–50.

Concretely in src/main/java/org/owasp/benchmark/testcode/Benchmark00026.java:

• Replace line 47’s concatenated string with a parameterized query:
  String sql = "SELECT * from USERS where USERNAME='foo' and PASSWORD=?";
• Replace line 50’s call with one that supplies parameters:
  queryForRowSet(sql, param);

No new imports are required, because we still reference DatabaseHelper.JDBCtemplate and SqlRowSet by fully qualified name.

---

Suggested fixes powered by Copilot Autofix. Review carefully before merging.