top | item 10649917

Sqlmap – Automatic SQL injection and database takeover tool

139 points| danso | 10 years ago |sqlmap.org | reply

28 comments

order
[+] danso|10 years ago|reply
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).

[+] 001spartan|10 years ago|reply
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!
[+] chair6|10 years ago|reply
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...

[+] LunaSea|10 years ago|reply
That's because a very large majority of developers are shit at security (and I'm a developer).
[+] dvdgsng|10 years ago|reply
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.

[1] https://twitter.com/cschneider4711

[+] dorian-graph|10 years ago|reply
I know of a company that somebody used SQLMap against them last year. They're just a small, local company here in Australia.
[+] espes|10 years ago|reply
First release was ~2006

It's a tragedy that it has been almost a decade and it's still just as effective -_-

[+] jwcrux|10 years ago|reply
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.
[+] frik|10 years ago|reply
"Full support for six SQL injection techniques: boolean-based blind, time-based blind, error-based, UNION query-based, stacked queries and out-of-band."

Prevented with prepared statements - correct?

[+] 0x0539|10 years ago|reply
As long as you use prepared statements correctly.

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
Also prevented by escaping input.
[+] DawkinsGawd|10 years ago|reply
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.
[+] amjo324|10 years ago|reply
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:

https://www.owasp.org/index.php/SQL_Injection_Prevention_Che...

[+] zaroth|10 years ago|reply
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!

[+] tritium|10 years ago|reply
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.

[+] elktea|10 years ago|reply
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.
[+] 0x4a42|10 years ago|reply
Why using real_escape_string wouldn't help fixing sqli? Could you provide some examples?

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
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.
[+] amjo324|10 years ago|reply
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.