Please continue writing such articles to help your fellow professionals.

I hope that you’ll still continue writting about that, because is a issue than there’re not so much information about how can we used it.

Good for you! and thank u

Cheers,

Ken van Wyk

@Ben – thanks for the great catch – updated the code referencing your comment.

The example you use for SQL injection is one I see a lot:
Password: ‘ OR ’1 = 1
…making the resulting query:
…AND password = ” OR ’1 = 1′

But this is NOT a correct statement, the ’1 = 1′ might be “true” for some databases but not necessarily always. For example, this will NOT work on Microsoft SQL Server.

On a side note, I have no idea where this strange wrong injection string is coming from but have even found it in scientific papers

A correct injection string would, for example, be:
Password: ‘ OR ’1′ = ’1
…making the resulting query:
…AND password = ” OR ’1′ = ’1′

…which is a correct statement, no matter which database is used.

—
Nonetheless, your example shows that some databases accept strange things as “true”, which is a royal PITA when trying to filter input and shows that blacklisting is futile (think of signature-based IDSs, IPSs, WAFs,…).

For example, MySQL (and I guess this was used for “finding” the wrong injection string) accepts, probably among others, the following values as “true”:

any positive or negative number except 0:
where 1
where 2
where -34

any string starting with a positive or negative number except 0:
where ’1′
where ’1 = 1′ — looks familiar?
where ’2′
where ‘-34something’

Kind regards,
Ben

However, ESAPI does provide database codecs because there are many situations when remediation is more easily done with an escaping method. There are also certain types of queries for which using PreparedStatement will cause significant performance problems (so be careful with those recommendations folks). Also, in some environments parameterized queries may not be available, so an escaping option is important.

I looked into this pretty deeply back in 2002/2003 (http://lists.virus.org/webappsec-0301/msg00003.html). The upshot is that the JDBC spec doesn’t explicitly require that PreparedStatement prevents injection, so there’s certainly some risk in relying exclusively on them. That’s why input validation, escaping, and access reference maps are important security controls. And of course there are degenerate cases like PreparedStatement.executeQuery( “exec ?” );

I looked into the MySQL driver back then and decided that it wasn’t obviously vulnerable. I even took a swing at reversing the Oracle JDBC drivers, but I didn’t get far enough to give anyone any confidence. This is exactly the lack of visibility that makes it so difficult to make progress in application security.