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:
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.
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.
[+] [-] danso|10 years ago|reply
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).
[+] [-] 001spartan|10 years ago|reply
[+] [-] chair6|10 years ago|reply
Cool to see tools lasting / improving, but depressing that SQLi is still so pervasive...
[+] [-] LunaSea|10 years ago|reply
[+] [-] auscompgeek|10 years ago|reply
[+] [-] dvdgsng|10 years ago|reply
[1] https://twitter.com/cschneider4711
[+] [-] dorian-graph|10 years ago|reply
[+] [-] espes|10 years ago|reply
It's a tragedy that it has been almost a decade and it's still just as effective -_-
[+] [-] jwcrux|10 years ago|reply
[+] [-] frik|10 years ago|reply
Prevented with prepared statements - correct?
[+] [-] 0x0539|10 years ago|reply
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.
[+] [-] PlzSnow|10 years ago|reply
[+] [-] moloch|10 years ago|reply
[+] [-] DawkinsGawd|10 years ago|reply
[+] [-] amjo324|10 years ago|reply
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:
https://www.owasp.org/index.php/SQL_Injection_Prevention_Che...
[+] [-] zaroth|10 years ago|reply
And then there's the VTech's of the world.... sheesh!
[+] [-] tritium|10 years ago|reply
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.
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] elktea|10 years ago|reply
[+] [-] 0x4a42|10 years ago|reply
I know prepared statements are the way to go but proper escaping, even if tedious, seams to be OK for me.
[+] [-] funkyy|10 years ago|reply
[+] [-] amjo324|10 years ago|reply