Mark java.sql.Statement enquoteIdentifer, enquoteLiteral, and enquoteNCharLiteral SQL_INJECTION_SAFE

[jim-bentler]

There is no built-in support for java.sql.Statement enquoteIdentifer, enquoteLiteral, or enquoteNCharLiteral. They should be defined as SQL_INJECTION_SAFE:

java/sql/Statement.enquoteLiteral(Ljava/lang/String;)Ljava/lang/String;:0|+SQL_INJECTION_SAFE
java/sql/Statement.enquoteIdentifier(Ljava/lang/String;Z)Ljava/lang/String;:1|+SQL_INJECTION_SAFE
java/sql/Statement.enquoteNCharLiteral(Ljava/lang/String;)Ljava/lang/String;:0|+SQL_INJECTION_SAFE

[jackoske]

why SQL_INJECTION_SAFE?
It's highlighting the risk of SQL injection due to the lack of built-in escaping mechanisms.
The annotations don't magically make custom escaping methods safe.
consider switching to Prepared Statements as this is the recommended and most secure approach. Prepared statements separate data from the SQL query, and the database handles escaping, mitigating injection risks.

[jimbentler]

I'm quite aware of all that.

The columns involved in the query are dynamic. The escape methods are the best that can be done.

[jimbentler]

That said, these also aren't custom escaping methods. They are escaping methods implemented either by the JDBC driver or by Java (if the driver hasn't overridden the default implementation).

We are using PreparedStatements to the degree allowed. So values are always supplied via bind variables, but column names are escaped using the appropriate method.