Using Burp’s session Handling Rules to insert authorization cookies into Intruder, Repeater and even sqlmap

The problem….

Recently, NVISO was tasked to do a penetration test on a web application that had very short authenticated sessions and that implemented anti CSRF tokens. This presented a unique challenge, as most of our automated tools and techniques had no reliable way of working as the base requests that were being used as entry point, always contained invalid cookies as the lifetime of a session was about 2 minutes and the anti-CSRF token was unique per request (as it should be). So, we needed to find a way to bypass these restrictive sessions!

Burp Session Handling Rules to the rescue!

Fortunately for us, Burp Suite provides a solution for this called “Burp Session Handling Rules”. Using this functionality, it is possible to trigger certain requests automatically given a certain condition. In this case pseudocode for this problem would look a little like this:

IF ("session failed" in response.body OR HTTP.STATUS.CODE == 403 ): re-authenticate

Here is an example on how to achieve this:
in Burp, go to the “project options” tab and choose sessions

Burp Session rules

In the first section of the screen you should now see a standard rule called “use cookies from Burp’s cookie jar“. Keep this one, and add your own custom rule. In the rule actions click the “Add” button and choose Check session is valid.

Burp rule action

Once you have set your rule action, edit it by selecting the action and pressing the Edit button. You should be redirected to the Session handling action editor.

Here you can specify which request should be ran to check if the session is still valid or not. In our use case, the current request will tell us using the error body “session failed” that our session is not valid anymore, which is why the “Issue current request” is ticked.

It is for the same reason that the “Response body” option is ticked and we instructed Burp Suite to check if the string “session failed” is in our request response. If this is the case we will run the re authentication macro.

Our rule is now finished, and will now execute the reauth macro every time a response comes back that contains the text “session failed”.

Burp macro

When adding a macro, you will be redirected to a pop up screen with your HTTP history captured by Burp Suite. You will now have to choose all the requests that are relevant to your applications authentication flow Pro tip: highlight your authentication calls in the proxy history tab, this will make them easier to find.

Burp Suite will automatically trigger these calls and store the cookies in Burp’s cookie jar. After you added all your calls, you can test the macro using the “Test macro” button on the right side corner of your screen.

Define your rule scope

Now that the rule and macro(s) are created, it is time to define where you want to use them. Back in the session rules overview screen (where we defined our rule), edit the rule you created. and click the scope tab:

In this tab you can select where to use your rule, in this case I opted to use it everywhere except the Proxy itself and the Extender. I also ticked the box use suite scope because I only want this rule to be executed on my target scope and not everywhere.

Okay that is great, but what about sqlmap?

Now that the everything is set, time to throw sqlmap in the mix. In order for this to work, you’ll have to tick the “Proxy” box in your rule scope. after that all you have to do is launch sqlmap with your request you want to fuzz and the following option:

--proxy https://<BurpIp (usually 127.0.0.1)>:<BurpPort>(usually 8080)

sqlmap will tell you that it detected session cookies, and will ask you if you want sqlmap to update them automatically. Say No, as burp will do the heavy lifting for you!

Conclusion

As we described, the Session Handling Rules functionality in Burp can be tremendously useful when working with web applications that implement restrictive authentication schemes, with sessions expiring quickly. By setting up a few simple rules, guided by the GUI, sessions can be kept authenticated while performing your (automated) testing, even outside of Burp in your own favorite tools, including sqlmap!

Do you have other tips on dealing with sessions in your own penetration tests? Don’t hesitate to share them in the comments!