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

asian aid

[User 956 (568564)]

The list is intended asan aid for both web application developers and professional security auditors.

Ok, so that covers China and Japan, but what about Europe and the U.S.?

Why is this needed at all?

[by 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:

[koh (124962)]

The DB interface in PHP5 supports positional arguments AFAIK. Now, if only the service providers would switch to PHP5, there would be less problems. Unfortunately, it seems that, at least here, the major providers are still stuck in PHP4-for-compatibility-with-existing-apps mode.

Re:

[billcopc (196330)]

Gee that's an easy solution: dump the legacy apps! PHP 5's only been out for 3 years :P How hard can it possibly be to rewrite the vulnerable bits of SQL anyway ? I never really felt much of a shock when I switched to PHP5 years ago, the bulk of my coding habits were unaffected and the few things that broke involved a 5-minute fix or less.

Re:

[neoform (551705)]

mysql_real_escape_string() has been a function going back to php4..

Re:

[ThwartedEfforts (2976)]

magic quotes ain't helping though either, but I suppose seeing backslashes littering the output (as is common on many websites) is better than SQL injection. The magic quotes setting, and the concept behind and naming of the stripslashes function, is so confusing that it's best to just turn off magic quotes, don't use stripslashes, and manually make sure you either quote everything (hard) or use prepared statements (much easier).

Re:Why is this needed at all?

[mabinogi (74033)]

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:

[PhotoGuy (189467)]

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.

I agree. I actually find it easier to use the call with parameters, rather than trying patch together a string. Putting in the "?" parameters in the string, and listing them afterwards, pretty damn simple. I'm amazed SQL injection is an issue at all. I guess there's a lot scarier programming out the

Re:

[GnuDiff (705847)]

I think it is due to 2 reasons:

1) the string concatation technique being present in several pretty popular (and awful) PHP books, and (afai remember) in the PHP documentation itself, thus becoming defacto "standard";

2) The general ignorance of a significant part of PHP developers of any database abstraction layers and in fact anything but the magic LAMP.

Re:

[Firehed (942385)]

Only helps if you use it. It's easy to forget at least once, especially in a big project.

Re:

[vdboor (827057)]

For a security audit of an existing code base! Or are you willing to hire someone to browse code in a month time?

I suppose the over-use of PHP (which for a long time didn't even support prepared statements (does it even do it today?))

Every language allows you to write libraries which do things properly. The language is not a limiting factor here.

Re:Why is this needed at all?

[hclyff (925743)]

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:

[FooBarWidget (556006)]

Prepared statements are slower because it needs an extra server roundtrip. I've recently discussed this issue on the Ruby on Rails core mailing list [google.com], and people mentioned this while asking why we need prepared statements.

Re:

[ensignyu (417022)]

You could always use client prepared statements, which is mostly the same as building your own SQL statements strings but are much cleaner and does the quoting for you.

Re:Why is this needed at all?

[ceswiedler (165311)]

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.

Re:

[FooBarWidget (556006)]

"Huh? Do you prepare your statements every time you execute them?"

Uhm, if you use PHP then you *can't* cache your prepared statements (unless you do the same query many times in the same PHP run, but that's unlikely). PHP is stateless, after one run it frees everything.

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

In theory, yes. But are there

Re:

[enrevanche (953125)]

I cannot answer for Ruby, but for Java/JDBC this is only true for the first call to a prepared statement. For the second and subsequent calls to a prepared statement, a prepared statement is always better or at worst equivalent. With connection and prepared statement pooling, performance can be improved dramatically.

Note that this all depends on the database and the driver, as some databases do not cache query plans or the driver does not properly coordinate the query plan with the database.

There is no s

Re:

[jZnat (793348)]

PHP 5 does natively via PDO [php.net], and PHP 4 (and 5) does via PEAR's MDB2 [php.net] (older version: DB [php.net]). There is also ADOdb [sourceforge.net] which has a very similar API to Microsoft's ADO RDBMS API (acronym overload!).

The availability of robust packages like those still doesn't stop newbie (and veteran) PHP programmers alike from just using the raw MySQL API subset known as the mysql_* functions (which were deprecated in favour of the newer MySQLi [php.net] functions/objects that also support prepared statements) along with occasional use of adds

Re:Why is this needed at all?

[vr (9777)]

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:

[nurb432 (527695)]

Because people sometimes goof, and its always good to test test test test.

Re:

[AnObfuscator (812343)]

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

Alternatives

[stonecypher (118140)]

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 Mnesi

Detecting SQL Injection is hard ...

[Gopal.V (532678)]

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 [flickr.com] in the background. But there's still no real easy way to reliably scan for Sql injection.

Re:

[Plutonite (999141)]

Rasmus Lerdorf has this awesome test-tool for XSS he keeps demo'ing (thankfully not released).

Why thankfully? I've left this stuff a long time ago, but nothing has changed about security and obscurity. You cannot win this way, you only prolong a possibly undetected failure.

what exactly is an sql injection?

[siddesu (698447)]

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:what exactly is an sql injection?

[MickDownUnder (627418)]

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

Re:

[weicco (645927)]

Yep. And that's why you should use parameters instead of dynamically creating SQL commands as string. Not like this (C# .NET):

SqlCommand cmd = new SqlCommand(); cmd.CommandText = "SELECT * FROM t_Table WHERE Something LIKE '" + InputString + "'";

But like this (C# .NET):

SqlCommand cmd = new SqlCommand(); cmd.CommandText = "SELECT * FROM t_Table WHERE Something LIKE @param1"; cmd.Parameters.Add("param1", DbType.String).Value = InputString;

Lousy example, I know. A lot of languages and/or frameworks sup

Re:

[Shados (741919)]

Its not the language that makes it so you use ? or @name for the parameters, but the access layer and/Or the DBMS itself. For example, using ODBC or OLEDB, even if you connect to SQL Server with C#, you'll end up using the ? way of doing things. Just a side note :)

Wikipedia is your friend

[CaptainZapp (182233)]

For more information about SQL Injection [wikipedia.org]

Re:

[cheater512 (783349)]

Oh the common interface is there. Its just that people (like you) dont know about it.

www.php.net/pdo

Re:

[siddesu (698447)]

pray tell, how does (using the example above, and an imaginary access api)

this:
st = api.createStatement('select * from employees where fullName like ' + mySQLInjectedInputFromUser);
st.execute

take more time to write than this:
st = api.createStatement('select * from employees where fullName like ?' )
st.execute(mySQLInjectedInputFromUser);

Re:

[FooBarWidget (556006)]

What do you mean, "I'll bite"? What makes you think it's a troll? Can't people have a legit question these days without being seen as flamers and trolls?

Properly written software...

[MickDownUnder (627418)]

In well written software SQL injection attacks shouldn't be possible. Don't use dynamic SQL, use stored procs. If you think you have to use dynamic sql, then create the sql statement within a stored proc (not code) then access that stored proc using authentication details that permit only read only access. I've never seen a situation in which dynamic SQL was required for updating or inserting data, generally it only gets used when performing complicated searching and even then it's not the only option...

Re:

[growse (928427)]

Why go through the faff of stored procedures whn you can just use parameterized queries? As far as I know, you need to have access to the db server to create/edit stored procs, and also, afaik, there's no way to use a source code control system on them.

Because a parameterized query sits in the code, you don't have to touch the db server if you want to do a code update.

Re:

[MickDownUnder (627418)]

It is common practice with database development tools to update stored procs from sql scripts which are checked into source control systems. Microsoft has a whole verion of Visual Studio [microsoft.com] for this purpose.

Not using stored procs at all in your application is typically done by novice developers, it is not how an experienced professional works with a database.

Re:

[growse (928427)]

Which I'm sure is fabulous if you're using .NET and MSSQL. However, I imagine that particular combination doesn't make up a very large percentage of all the database applications out there.

Don't get me wrong, stored procs are a useful tool which are the correct answer to some types of problem. But completely overkill if you just need simple or even slightly complicated CRUD operations. Using stored procs when they're not really necessary is the mark of a developer who doesn't know how to use every tool in

Re:

[MickDownUnder (627418)]

Most database engines takes advantage of store procedures to create a pre-prepared execution plan which is used to optimise and speed execution time. Visual Studio will work with any database with an ODBC connection. All Visual Studio gives you is a nice environment in which to extract sql scripts and check them into source control, you don't actually need Visual Studio, you can just use notepad and edit sql scripts and check them in and out of source control manually.

*sigh* I don't know what I was thinki

Re:

[Jaime2 (824950)]

Most database engines takes advantage of store procedures to create a pre-prepared execution plan which is used to optimise and speed execution time.

Most database engines also apply the exact same techniques to plain text queries. If the plain text queries are parameterized, then it works even better.

All Visual Studio gives you is a nice environment in which to extract sql scripts and check them into source control

Visual Studio also give you powerful tools to build parameterized queries and wraps t

Re:

[MickDownUnder (627418)]

The whole parameterized query thing vs stored procs argument has been argued from the day the internet was born.
Here's the arguments I would make for stored procs.

Most database engines also apply the exact same techniques to plain text queries. If the plain text queries are parameterized, then it works even better

Database engines more often than not will generate a whole new execution plan for plain text queries, it can also cause the execution plan cache to fill up more quickly, plus it opens you up to s

Re:

[Jaime2 (824950)]

plus it opens you up to sql injection

No, it doesn't. That's the false dichotomy that sp supporters like to espouse. A poorly called sp is vulnerable to SQL injection, while a well written, properly called ad-hoc query is not vulnerable. Just using a stored procedure does not protect you from SQL injection and just avoiding them does not make you vulnerable to it. I just worked up a real quick ad-hoc paraeterized SQLCommand in Visual Studio and here is what SQL Profiler shows me is really executing;

Re:

[Doctor Faustus (127273)]

What about my argument that T-SQL is a horrible language? You have one looping construct and one statement level conditional construct. Cursor loops require you to write the FETCH both before the loop and at the end of the loop making maintenance that much more tedious. Compile errors can be tough to track down as the messages are often vague. Hidden gotchas like compiling a procedure with QUOTED_IDENTIFIERS on and modifying it with them off are always fun. No select construct (as in a traditional programmi

Re:

[growse (928427)]

I'm sorry, but if you think that stored procedures are the be-all and end-all to db query security, then it would appear that you don't have a clue.

It is perfectly possible to write secure code without using stored procedures. It might be more difficult, in some cases, but not impossible.

Re:

[Shados (741919)]

Btw, what cracks me up is, bringing Visual Studio to the table, then talking about most database engines taking advantage of SPs for query plans...then forgetting...

One of the database engine thats the most used in tandem with Visual Studio, does NOT. In SQL Server, the execution plan is not pre-prepared. Its made at runtime, and cached. What does that mean? That dynamic sql (using prepared statements ONLY!), and stored procedures, have the same performance advantage, so that argument falls flat. I know not

Re:

[Ash Vince (602485)]

What alovely idea, but here in the real world we have things called design constraints. Like maybe you have a web application that has been doing its job for the previous 5 or 6 years but is also constantly evolving. You have a lot of legacy code that was written to run against a mysql database from 5 years ago. That puts you on MySQL 4.0 with no stored procedures.

Now I am not saying this doesnt need an upgrade (currently in the works), but when you are talking about a mission critical app that is already m

Re:

[Shados (741919)]

While stored procedures are good, using dynamic sql inside the stored proc is (almost) as vulnerable as using normal dynamic sql.

The truly secure methods are:

1) Use stored procedure, with no dynamic sql whatsoever.
2) Use prepared statements: this make dynamic sql just as secure as stored procedure, and in the more advanced RDBMS, allows query plan to be cached (aka: it is virtually exactly as fast as stored procedures. SPs being used for performance reasons is a myth folks, at least with the better RDBMSs)
3

Testing slashdot

[mobby_6kl (668092)]

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

Top 15 _______?

[kjart (941720)]

What is this, Digg?

Validating Input

[mtjo (1080513)]

Validating input prevents alot of problems. Prepared queries help but can still be exploited in poorly written statements. As in the classic SELECT query example, "where id=23 OR 1=1", using a datatype test as well as testing for null values for a $_GET or $_POST parameter before executing the query would throw back an error if expecting an unsigned integer.

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

[thewils (463314)]

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

do they check cookies?

[brunascle (994197)]

it's not just URLs and post-back forms that can be vulnerable, cookies can be too. i didnt realize that until i found one on my own site. (it wasnt exploited, i found it on my own.)