Fuzzing and sqlmap inside CSRF-protected locations (Part 1)

– @dave_au

Hi all, David here. I was recently testing a web app for a client written in ASP.NET MVC. The developers are pretty switched on, and had used RequestValidation throughout the application in order to prevent CSRF. Further to this, in several locations, if there was a RequestValidation failure, they were destroying the current session and dropping the user back to the login form. Brutal.

I didn’t think that there would be any injection issues in the app, but I needed to test all the same and this presented an interesting challenge – how to fuzz or sqlmap on target parameters within the CSRF-protected pages of the application.

If I opted for a manual approach, the process would look like this:

  1. Login to the application
  2. Navigate to the page under test
  3. Switch Burp proxy to intercept
  4. Submit and intercept the request
  5. Alter the parameter under test in Burp, then release the request
  6. Observe results
  7. Goto 1

This would be incredibly slow and inefficient, and wouldn’t really provide a way of using external tools.

I scratched my head for a while and did some reading on Buby, Burp Extender and Sqlmap tamper scripting until I finally came across an article from Carstein at 128nops which led me to further reading by Dafydd on the Portswigger Web Security Blog. Turns out that Burp suite can do exactly what I needed, out of the box, so I thought I’d put together a step-by-step for how I solved the problem.

Fuzzing (with Intruder) inside CSRF

Note: Intruder has built-in recursive grep functionality that can be used in some circumstances to take the CSRF token from one response and use it in the following request (&c.)[1]. This wasn’t much good to me, since the session was being destroyed if CSRF validation failed.

In Burp terminology, you need to create a Session Handling Rule to make Intruder perform a sequence of actions (login, navigate to page under test) before each request.

Go to the “Options” tab, and select the “Sessions” sub-tab. “Session Handling Rules” is right at the top.

screenshot1

Click the “Add” button to create a new Session Handling Rule. The Session Handling Rule editor window opens. Give the rule a meaningful name, then click the “Add” button for “Rule Actions” and select “Run a macro” from the drop-down.

screenshot2

This opens the Session Handling Action Editor window…

screenshot3

In this window, click the “Add” button next to “Select macro:”. This opens the Macro Editor and Macro Recorder windows (shown a further on). Now that Burp is set up and waiting to record the sequence, switch over to your web browser. In a new window / session (making sure to delete any leftover session cookies), navigate to the login page, login, then navigate to the page within the application where you want to be doing fuzz testing. Once you are there, switch back over to Burp. The Macro Recorder should show the intercepted requests.

screenshot4

Select the requests that you want to use in the macro and click “OK”. This will close the Macro Recorder window.

screenshot5

In the Macro Editor window, give the macro a meaningful name and look through the “Cookies received”, “Derived Parameters” and “Preset Parameters” columns to check that Burp has analysed the sequence correctly. When you’re happy, you can test the macro out by clicking the “Test Macro” button. If everything looks alright, click “OK” to close the Macro Editor window.

screenshot6

Almost there.

Back in the Session Handling Action Editor window, you should be OK to leave the other options for updating parameters and cookies as-is. Click “OK” to exit out of here.

Now, back in the Session Handling Rule Editor window, you’ll see your macro listed in the Rule Actions…

screenshot7

Before you close this window, switch over to the “Scope” tab and alter the scope for the rule to be just for Intruder and “Include all URLs”. (If you want to be more specific, you could specify the URL that you wanted the rule to apply to, but I just put it in scope for all of Intruder, and remember to turn the rule off when I’m not using it. This becomes more important in Part 2 of this post.) Then close the Session Handling Rule Editor window.

screenshot8

Your session handling rule is now defined.

Next, go back over to Burp’s proxy and send the request that you want to fuzz over to Intruder in the usual way.

screenshot9

In Intruder’s “Position” tab, you’ll want to clear all of the injection points except for the one that you want to specifically fuzz test. Session cookies and any CSRF tokens (in cookies or hidden form fields) will be populated automatically by Intruder from the macro sequence.

screenshot10

Set your payloads and other options as required. If the application is sensitive to multiple concurrent sessions for the same user, you will need to reduce the number of threads to 1 in the “Options” tab.

Then start Intruder. You will almost certainly notice that Intruder runs slowly; this is to be expected when you consider that it is going through a new login sequence for each request.

To fuzz different parameters on the same page, just go back into “Positions” and choose the next target.

To fuzz parameters on a different page, you will probably need to go back into your Session Handling Rule and edit your macro (or define a new macro) that logs in and navigates to the new target page.

In part 2 of this post, I’ll step through a slightly different scenario where we use an external tool (sqlmap), proxied through Burp, with a Session Handling rule running on Burp’s Proxy.

Published by

David Taylor

Twitter: @dave_au

One thought on “Fuzzing and sqlmap inside CSRF-protected locations (Part 1)”

Leave a Reply

Your email address will not be published. Required fields are marked *