A SQL injection attack that may be executed against the Oracle database was recently documented by database security researcher David Litchfield.
The attack requires that the attacker to have been granted a database account, making it more likely that this kind of attack will occur in the research lab than "in the normal sense," Litchfield said of his finding.
But Oracle's manager for security in its Global Technology Unit, Erich Maurice, Monday said in a blog post that Litchfield's exploit demonstrates how "a lateral SQL injection" attack can be placed by an outsider in a database application using Oracle's extended PL/SQL query language, and developers of database applications should be aware of the potential for such attacks.
SQL injection occurs when an intruder is able to put a SQL statement into a user input form where the application expects a name, address, date, or some other standard information. SQL injection succeeds when there's no validation of the entry. That is, there's no automatic check that the entry follows an expected format or meets length and alphanumeric character limits. Such validation would be able to detect a SQL statement in place of a date and halt execution of the program.
Lateral injection is indirect injection -- putting the PL/SQL statement someplace where the application will find it when it's looking for something else, then successfully directing the application to that statement.
Litchfield is a researcher with the United Kingdom's Next Generation Security Software. On April 25, he published a paper showing how an exploit could be injected via "a little bit of trickery" instead of directly through an intentional, fraudulent user entry. It requires a PL/SQL procedure that looks for a date variable by calling a system function.
Litchfield demonstrated the effect of leaving out a quote mark that would normally terminate a PL/SQL command. As the system looked for the right way to terminate the quotes marks, it called a previously named system function that had a PL/SQL command buried in it. It then injected that function as the correct replacement for the unterminated command and the malicious code had found its execution path.
"While some may consider the topic of Lateral SQL Injections as mostly academic, I think this paper has the merit of further raising the awareness of database administrators and programmers to SQL Injections," he wrote in a blog post on Monday.
To minimize the risk of a SQL injection attack, advised Maurice, reduce the user inputs to only those absolutely essential. Doing so "reduces the attack surface" of the application, he noted. Following good coding procedure by binding a variable to the data type and database section that is supposed to define it is another preventative measure, he said.
