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, etc. Injection flaws are easy to discover when examining code.
Oracle Banking Trade Finance uses Oracle database and it has adequate inbuilt techniques
to prevent SQL injections as underlined below:-
- Use of prepared statements (parameterized queries) — Oracle Banking Trade Finance uses PreparedStatement 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. Oracle Banking Trade Finance uses safe Java stored procedures calls.
- In addition to the above, wherever dynamic queries exist, Oracle Banking Trade Finance uses adequate defence to sanitize the untrusted 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’s 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’s no guarantee that it will prevent all SQL Injection in all situations.
Oracle Banking Trade Finance uses context specific escaping. It has a StringEscapeUtils.java file, where context specific escaping is handled.