This is part 2 of a post on fuzzing and sqlmap’ing inside web applications with CSRF protection. In part 1 I provided a walkthough for setting up a Session Handling Rule and macro in Burp suite for use with Burp’s Intruder. In this part, I will walkthrough a slightly different scenario where we use Burp as a CSRF-protection-bypass harness for sqlmap.
Sqlmap inside CSRF
A lot of the process from part 1 of the post is common to part 2. I will only run through the key differences.
Again, you’ll need to define a Session Handling Rule, containing a macro sequence that Burp will use to login to the application, and navigate to the page that you need.
The first real difference is in the definition of scope for the session handling rule. Instead of setting the scope to “Intruder” and “Include all URLs”, you’ll need to set the scope to be “Proxy” and a custom scope containing the URL that you are going to be sqlmapping.
There is a note to “use with caution” on the tool selection for Proxy. It is not too hard to see why – if you scoped the rule too loosely for Proxy, each request could trigger a whole new session login. And then I guess the session login could trigger a session login, and then the universe would collapse into itself. Bad news. You have been warned.
Once the session handling rule is in place, find an in-scope request that you made previously, and construct it into a sqlmap command line.
In this example, I’m attempting an injection into a RESTful URL, so I’ve manually specified the injection point with “*”. I’ve included a cookie parameter that defines the required cookies, but the actual values of the cookies is irrelevant, since Burp will replace these based on the macro.
If it was a POST, you would need to include a similar –data parameter to sqlmap, where Burp would replace any CSRF tokens from hidden form fields. Finally, we have specified a proxy for sqlmap to use (Burp).
Running sqlmap, we start to see it doing it’s thing in the Burp Proxy window.
That’s pretty much all there is to it.
One catch for the Session Handling Rule / macro configuration is that there isn’t a lot of evidence in the Burp tool (Intruder, Proxy, …) that anything is happening. If you are not getting the results that you would expect, the first thing to check is the Sessions Tracer, which can be found in the Session Handling Rules section. Clicking the “Open sessions tracer” button opens the Session Handling Tracer window. If a session handling rule is triggered, the actions for that rule will start to show up in the Tracer window. You can step through a macro, request by request, to see that everything is in order.
In this two part post, I’ve walked through setting up Burp Suite to do fuzzing inside CSRF-protected applications, both with Burp’s own Intruder tool and using an external tool (sqlmap).