Top 15 Free SQL Injection Scanners

J.R writes "The Security-Hacks blog has a summary of the 15 best free SQL Injection scanners, with links to download and a little information about each one. The list is intended asan aid for both web application developers and professional security auditors."

Alternatives

[stonecypher]

Of course, security through obscurity is badbear.

That said, there are times - and this is one of them - that I'm glad my recently most common database isn't fundamentally SQL, or anything well-recognized. It also helps that (I believe) mnesia is immune to injection [erlang.org], given that its queries are never textual, but rather always functional, and given that data are always presented as arguments. Every route to injection I'm aware of just doesn't make sense in context (though if someone knows a way attack Mnesia, I'd love to hear about it.)

Sure, there are times at which SQL is a major win over mnemosyne, but they're not common. Sure, it's nice to have a database be ready for you at any host, instead of having to take the time to find a good host who lets you run stuff. But when it comes down to it, the atypical performance characteristics of Erlang (especially since I write multiplayer games, for which massive concurrency is win) and the ridiculous speed of Mnesia make me miss SQL less every day.

'Course, client stuff still needs to work on MySQL. :(

what exactly is an sql injection?

[siddesu]

i hear people talking about them from time to time, but i still can't figure out how they appear.
ain't there query parameters in practically all database access APIs?

Re:Why is this needed at all?

[vr]

If you just make sure you always use prepared SQL statements with positional arguments, you will never have any problems with SQL injection.

Actually, that is not true, as it ignores one problem: bugs in the database drivers. Seriously, there have been bugs in database drivers that have enabled SQL injection... I specifically remember a bug in the PostgreSQL JDBC driver [postgresql.org] a while back.

I also remember seeing a JDBC driver that simply inserted arguments into the string containing the SQL statement, although I fail to remember exactly which driver that was. This was a while back, mind you, so hopefully errors like that have been fixed. :)

Until I encountered these things, I believed that positional arguments was the silver bullet. The point here is that positional arguements in itself is no guarantee, it is only a part of an API. At some point you have to trust the developers of the database driver and the database itself, of course...

Re:Why is this needed at all?

[AnObfuscator]

If you just make sure you always use prepared SQL statements with positional arguments, you will never have any problems with SQL injection.

Well, prepared statements have their own shortcomings -- they're not the magic bullet to solve all our DB issues. Some would have you believe they are, but don't be fooled.

I suppose the over-use of PHP (which for a long time didn't even support prepared statements (does it even do it today?)) combined with stupid users that created the current situation.

IIRC, when PHP 4's mysql drivers were written, MySQL did not support prepared statements. However, PHP 5's mysqli driver does support MySQL prepared statements. Also, PHP 5's PDO system offers a unified DB API with prepared statements.