
Sqlmap: Automatic SQL injection and database takeover tool - madewulf
http://sqlmap.org/
======
tptacek
If you're a small startup looking to automate security testing against your
application, I strongly recommend just shelling out for Burp Suite; it's like
a couple hundred bucks tops, can be used to automate almost every common web
app attack, and is the tool most likely to be used by good auditors when you
eventually decide to get tested professionally. 

<http://portswigger.net/burp/>

There's a free version, which disables the (mostly vestigial, anyways)
"scanner", and slows down the fuzzer tool; if you're really automating
security testing --- which, do --- pay for the real version; you want the
fuzzer to work. 

There are things sqlmap does that Burp does not do easily, but they're not
important to app developers; if you're generating database exceptions with
inputs, don't dick around trying to make time-based blind SQL work; just fix
the bugs. 

~~~
127001brewer
Here's a blog posting from Bruce Schneier on getting started in computer
security:

[http://www.schneier.com/blog/archives/2012/07/how_to_become_...](http://www.schneier.com/blog/archives/2012/07/how_to_become_a_1.html)

There are links within his blog posting to other tools. 

~~~
tptacek
I wrote a similar piece for Krebs the week prior; I think it's linked from
this one. 

I'm not a fan of Schneier's take on this.  Don't start a career in security by
thinking about certification. 

~~~
127001brewer
Can you provide the link to Krebs? 

~~~
ontoillogical
Here: [http://krebsonsecurity.com/2012/06/how-to-break-into-
securit...](http://krebsonsecurity.com/2012/06/how-to-break-into-security-
ptacek-edition/)

------
maratd
Forgive my ignorance, but if you're using prepared statements for all your SQL
queries using user input, aren't you by definition safe from any kind of
injection? 

~~~
tptacek
Of course not.  This is a pernicious myth about SQL security.  Many inputs to
query construction can't be parameterized. 

~~~
maratd
> Many inputs to query construction can't be parameterized. 

I do not allow the client direct access to the database.  They access the
database through objects, which have methods that only permit parameterized
input. 

The client cannot specify the database, table, or columns.  That is hard-coded. 
They can only specify values.  Values that are always entered through a
prepared statement. 

In that scenario, isn't injection impossible? 

~~~
tptacek
No.  Of course not.  In all likelihood your SQL RDBMS will only allow you to
bind data.  Do you paginate?  What about "LIMIT" and "OFFSET"?  Do you sort
tables?  Then you have to handle column names.  Do you sort in both directions? 
Then you have to handle "ASC" and "DESC".  And so on. 

Obviously, you can write simple code to do each of these safely.  But then, you
can write simple code to handle query parameters too. 

By all means, use parameterized queries.  Just don't assume they're a magic
totem against SQLI. 

~~~
zzzeek
You can and should bind LIMIT and OFFSET with parameters on many if not most
drivers (some can't handle it but most that I work with these days do, though
I'm in Python, perhaps JDBC or other drivers are a different story).  ASC and
DESC are SQL keywords so assuming you're not a terrible programmer (which I
know is what you're addressing) you wouldn't have those rendered from user
input any more than the WHERE or ORDER BY keywords. 

The lexical structure of the statement and the parameters themselves are two
different things.  You are correct that "parameterization can't save you from
SQL injection", if you're such a bad programmer that you're feeding user input
directly to produce lexical tokens.  One example is a recent blog post talking
about how to escape table names for apps that feed things like "customer_name"
to serve as the table name (totally insane).  Your example of feeding in
"sort=xyz" to produce the column name in the ORDER BY is also a pretty awful
practice - I haven't seen that one in like a decade, but sure. 

So of course parameterization doesn't magically protect a system against all
forms of attack - the programmer could be feeding user input directly into
shell commands too.  The recommendation for parameterization is addressing the
bulk of the issue at least among the code that I regularly work with, maybe
you deal with crappier programmers than I do on a regular basis. 

~~~
lotyrin
> Your example of feeding in "sort=xyz" to produce the column name in the
> ORDER BY is also a pretty awful practice - I haven't seen that one in like a
> decade, but sure. 

This still happens every day.  Google how to do dynamic sorting and you'll find
a hundred examples of it in PHP, and as unfortunate as it is, that's how a
significant portion of code is authored. 

------
mrkmcknz
How can I donate to you guys? 

------
wglb
This is an excellent tool.  But generally on a penetration test, BurpSuite is
what you want to use. 

If, however, simply demonstrating that SQLi is there is not sufficient, or if
the blind SQLi is too ephemeral sounding to the client, Sqlmap can help you
dump the entire database.  This will convince even the most skeptical. 

~~~
emidln
I prefer using w3af over BurpSuite.  Full source is a good thing. 

------
daksatech
Havij is a similar tool thats gaining in popularity due to its point and click
interface.  check out: [http://blog.imperva.com/2012/04/dissecting-the-sql-
injection...](http://blog.imperva.com/2012/04/dissecting-the-sql-injection-
tools-used-by-hackers.html)

------
taylorbuley
Here's a video demonstration playlist:
[http://www.youtube.com/watch?v=fGBQm9Nfn24&list=UU8lIbC-...](http://www.youtube.com/watch?v=fGBQm9Nfn24&list=UU8lIbC-
tp4cPosY0kB8Xkxg&index=9&feature=plcp)

------
benatkin
Here's a better web page that contains the same information:
<https://github.com/sqlmapproject/sqlmap>

------
lucasgameiro
Thanks god this kind of tools now has so much better layouts than few years
ago. 

------
countessa
Nice little tool thanks

------
BaconJuice
Very cool, Thanks

------
Toshio
Has anyone done a comparative review of sqlmap vs skipfish? 

~~~
tptacek
They're not really comparable.  Skipfish is a fast crawler with some checks for
DOM corruption, SQL metacharacters, and hygiene.  sqlmap is a tool for
exploiting SQL injection. 

I like the code for Skipfish a lot, but neither tool is particularly important
in the profession; if you're working with a contract application security firm
and they give you findings that came from sqlmap or Skipfish, you should be
irritated. 

~~~
jvdongen
I'm not sure I read your final remark correctly.  Do you mean to say that using
Skipfish or sqlmap has no place in a professional pen test or that a
professional pen tester should not subject his clients to the raw results from
said tools? 

The latter I agree with, the former I don't.  Any automated security scanner
has its shortcomings - combining the results of various scanner products
generally has a positive effect upon the quality of the test.  I've often been
in a situation where one tool (commercial or otherwise) indicated or hinted at
a vulnerability while all other tools (commercial or otherwise) used did not
indicate anything. 

~~~
tptacek
The former.  With some _very_ minor exceptions, we don't use automated scanners
at all in our practice.  We use Burp to set up testing experiments, and we use
ruby for automation.  We've found that "scanners" make good testers much less
sharp; if the tool spits out the names of specific vulnerabilities, it's
suspect. 

But even practices that do use automated scanners won't be relying on Skipfish
or sqlmap. 

This obviously doesn't hold for network pentesters.  For tests in which
application flaws aren't the whole story, and you're just looking for the
fastest way in you can find, sure; sqlmap is valuable there, much more so than
Skipfish.  We don't do those kinds of tests often. 

~~~
ontoillogical
When you say "we use ruby for automation" do you mean using something like
buby with Burp, or something custom? 

I find myself writing a lot of custom fuzzers in python, and am looking to
improve my toolkit. 

~~~
tptacek
A long time ago, Eric Monti, then a member of our team and now at a big
startup in SF, wrote a Burp/Ruby bridge called Buby.  For a long time, and
maybe still, another team member --- Timur Duehr, who also wrote the first
version of our Ragweed native code debugger DSL --- maintained it.  A lot of
people on our team use Buby to automate. 

Another faction of our team uses Mike Tracy's WWMD toolkit, which does some of
what Burp does but from an irb prompt. 

I'm allergic to both approaches and tend to just start from EventMachine and
ev-http-request. 

Good example of the kind of scenario that'll get me into "writing code to test
web apps" mode: testing those goofy cryptographic tokens applications send via
email to reset passwords. 

~~~
ScottBurson
"Goofy" cryptographic tokens?  Is there a better way? 

~~~
tptacek
Not having the tokens be replayable, rewritable to different user IDs, or
decryptable would be a good start, right? 

Yes: the better approach is to have the token be a 256 bit cryptographically
strong random number that corresponds to a row in the database with metadata
sufficient to expire the token and invalidate it on password reset. 

~~~
ScottBurson
Ah.  So it's not the use of cryptographic tokens _per se_ that you're objecting
to -- just that they're not generated and/or handled correctly. 

~~~
tptacek
I object in general to the widespread practice of using tokens that contain
semantically interesting information protected by encryption. 

~~~
ScottBurson
Got it.  Didn't realize that was so widespread. 

~~~
ontoillogical
You'd be surprised to know how often it's just the username encoded in
base64...

