SQLMap on a seqential form

Question

There is a certain form that gets posted over POST. The form has some form elements. I am doing a pen-test on the application that has this form. The form values are being stored in a certain database. It's a PHP application and the interesting part, that I learned through some discussions with the developer who own that form, is that prepared statements are not being used to process the respective queries to handle the POST data coming through the form.

This made me suspicious and hopeful of finding a potential SQLi.

I am running SQLmap including a valid session and other form data. However, through a -v 5, I realized that SQLMap is actually getting a 302 redirect response for every single request. Through some further investigation, I realized that the form in question (say form3) is obtained after I follow the sequence

form1 --> form2 --> form3.

If I try accessing the form3 directly (even through the browser, post login of course), I am redirected back to form1. So I need to follow the above sequence strictly to be able to actually submit form3 data to be processed.

Is there a way I can automate this sequence in SQLmap? Or is there any way that I can test for the existence of a SQLi on form3 given the above scenario ?

Answer 1

Generally if you find an SQLi you don't need to map the whole database to prove the vulnerability, actually very little information is needed as proof. SQLmap is a great tool for what it's meant for, mapping databases, but it does have some limitations in usability.

Generally I'd advice to use a web application scanner to look for SQLi vectors, for example the OWASP ZAP proxy scanner. But in this case even scanners might be hard to configure to always do a series of valid requests before the target form is sent. Scanners have a large set of ready-made SQLi payloads and response analysis techniques and this is definitely a resource that should be used.

If all fails then a simple script and a list of SQLi strings could be used to do the job. Automating the two earlier forms to be sent with valid static input is easily done in most languages, especially if you don't need any part of the response. After this you can send the third form with an injected parameter. Now you can repeat this process for all the payloads until you get an interesting response. Anything slightly out of the ordinary is an interesting response.

Often an error message, a slightly different response or a difference in query duration is enough to mount a blind SQLi attack. This means that all the proof needed to show that the vulnerability exists is a series of (in this case) three requests that end up responding in a way that discloses information about the querying process. Given this one proof-of-concept series of requests an attacker could easily write a script that slowly extracts the whole database, you, as a tester don't actually need to do this.

If you are an experienced programmer you could leverage the libraries that are a part of the SQLmap project.