InfoQ

News

Study Shows That 11% of Sites Are Vulnerable to SQL Injection Attacks

Posted by Jonathan Allen on Sep 30, 2006 06:42 PM

Community
.NET,
Java
Topics
Data Access,
Security
Tags
Validation,
Vulnerabilities

In an informal study, Michael Sutton of SPI Dynamics was able to demonstrate that 80 out of 708 tested web sites were susceptible to SQL injection attacks.

In order to limit the test to sites that used a database, he first performed a Google search for sites with URLs containing "id=10". The assumption was that any site using a name=number pattern in the query string was most likely doing a database lookup. Using this, 1000 sites were selected.

After removing duplicates and non-functional sites, Michael Sutton was left with a pool of 708 candidate sites. By altering the query string, he found that 80 sites were returning error messages that suggested they were vulnerable to SQL injection attacks.

While study may not be formal enough for an academic paper, it does suggest that SQL vulnerabilities are a wide-spread problem among websites.

3 comments

Reply

Protection against SQL Injection (request for comments) by Thomas Mueller Posted Oct 2, 2006 2:19 AM
Re: Protection against SQL Injection (request for comments) by Paul H Posted Oct 3, 2006 6:58 PM
lies damn lies... by Jelmer Kuperus Posted Oct 8, 2006 4:01 PM
  1. There is an abvious way to protect against this vulnerability: don't embed user input into the SQL statement, use parameterized statements instead. I suggest that this should be enforced by the database engine (or, by the driver), by disabling literals in SQL statements. See here for more details: http://www.h2database.com/html/advanced.html#sql_injection What do you think about this solution?

  2. It's the standard solution :). Other problems (derived from the request params issues) might occur like removal/retrieval of items, for what you don't have credentials, common mistake in all the web apps, but that's a design problem. It would be nice to hear about solutions to avoid such flaws. I saw a few months ago an article about encrypting the url params etc, but i can't find the link :(.

  3. Back to top

    lies damn lies...

    Oct 8, 2006 4:01 PM by Jelmer Kuperus

    pfff or an error is shown because the parameter cannot be parsed to a string. This doesnt say anything

Exclusive Content

Using Ruby Fibers for Async I/O: NeverBlock and Revactor

Ruby 1.9's Fibers and non-blocking I/O are getting more attention - we talked to Mohammad A. Ali of the NeverBlock project and Tony Arcieri of the Revactor project.

Agile and Beyond - The Power of Aspirational Teams

Tim Mackinnon talks about the aspirations behind the Agile principles and practices, the desire to become efficient, to write quality code which does not end up being thrown away.

Concurrency: Past and Present

Brian Goetz discusses the difficulties of creating multithreaded programs correctly, incorrect synchronization, race conditions, deadlock, STM, concurrency, alternatives to threads, Erlang, Scala.

ActionScript 3 for Java Programmers

Often the hardest part of changing technologies is language syntax differences. This new article provides Java developers with a transition guide to Actionscript which forms the foundation of Flex.

Neal Ford On Programming Languages and Platforms

Neal Ford talks about having multiple languages running on one of the two major platforms: Java and .NET. He also presents the advantages offered by Ruby compared to static languages like Java or C#.

Future Directions for Agile

David Anderson talks about the history of Agile, the current status of it and his vision for the future. The role of Agile consists in finding ways to implement its principles.

Nick Sieger on JRuby

Nick Sieger talks about the future of JRuby, Java Integration, and his work on JEE deployment tools for Ruby on Rails like Warbler.

Rustan Leino and Mike Barnett on Spec#

Rustan Leino and Mike Barnett of Microsoft Research discuss the technology in Spec# and its futures.