
Sqlmap – Automatic SQL injection and database takeover tool - danso
http://sqlmap.org/
======
danso
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
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!

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

~~~
0x4a42
>prepareQuery("SELECT something FROM table WHERE col='"+userInput+"' and
otherCol=?", otherUserInput);

This is very dumb, yet too common. :-/

------
DawkinsGawd
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
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...](https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet)

~~~
DawkinsGawd
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?

~~~
amjo324
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.

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

~~~
iSnow
>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.

~~~
cookiecaper
>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.

~~~
iSnow
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.

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

~~~
elktea
Some examples can be found here:
[http://stackoverflow.com/questions/5741187/sql-injection-
tha...](http://stackoverflow.com/questions/5741187/sql-injection-that-gets-
around-mysql-real-escape-string)

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

