SQLMap –data trick

I’ve recently learned a new trick about sqlmap that I think is worth sharing.  If you already know this, power to you, if not, hope that this helps you out.

The scenario where I learned this trick was as follows: I was trying to run sqlmap against a web form that I identified as being vulnerable to a SQL injection attack.  I ran sqlmap with the usual “–forms” after providing it the web address of the form, and off sqlmap went.  However, as the tool started parsing the code, I immediately kept receiving errors about mal-formed HTML code which would cause sqlmap to error out and quit immediately.   I attempted running the same command a couple more times, all with the same result, and was therefore unable to have sqlmap run against the form field.

Needless to say, I was pretty disappointed because I know the form had an injection flaw.  It was obviously posible to to manually exploit the injection flaw to dump the data out of the DBMS behind the form, but an automated tool such as sqlmap would be able to get the job done much quicker, so I set out on researching how to fix this.  Within about 30 minutes, I found my answer.

I discovered that instead of giving sqlmap the -u URL of the form web page, I should actually give it the URL of the form processing page.  Next, since the information is passed via a POST request, I need to copy the variables and the values sent in the post request, and input that into sqlmap.  To gather all this information, I turned on Burp Suite, navigated to the form processing page, ensured intercept was on, and then submitted data through the form.  Burp suite caught the form processing URL and all data being sent via a POST request.  I copied the URL and set the URL as the -u value for sqlmap.  I also copied the data that was being sent in the POST request, and set the data as the –data value within the sqlmap command.  The last piece of data I used within the sqlmap command (before I gave what I wanted out of the DBMS such as –dbs, or –tables) was the -p switch.  This switch lets me identify specifically which parameter I wan sqlmap to target.  Since I already identified the injection flaw within the form, I just found the variable name that was given to the specific form field which was injectable, and provided it within the sqlmap command.

Edit: Want to be able to just give the request in a single file?  Easily copied from Burp Suite?  Just save the request that burp intercepted in a txt file, and then call sqlmap and pass it the text file using the -r switch.  This will tell sqlmap to read the url and variables from the request file.

To help show what I mean, I’ll use my web page’s login form as a sample target.  If I had to perform the exact steps above in relation to my login page, the sqlmap command would look like (the “-” should actually be a double dash for the dbs and data switch, however it is being filtered at the moment):

 ./sqlmap.py -u http://www.christophertruncer.com/wp-login.php –data=”log=TestUserAccount&pwd=TestUserPassword&wp-submit=Log+In&redirect_to=http%3A%2F%2Fwww.christophertruncer.com%2Fwp-admin%2F&testcookie=1″ -p pwd –dbs

In the command above, I am giving it the login.php page as the page to target.  This is the page the processes the data sent in the POST request made by a browser (in this case, it’s also the page where the form is stored).  The information in the –data switch is the information sent in the POST request to the form processing page.  The -p parameter is the variable that I am having sqlmap target, which in this case is the password field.  Finally, the –dbs switch is given to tell sqlmap once I have injected into the form, return all database names stored on the backend database server.

Once I set the above commands, I ran the sqlmap statement, received no errors, and was able to automate gathering all the data I needed/wanted from the backend database.

Hope this helps in the event anyone comes across a mal-formed html code error within sqlmap!