AFAIK...SQLmap is pretty old, right? I definitely have vaguely heard of it before...however, I was surprised to see it have not just a spiffy Github Pages homepage (after being on SourceForge), but a pretty highly followed Github account with commits in just the past couple of days.
But honestly, I have never heard another developer talk about using it (though I imagine full time sysops and security folks know it well)...even though it seems like it has an API easy enough to use and throw in as part of your dev toolkit (e.g. run it as part of an integrated test quite).
SQLmap has been part of many hackers' toolkits for quite some time now. It's very well known in the security industry as you suspected, and many of us penetration testers use it quite a bit for automating web app testing. I do imagine that it could be very useful for web devs, to test their security, and I wish more of them used it regularly!
Yep, from the changelog - "Version 0.2 (2006-12-13)". I've been using this during pentest gigs and the like since it was first released on SourceForge.
Cool to see tools lasting / improving, but depressing that SQLi is still so pervasive...
I just attended an interesting talk/livedemo by a security researcher[1] on WJAX2015 who used sqlmap to exploit a web application and extract and manipulate its content. So folks are using sqlmap.
The "-g GOOGLEDORK" and the "--tor" flags are key to any script kiddies arsenal. That's why you see so many low-level db breaches posted on things like Pastebin. Set those two flags and you have automated sql injection for easy targets.
"Full support for six SQL injection techniques: boolean-based blind, time-based blind, error-based, UNION query-based, stacked queries and out-of-band."
I can't tell you how many times I've seen someone passing a query though the prepared query method but still crafting the query dynamically
Stuff like:
prepareQuery("SELECT something FROM table WHERE col='"+userInput+"' and otherCol=?", otherUserInput);
That is still vulnerable even though prepared statements are in use. As long as user input doesn't find its way into the query string though you should be safe from these assuming the issue isn't internal like bad stored procedures creating queries based on input.
I played with SQLMap a bit on Kali. Easy tool to use, plays nicely with SOCKS5/TOR. I'm amazed at how prevalent SQLi is as an attack vector still. With PreparedStatements/PDO/other query libraries I would have bet this vector would have been all but eliminated many years ago.
I've been doing penetration testing of web applications professionally for about 5 years now. The incidence of SQLi has definitely decreased over the years but I would estimate that we still identify it on approximately 1 of every 5 web apps that we test for our clients. Usually, the more obvious SQLi has been found and patched already years ago. An example of obvious SQLi is 'error based SQLi' where the application returns verbose error messages such as:
"You have an error in your SQL syntax; check the manual
that corresponds to your MySQL server version for the
right syntax to use near '\'' at line 1"
As soon as we see an error message like this, we know we can dump the entire database in a matter of minutes.
These days, we usually have to work a bit harder to find the more difficult to identify and exploit SQLi (e.g. boolean-based blind and time based) but the end result is the same once we do. SQLMap is a standard tool in a any good web app penetration tester's toolkit. It's not always going to work but when it does it automates away a lot of the grunt work. I applaud the SQLMap developers who seem to know SQL inside out and actively acknowledge feedback from the community.
For any devs, this is decent guide for preventing SQLi:
My experience is fairly similar. How often does SQLMap (or another SQLi automated tool) fail to recognize a hole that is later uncovered through a manual investigation?
As per my other comment below, the intended use case for SQLmap is more around exploitation rather than identifying injection points. Penetration testers will usually identify the injectable parameters through other means (e.g. using purpose built security HTTP proxy software such as 'Burp Suite' and 'Zed Attack Proxy'). After they have confirmed the existence of SQLi, they will then feed the HTTP request and vulnerable parameter into SQLMap to automate exploitation (i.e. dump DB contents and hashes etc).
I would say that SQLmap is normally effective at determining whether a HTTP parameter is injectable with a high degree of confidence. However, sometimes there will be Web Application Firewall (WAF) filters or unusual/inconsistent application behaviour on certain inputs which means it can't confirm whether the parameter is definitely vulnerable or not (less than 10% of the time in my experience). For the same reasons, often it won't be able to successfully automate the exploitation for you. On those occasions, we have to craft our queries manually to exfiltrate database contents and so forth.
When using something like LINQ or Entity, I assume that SQL injection is a "solved" problem. As long as you aren't doing something crazy like writing stored procedures which internally concat user strings with query language, it's a whole class of attacks which you know will not succeed. Has anyone ever proven this wrong?
And then there's the VTech's of the world.... sheesh!
It is disturbing to know how many web applications simply forgo any sort of strong type enforcement on arguments and variables supplied directly to SQL as raw strings, simply because developers "don't like" or rather can be bothered with the wrestling matches needed, when explaining to non-technical people, the reason why it will take so long to add new features to an already expensive investment of development effort.
Many people out there just simply don't feel like writing prepared statements, entity classes for domain specific problems, or pushing past SQL query strings, and treating a data access layer as more than a scriptable text-based input vector to a glorified command line tool.
For as long as there are SQL databases, so too, there shall be successful SQL injection attacks.
>simply because developers "don't like" or rather can be bothered with the wrestling matches needed
In all fairness, I'd say it's more like web application security is a huge field (larger than just SQLi) and a developer typically has their hands full wrestling the technologies they use on a daily basis.
I am the most senior developer here in a team of 6 and we all know just the most basic facts about SQLi (use stored procedures), XSS (use sanitizing libraries) and it ends right at CRSF. Of the OWASP top 10, we have an eye on the top 4 and I wouldn't wager a high bet we have them nailed down.
It feels bad, but considering the resources we'd need to pour into getting one of our better devs trained in all the facets of web app security, it's unlikely to change any time soon.
>It feels bad, but considering the resources we'd need to pour into getting one of our better devs trained in all the facets of web app security, it's unlikely to change any time soon.
Consider the resources you'll have to expend in the event of compromise and compare. While this analysis doesn't always prove the slower but more secure approach to be cheaper, it usually does. Unfortunately, you usually can't get the people holding the purse strings to accept the trade until they've been bitten.
The last time I wrote a longish mail why we should at least pour _some_ resources into this, my superior (who straddles technical and managerial role and is responsible for budget oversight) answered:
"Thanks for bringing this topic up, Mr. iSnow.
Looking at it pragmatically, we have no real use-case for that right now, so I don't think it's the right time to dive into it. I will, however, keep it in mind and would ask the team to collect information on this and keep an eye on the subject".
And of course, without dedicated time and budget for such a large area, developers can either cheat and hide learning it between feature requests or don't do anything about it. So, I am totally not surprised things like the VTech break-in happen all the time, I just don't think it's fair to blame developer's inertia for it.
I used this just today to demonstrate to our developers why their attempts to fix SQL injection via real_escape_string and regex wasn't a good idea. Great tool.
This looks like a great time and money saver. Thanks for this to all contributors. I will test drive it soon on my app that requires high security level.
In my opinion, this is not really SQLMaps intended use case. It's essentially an exploitation tool for penetration testers and doesn't provide a proper mechanism to just scan your app looking for SQL injection points. There are better tools for that (google 'Burp Suite') and if your app requires a high security level you should be engaging a full time infosec professional to manually assess it.
But honestly, I have never heard another developer talk about using it (though I imagine full time sysops and security folks know it well)...even though it seems like it has an API easy enough to use and throw in as part of your dev toolkit (e.g. run it as part of an integrated test quite).