Hi, this is Eric Maurice again.
A number of publications recently reported about a new way to hack Oracle databases. These articles were in fact referring to a recently published paper by David Litchfield, titled Lateral SQL Injection: A New Class of Vulnerability in Oracle.
SQL Injections are a very well known class of attacks, which can affect virtually any relational databases when no or insufficient input validation has been implemented.
In simple terms, SQL Injection attacks are designed to leverage improper coding of database-powered applications that, in the absence of proper input validation, allow a malicious attacker to insert string input to an application. In such scenario, an attacker can "inject" or pass on harmful SQL commands, which will then be executed by the back-end database. The consequences of successful SQL Injections can be severe: an attacker could gain access to sensitive data, manipulate database information, and in some instances, change the structure of the database, deny legitimate access to it, or grant unauthorized privileges to himself or to others. Web applications are particularly at risk because -- exposed to the Internet -- they often allow an attacker to perpetrate SQL injection attacks without being authenticated to the targeted database or application.
An important aspect of Oracle Software Security Assurance is sharing security information and recommended practices with customers so that they can optimize their security posture. We recently posted a SQL Injection tutorial online that demonstrates how to properly implement input validation controls and prevent this kind of attacks.
In his paper, David explains that in certain circumstances, SQL Injections can also take place in procedures that are not intended to take user input. Note however, that in such a scenario, setting up the attack requires that the attacker had been previously granted a database account with necessary privileges. David concludes that it is doubtful that this kind of attacks becomes:exploitable in the normal sense.
While some may consider the topic of Lateral SQL Injections as mostly academic, and relevant only for the security researchers community, I think this paper has the merit of further raising the awareness of database administrators and programmers to SQL Injections. SANS and others have flagged this class of attacks as a primary threat for database-driven sites and applications. In my opinion, proper input validation constitutes a required security practice that needs to be extended to all functions and procedures, whether they are expected or not to take user input. Furthermore, as expressed in the SQL Injection training and in the Oracle documentation, bind variables should be used as much as possible.
As discussed above, SQL injection happens when a dynamic SQL statement is constructed from user input. In the case of the attack discussed in David's paper, the dynamic SQL statement is being constructed from data stored in the database. The values are then being converted into character strings based on a template provided by the system. It is this template, as opposed to the stored value, that controls what will be injected.
When bind variables are properly used, the bind variable name is physically part of the SQL statement, but this bind variable is used as a reference to the rendered value. As a result, the rendered value is never interpreted directly as part of the SQL statement; therefore no SQL Injection can take place.
In some instances, like DDL operations where a database object needs to be constructed, Oracle administrators do not have the option of using a bind variable. In this instance, the DBMS_ASSERT package should be used to correctly handle the rendered value, either ENQUOTE_LITERAL when it is going to be used as a literal or ENQUOTE_NAME when it is going to be used as the name of a SQL object.
For more information, see the online tutorial Defending Against SQL Injection Attacks. Information on Oracle Software Security Assurance is available on Oracle.com.
