Vulnerability assessors and code auditors are often faced with situations where a large volume of code needs to be audited quickly to enable a deployment. In these situations large web applications need to be reviewed in a fast and efficient manner. Although
a code level analysis is often the most effective way to analyse the security of an application it is a time consuming process and not all practical. In these situations testers often turn to automated tools to help discover vulnerabilities.
is an automated SQL injection tool that, like most web auditing and assessment tools, does a great job if properly configured and guided through execution. SQLMap contains some interesting features that seem
to lend it to quick evaluation of applications. In this article I'll go over these features and how to use them and conclude with an evaluation of the effectiveness of SQLMap for this purpose.
The course involves some hands on exercises, including a simple PHP/MySQL based application that is deliberately vulnerable to SQL injection in several places. Looking at the code base, it is relatively straightforward to identify these vulnerabilities and
develop exploits. I was interested to see if SQLMap would be as effective in finding and exploiting these vulnerabilities.
For the purposes of this exercise you can download the latest version of the SQLInjectionWebApp from SourceForge at
Once the application is unzipped you need to create the database using the script in the sql/ directory. To do this simply type, at the command prompt:
And you shouldn't get any errors. Once the database is installed you can browse the application to get a sense of its functionality. If you need any pointers or tips on debugging feel free to check out the presentation slides I put together for the exercise
Which should print out the usage options. SQLMap contains a very interesting input feature that is invoked with the "-l" flag. This is the list option which allows you to pass a list of URL's or WebScarab logs. To utilize the full power of this feature
Once WebScarab is up and running we need to configure our web browser to use a local proxy on port 8008. On Firefox this is easily done by going to Edit -> Preferences -> Advanced -> Network, then click the 'Settings' button next to the Connection section.
In the new window click the radio button next to 'Manual proxy configuration:' and set the 'HTTP Proxy' to 127.0.0.1 and the port to 8008 then click 'OK'. Now that the proxy is running pull up the target site page in a browser.
You'll notice that WebScarab instantly records the page request.
Now, you could manually surf through the entire application, showing WebScarab where each page was, but WebScarab has a nice feature that obviates this need. Simply right click the URL and select the 'Spider tree' option. This will spider the entire application
quickly and accurately. Once you've completed the scan save the session in WebScarab from 'File' -> 'Save' and specify a folder name. For our purposes let's say you save the scan in ~/webscarab/sql-inject/.
Once saved you can look in the directory where the WebScarab output was stored. You'll notice a subdirectory called conversations. Inside of this folder you'll see a series of request and response files. Each one stores the text of the corresponding request
to the target or response from the target. We'll use this directory as our input for SQLMap to automate the search for SQL injection.
To fire up SQLMap using the WebScarab logs use the command:
Answer 'y' for affirmative response to all the questions SQLMap prompts you with. You should see output that looks something like the following:
There are several interesting things to note about this output. The first is that SQLMap uses GET variables by default. You can change this to examine POST variables, but SQLMap needs to understand the variable to use during POST assessment, so it won't
work with your WebScarab data. The other thing to notice is that SQLMap only finds one SQL injection vulnerability in the URL '?id=1' even though this vulnerability clearly exists with other 'id' GET parameters.
Ultimately SQLMap identifies only one of the SQL injection points in the application even though there are several, including a POST injection vulnerability in the login script that allows authentication bypass. Additionally there is a COOKIE injection
vulnerability that is completely blind that SQLMap does not (and cannot by design) identify. Although there are several other vulnerabilities that present themselves after authentication, the surface scan of SQLMap cannot identify these as it fails to identify
the vulnerability in the login.
From an evaluators standpoint this approach is interesting, but far from definitive. It's a good way to find low hanging fruit, but even in this capacity SQLMap does not excel. It is worth noting that if you manually feed SQLMap URL's and parameters it
does a much more successful job of exploiting vulnerabilities. However, it is worth noting that even if you explicitly tell SQLMap parameters to use in the login form it will still fail to exploit them:
SQLMap is very good at exploiting certain kinds of SQL injection vulnerabilities. However, if the vulnerability is non-standard or requires parameters outside of SQLMap's capabilities SQLMap will incorrectly report that the vulnerability does not exist.
Although this approach to evaluation is not completely without merit, one can clearly observe that a code level analysis is much more effective. SQLMap is a very handy tool once vulnerabilities have been identified, but even in certain cases, such as with
the login form, SQLMap will fail to exploit vulnerabilities that users can confirm and exploit by hand. Perhaps this is a good thing, as it limits the danger posed by SQLMap to many applications and limits it's effectiveness in the hands of script kiddies.
Like most web application evaluation software SQLMap does a great job identifying and exploiting a very narrow range of vulnerabilities but fails to give analysts an accurate vulnerability assessment.