Slashdot Mirror


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

16 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 ThwartedEfforts · · Score: 2, Insightful

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

    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.
    3. Re:Why is this needed at all? by billcopc · · Score: 2, Insightful

      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.

      --
      -Billco, Fnarg.com
    4. Re:Why is this needed at all? by PhotoGuy · · Score: 2, Insightful

      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 there on major sites than I can possible imagine.

      --
      Love many, trust a few, do harm to none.
    5. Re:Why is this needed at all? by ceswiedler · · Score: 3, Insightful

      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.

    6. Re:Why is this needed at all? by GnuDiff · · Score: 2, Insightful

      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.

    7. Re:Why is this needed at all? by enrevanche · · Score: 2, Insightful
      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 simple answer, as this all depends on the database and the application.

    8. Re:Why is this needed at all? by encoderer · · Score: 1, Insightful

      1. Explain to me how PHP didn't allow libraries to be written? I don't understand that whatsoever. In PHP4 I'd write (and have written) a data abstraction layer that wrapped the inbuilt mysql functions, incorporating, among other things, string cleansing. The mysql library is procedural in PHP4 and below (and is both proc and oo in 5). So even if you're using <4 you can just write your own wrappers for all the functions and throw them in a file that gets auto_prepend()'ed to every page. (auto_prepend acts sorta like a generic front-controller)

      2. I never developed from scratch in PHP3 (just upgraded a few applications) or below but if, for some who-knows reason why people couldn't write such function wrappers, forget not that PHP is open source. Anyone could've written an extension in C and compiled it into PHP.

      3. There is nothing about PHP5 that makes injection any less likely than in PHP4 if the developer is still using the mysqli library the same as he used the mysql library in php4. And if the developer is enlightened enough to use the improvements afforded by mysqli library properly, he'd probably also be enlightened enough to realize you can use the mysqli library in PHP4 as well.

      4. Nobody is developing in PHP6 yet. It just made (EARLY) beta.

      5. In summary, you don't seem to know all that much about PHP. You certainly know more than most, but I don't know why you posted information that's just not true. Is it just more PHP FUD or were you just sincerely misinformed? I only even point this out because PHP gets a pretty bad rap on here even though version 5 compares favorably to any other modern web dev language. It's not in the league of ASP.Net or J2EE, but it certainly is a better language than the avg /.'er gives it credit for.

      I used to avoid PHP like the plague. I was comfortable using Java and C# for web development and even an occasional line of {shudder} VBScript. What I found when I began using it was a language that was very capable when used properly.

      People here give PHP a bad rap because of the PHP Developers using it. It's a great entry level language. It gives you what I call complexity on demand. It's a language thats useful for your first-time developer, he doesn't need to learn or concern himself with procedures or classes or design patterns, and also useful for an experienced developer, capable of OOD, reflection, etc.

  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.

    1. Re:Detecting SQL Injection is hard ... by Plutonite · · Score: 2, Insightful

      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.

  3. Re:what exactly is an sql injection? by FooBarWidget · · Score: 2, Insightful

    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?

  4. Re:Properly written software... by growse · · Score: 2, Insightful

    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 his toolbox properly.

    --
    There is nothing interesting going on at my blog
  5. Top 15 _______? by kjart · · Score: 2, Insightful

    What is this, Digg?

  6. do they check cookies? by brunascle · · Score: 2, Insightful

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

  7. Re:Properly written software... by Ash+Vince · · Score: 2, Insightful

    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 making money you have to be very careful about breaking anything, you cant just throw a new version of mysql on your master database server and pray to the gods of IT. You have to be 100% sure everything will work before you move to a new version of anything, otherwise you irrepairably damage the image of your business.

    Even when you are sure that it will work you have to perform the switch outside of core hours and warn customers of the potential for downtime. Things do not always go 100% according to plan and the most minor error can have serious consequences. Especially when in order to do something outside working hours you are doing this at 4am. It takes several days to switch your sleep patterns over to nighttime working but quite often in the run up to the overnighter you are too busy to sleep all day.

    Out here in the real world we have to deal with suboptimal platforms as the decision to go with a particular DB server might have been taken years before you started working for the company. You can not just go in and insist everything is changed to what you would prefer (even if it is a better platform).

    --
    I dont read /. to RTFA, I read /. to offend people in ignorance.