2.1 Injection
Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code. They are often found in SQL, LDAP, Xpath, or SQL queries; OS commands; XML parsers, SMTP Headers, program arguments, and so on. Injection flaws are easy to discover when examining code.
- Use of prepared statements (parameterized queries) - Application uses Prepared Statement with bind variables to construct and execute SQL statements in JAVA.
- Use of Stored procedures - Stored procedures have the same effect as the
use of prepared statements when implemented safely. Implemented
safely means the stored procedure does not include any unsafe
dynamic SQL generation. Application uses safe Java stored procedures calls.
In addition to the above, wherever dynamic queries exist, application uses adequate defence to sanitize the un-trusted input. The use of DBMS_ASSERT.SIMPLE_SQL_NAME and the use of bind variables justify the fact.
- Escaping all user supplied input - This third technique is to escape user
input before putting it in a query. If it is a concern that rewriting the
dynamic queries as prepared statements or stored procedures might break the
application or adversely affect performance, then this might be the best
approach for the purpose. However, this methodology is frail compared to using
parameterized queries and there is no guarantee that it prevents all SQL
Injection in all situations.
APPLICATION uses context specific escaping. It has a String Escape Utils.java file, where context specific escaping is handled.