By Charles Babcock
April 29, 2008
A SQL injection attack that may be executed against the Oracle (NSDQ:
ORCL) database was recently documented by database security researcher
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
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
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
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.
Subscribe to the InfoSec News RSS Feed