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

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