Exploring SQL Injection via POST with SQLmap


SQLMap is a SQL Injection Fault Scan script. We already posted a lot of material on the subject in the blog, and even how to identify these faults manually and with automated scripts like Uniscan, Arachni, Nikto and etc, in addition, one of the first blog posts was about exploiting SQL Injection failures via GET. I recommend that you study these examples first to better understand what is going on here.

Performing the Automated Test

First we will scan the application for flaws.

 # uniscan -qdws testphp.vulnweb.com/

After the scan is finished, uniscan will report to us with the vulnerabilities and information found in the URL we are looking at. You can learn more about Uniscan by reading a post I made some time ago, you can find it by clicking here .

Conducting the test manually

The automated test is known to generate a lot of noise in the server, being easily detectable. I know it’s possible to do it through Proxy. We’ve done an article explaining how, but that’s not what I’m talking about, it’s up to the target to know that someone is attacking the app and taking preventative measures that can slow or damage the attack.
The best way is to do it manually by exploring the forms of the site manually by performing SQL Injection attacks on hand.

Proxy Setup Burp suite

First let’s open the Burpsuite.
Burpsuite is a proxy that helps us with the answers of the server to the browser and vice versa, generating a history for analysis of everything we send and receive via POST and GET,

Project Link: https://portswigger.net/burp/

Now we’ll need to open Burpsuite and Firefox (or Iceweasel).
With the BURP SUITE open, go to the browser’s network settings, point the proxy to your localhost on port 8080. In this way, it will forward all requests and responses to port 8080 of our machine that will be analyzed by the Burp Suite.

Let’s do the analysis on a registration form


Let’s enter Boolean data in the form fields to try to generate some SQL errors to identify an exposed fault.

We can test all the fields one by one or all at once by exploring the fields so that they return us SQL syntax errors

Performing the scan via POST Data

Unlike interpreting the entire response of HTTP and putting it in a text file, we will only take the post data, that is, the information we send to the server, and perform the injection only with that information. In some cases, this technique can avoid a waste of performance.

Now open go to the Open Burpsuite Proxy tab and select HTTP History. Here it will mark all the requests that the software has captured and will interpret whether it is POST or GET.
Let’s go in this first request via the POST method and we will analyze it. She was the one we sent through the browser to the server, clicking on it we can extract important information about what was sent and interpreted.

In it we can identify that the form located in the /signup.php page was sent via post to the file /newuser.php, in case it is the file that caused the error, and it is in it that we must carry out the attacks via POST with SQLmap

We see that we’ve sent a handful of information, which generated the SQL error on the page. More precisely


So it’s this handful of information sent that caused the error, and it’s what we’re going to use to make the attack, so we’ll put it in the –data parameter in the SQLmap syntax

Come on

#sqlmap -u http://testphp.vulnweb.com/secured/newuser.php --data="uuname=nanoshots+%27or+1+%3D+%271%27&upass=&upass2=&urname=&ucc=&uemail=&uphone=&uaddress=&signup=signup" --dbs

Continue with the normal tormapinas of SQLmap opting or not for the test of the other variables besides the uuname that we applied the injection, in the end it will return you the databases found.

Now let’s explore:
First we will perform a Dump of all the tables in the database “acuart” that we found, for this we will specify the bank with the -D parameter and dump the tables with –tables

 sqlmap -u http://testphp.vulnweb.com/secured/newuser.php --data="uuname=nanoshots+%27or+1+%3D+%271%27&upass=&upass2=&urname=&ucc=&uemail=&uphone=&uaddress=&signup=signup" -D acuart --tables

Let’s check the users table by dump the table columns

 sqlmap -u http://testphp.vulnweb.com/secured/newuser.php --data="uuname=nanoshots+%27or+1+%3D+%271%27&upass=&upass2=&urname=&ucc=&uemail=&uphone=&uaddress=&signup=signup" -D acuart -T users --columns

Now finally we will perform the information dump of the columns, name, uname and pass

 sqlmap -u http://testphp.vulnweb.com/secured/newuser.php --data="uuname=nanoshots+%27or+1+%3D+%271%27&upass=&upass2=&urname=&ucc=&uemail=&uphone=&uaddress=&signup=signup" -D acuart -T users -C 'name,uname,pass' --dump

Performing attack via HTTP response

Again in the Burp Suite, let’s go to the POST request we made to the server. Copy the entire content of the request and paste it into a file called post.txt. This method is useful when the browser sends, receives, and validates various types of information in the case of cookies and sessions. All content submitted, including cookie information, sessions, information, schedules, permission levels will be sent.

Detail: Although this is the easiest method, it is worth mentioning that it is good to use it only when it is really necessary, that is, when sending by POST date is not enough, because its performance tries to be lower and Tends to generate almost triple the noise in the application.

Copy the entire contents of the POST Request

And with your favorite text editor, create a file called post.txt and paste the copied content into it. Then close the file.

 # vim post.txt

Now we will carry out the attack with reference only to this file. If we analyze it well, it contains all the information necessary to carry out the attack manually. We have the source page, the target page, the type of method used, and the variables used to exploit SQL Injection failure.

Let’s run the SQL map with the -r parameter, which is the read parameter and point to the file we created earlier

 root@fidelis:/home/matheus# sqlmap -r post.txt --dbs

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s