Slashdot Mirror

← Back to Stories (view on slashdot.org)

Top 15 Free SQL Injection Scanners

Posted by kdawson on from the looking-for-trouble dept.

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

6 of 103 comments (clear)

  1. Why is this needed at all? by Anonymous Coward · · Score: 5, Insightful
    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.

    1. Re:Why is this needed at all? by mabinogi · · Score: 5, Informative

      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.

      --
      Advanced users are users too!
    2. Re:Why is this needed at all? by hclyff · · Score: 5, Insightful

      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.
  2. Detecting SQL Injection is hard ... by Gopal.V · · Score: 4, Insightful

    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.

    --
    Quidquid latine dictum sit, altum videtur
  3. Testing slashdot by mobby_6kl · · Score: 4, Funny

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

  4. One of the best SQL injection attacks I've seen... by thewils · · Score: 4, Informative

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

    --
    Once I was a four stone apology. Now I am two separate gorillas.