How Prevalent Are SQL Injection Vulnerabilities?

Krishna Dagli writes to tell us of an investigation, by Michael Sutton, attempting to get an estimate of how widespread SQL-injection vulnerabilities are among Web sites. Sutton made clever use of the Google API to turn up candidate vulnerable sites. You might quibble with his methodology (some posters on the blog site do), but he found that around 11% of sites are potentially vulnerable to SQL injection attacks. He believes the causes for this somewhat alarming situation include development texts that teach programmers insecure SQL syntax, and point-and-click tools that allow the untrained to put up database-backed sites.

Re:The abuse of SQL injection

[Anonymous Coward]

The bad, though, is now, even if 10 people come by and mod you funny, you still lose karma because funny moderations don't count, but overrated/offtopic/troll/flamebait do.

You don't need to bother with SQL Injection

[thewils]

If you search for "mdb" you can download the entire database without too much trouble.

I recently came across a commercial site where you could substitute, for instance, "(select first_name from users where id=1)" into the page url and a nice error screen came up telling you that it couldn't convert "George" into an Integer.

It's not the SQL Injection per se that is the biggest problem, but the nice error messages you get back giving you, more or less, a SQL command line interface. Errors should be detected and redirected to a sanitized page, or if you can't be bothered, an unceremonious crash.

I notified the owners of that site by the way.

Re:The "Oh-Sh*t" face...

[Ford Prefect]

And I've seen the "oh-sh*t" face on a couple of developers after demonstrating to them that their software is vulnerable to SQL Injection. In both cases the vulnerabilities exposed the customers to the posibility of serious financial damage.

Have you seen the 'oh, that's not a problem, we're using SSL so it's completely secure' face yet?

As for stupidest work-arounds - a site I was doing a vague security audit for (sans source-code, alas) was (is) rife with SQL injection vulnerabilities. On attempting to explain this to the programmer, with very simple code examples, I was confronted by some increasingly complicated 'solutions' to the problem.

It was an integer database ID. But strings would go in. I suggested converting it to an integer. But no, programmer decided to do a search-and-replace on SQL keywords in the string.

So I used lower-case SQL keywords, and strongly recommended converting to an integer.

Programmer added lower-case SQL keywords to his search-and replace routine.

So I used mixed-case SQL keywords, and told him to stop being silly and just convert to an integer.

Last seen, the code was replacing non-digits with  . Okay, so it removed SQL injection attacks from that particular variable, but AAAAARGH.