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."
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.
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, 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 Mnesia, I'd love to hear about it.)
Sure, there are times at which SQL is a major win over mnemosyne, but they're not common. Sure, it's nice to have a database be ready for you at any host, instead of having to take the time to find a good host who lets you run stuff. But when it comes down to it, the atypical performance characteristics of Erlang (especially since I write multiplayer games, for which massive concurrency is win) and the ridiculous speed of Mnesia make me miss SQL less every day.
'Course, client stuff still needs to work on MySQL.
StoneCypher is Full of BS
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
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?
blah'; UPDATE users SET uid = '1' WHERE uid = '668092';
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
What is this, Digg?
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.
...was in conjunction with an error page which displayed the results of failed SQL.
... from catalog where section=1' into 'select ... from catalog where section=(select password from users where id=1)'.
I was able to change an innocuous 'select
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.
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.)
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