Self-Inflicted SQL Injection – don’t quote me !

After my recent post about escaping quotes in SQL scripts, I was surprised and delighted to receive a mail from Alexander Kornbrust, CEO of Red Database Security.
In it, he said he’d read the post and pointed out that the code therin was vulnerable to SQL-Injection.
I was fortunate enough to work with Alex, before he went off to become famous, so I know that he’s a bona fide expert in all things Oracle, especially security. Even so, I was initially puzzled by his assertion.
After all, the code I’d posted was an example where the code is held in a script and NOT in the database so wouldn’t be vulnerable to being executed by someone who’d hacked into the database itself. After all, SQL Injection happens interactively doesn’t it ? The hacker needs to be probing for weaknesses via a web front-end or similar. Don’t they have to be physically typing stuff in somewhere for this to work ? Er….apparently not.
Having asked around a number of Oracle developers, this would seem to be a widely held misconception. In terms of SQL Injection attacks, we’re all familiar with the classic HTML login form which POSTS to some mid-tier script or program which in turn, simply concatenates the username and password strings supplied by the user into a query then fires it off unthinkingly at the database. But how can you be attacked when the attacker isn’t even around at the time ?

Before I go any further, I think it’s only prudent to state the usual caveats here :

1) As with anything I post on this blog, this is code I’ve tested and works for me on my environment. I don’t make any garuantees that it’ll work the same anywhere else and I trust that anyone as discerning and intelligent, as you obviously are dear reader (as your reading this blog), would do anything as silly as applying this code to a critical environment without testing it out themselves first – somewhere safe .

2) What follows is an example of how an Oracle database can be vulnerable to such an attack and how to take steps to guard against it. It is not intended for use for nefarious purposes.

I should also say at this point that these examples were tested by me on Oracle XE Release 10.2.0.1.0 so there’s no garuantee that it would work the same on any other Oracle RDBMS version.

To continue reading, please read here
This article taken from The Anti-Kyte