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."

Comments

Why is this needed at all?

[Anonymous Coward]

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

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.

Re:Why is this needed at all?

[mabinogi]

It's the completely wrong answer to the problem though, as it still promotes the idea of using SQL built by string concatenation.
The result being that SQL injection is only one forgotten function call away.

Re:Why is this needed at all?

[hclyff]

Every language allows you to write libraries which do things properly. The language is not a limiting factor here. PHP did not for a long time. And no, I don't believe that "magic quotes" allows you to write secure code properly. Any framework which relies on string concatenation for building an SQL command is inviting insecure code, because the programmer has to *actively* seek to fix injection problems. There is statistical certainty he will overlook something sooner or later. Coupled with the fact that PHP4 was (is?) prevalent compared to PHP5/6 for a long time, it just might be the single most contributing factor to why are SQL injections so common.

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 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?

[ceswiedler]

Huh? Do you prepare your statements every time you execute them? That would certainly be slower, but if you prepare the statement once and execute it many times, the local overhead becomes minimal and the execution time in the database improves because the DB doesn't have to re-parse and re-plan the query.

Detecting SQL Injection is hard ...

[Gopal.V]

The feedback factor for SQL Injection is very low. It is very hard to generically detect the after-effects of a successful sql-injection attack.

In comparison, something like XSS is easy because if you inject a string, the string re-appears in the HTML returned (HTML injection). The XSRF and XSS attacks dominate the internet attacks because they are really easy to scan for - though technically that should be an excellent reason they shouldn't exist :)

Rasmus Lerdorf has this awesome test-tool for XSS he keeps demo'ing (thankfully not released). You can see the tool in action in the background. But there's still no real easy way to reliably scan for Sql injection.

Re:what exactly is an sql injection?

[MickDownUnder]

SQL injection attacks target code in which sql statements are dynamically created.

e.g.

'select * from employees where fullName like ' + mySQLInjectedInputFromUser

where mySQLInjectedInputFromUser has been asssigned a value entered by the user:-

Fred Flinstone; GO; delete employees; GO

Testing slashdot

[mobby_6kl]

blah'; UPDATE users SET uid = '1' WHERE uid = '668092';

One of the best SQL injection attacks I've seen...

[thewils]

...was in conjunction with an error page which displayed the results of failed SQL.

I was able to change an innocuous 'select ... from catalog where section=1' into 'select ... from catalog where section=(select password from users where id=1)'.

This was nicely reported back to me as a SQL error stating that SQL was unable to convert "sdfsdfsdfsdf" into an integer, where "sdfsdfsdfsdf" was user id 1's password. I reported the problem to the site's owners, and it was still a month before they fixed it.

Moral of story - don't show the users any SQL errors, it gives them far too much information.