Burp Suite is one of the best tools available for web application testing. Its wide variety of features helps us perform various tasks, from intercepting a request and modifying it on the fly, to scanning a web application for vulnerabilities, to brute forcing login forms, to performing a check for the randomness of session tokens and many other functions. Burp Suite Enterprise Edition The enterprise-enabled web vulnerability scanner. Burp Suite Professional The world's #1 web penetration testing toolkit. Burp Suite Community Edition The best manual tools to start web security testing. View all product editions. Tea Break - Burp Suite extension to increase productivity among bug bounty hunters and security researchers while prompting to take break after set time to avoid burnout and health issues. Turbo Data Miner - This extension adds a new tab Turbo Miner to Burp Suite's GUI as well as an new entry Process in Turbo Miner to Burp Suite's context menu. In the new tab, you are able to write new or select existing. Basically, for Black Box or Gray Box Pentester's often need to define their scope while testing for a web application. Web application URL's IP addresses Admin or Non-admin Database type that's being used by the application (ORACLE, MySQL, etc.) Now, lets see the differences between Burp Suite Free and Professional. In Burp Suite Free: Most of the Burp Suite's Pro functionality is enabled in.
I’ve been a little obsessed with the session handling tool-set that Burp Suite provides. I’ve been running into web applications that aggressively tear down (de-authenticate) sessions for any number of given reasons. Could be the volume of requests sent, malicious input, time-based, accessing a certain section of the app, or perhaps some custom algorithm that’s causing it. At the end of the day I don’t really care and just want to ensure that when I automate traffic via Burp, my requests are hitting my target application in an authenticated manner.
So yeah… I’ve been a little obsessed with session handling and just wrapped up looking at the following three things that have been on my mind recently.
- General concerns about how aggressive de-authentication mechanisms affect comprehensively scanning applications for vulnerabilities.
- Pushing various tools through Burp’s proxy and having burp maintain an active session regardless of whether the selected tool maintains a cookie jar.
- Working with Burp Extensions.
Note the emphasis on the end of the second bullet point. I have absolutely no desire to troubleshoot and deal with multiple cookie jars.
On my last engagement I worked with an application that provided me with a chance to look at all of these things together in a real-world scenario. The application in question produced a false-positive SQL Injection vulnerability during my scanning activities. One of those findings that your gut tells you is a false positive but you don’t necessarily want to brush off. It was thought to be some form of Blind SQLi that only produced a difference in the way the link toolbar was laid out. No explicit database or error output was provided. Just a Boolean in terms of page output.
The thought-to-be-vulnerable input was a cookie. Wanting to explore this further and not having the time to poke at it manually, I set out to use SQLMap to test the input and see if a vulnerability actually existed. Knowing that the application was pretty aggressive at de-authenticating sessions, I pushed the traffic SQLMap generated through Burp’s proxy in order to leverage Burp’s session handling rules to keep me authenticated. Nothing too crazy. The only compensating factor, outside of the macros & session handling rules needed to test the validity of the current session (and any subsequent re-authentication), required for this was to instruct Burp not to update the cookie in question during any requests. As in, pass the value provided by SQLMap through all of the session-handling rules untouched.
The following figure details the settings used to exclude the vulnerable cookie from being updated by the “Session Check & Repair” macro I was using. This was a request whose authenticated response was as lightweight (small) as I could find in my proxy history. It’s issued before every automated request to ensure an authenticated session is being used. If the test produces an invalid session, another macro is run to re-establish an authenticated session with the application. Yup, this causes a lot of requests but stealth is/was not a concern for this type of assessment.
This rule’s only goal is to establish a valid session state. The underlying macro updates the Cookie Jar but does not alter the current request being issued by our targeted efforts (aka SQLMap requests) as a subsequent rule was already in place to handle this.
Another configuration is necessary in the session handling rule that applies up-to-date cookies in the Cookie Jar to the current request. We want the payload sent by SQLMap to not be altered. Again, the vulnerable input was a cookie so we don’t want this session handling rule trouncing on our test payloads.
With these concessions made, I placed a recent, up-to-date version of the vulnerable request into a text file, marked the appropriate insertion point, and had SQLMap fire away at it. An example of a request file used for this would be something like:
And a simple SQLMap command something like:
Pretty straight-forward if you’ve spent any respectable length of time using SQLMap.
So long story short, I was able to work through testing the URL thought to contain a vulnerable input using SQLMap and have my state maintained by Burp Suite. Nothing too overwhelmingly complicated but I was happy to see my session maintained during my testing efforts. Mission accomplished!
This got me thinking about how I might approach a similar scenario where an application was aggressively de-authenticating me and I wanted to ensure the cookie being tested was being updated by any applied session handling rules. The caveat from the above example was that Burp was not updating the cookie being tested. The base value was being taken from the request file used by SQLMap and passed through all of the session handling rules unchanged.
In this new scenario, I want to pick an insertion point (the beginning or end of the cookie value) and prepend/append payloads to the targeted, updated cookie value. As in, I want the application to have the opportunity to work with a valid cookie in conjunction with the test payload. I know this probably isn’t a massively important issue as most applications don’t maintain state based off of numerous cookies. Regardless, I wanted to go down this rabbit-hole and work through how I might solve this issue using Burp Suite’s Macros, Session Handling Rules, and Extensions.
After a lot of trial and error I worked up a fairly elegant way to accomplish this. By sending two extra inputs (GET/POST parameters or cookies) I can instruct a Burp extension to target a particular cookie, apply a given payload to it, and then strip the extra inputs from the request prior to sending it to my target. This allows a request to work through the applied session handling rules before prepending/appending a given payload to the targeted cookie.
Unknown Host Burp Suite Movie
I tested this against a generic blind SQL injection (with a vulnerable cookie) proof-of-concept I had in my lab. I edited the poc such that it required authentication and made it de-authenticate my session every few seconds. Despite the aggressive session termination, SQLMap was successfully able to identify the injection point using multiple different payloads. Score!
The session handling rules looked like the following.
Remember, this is all going through Burp’s proxy so make sure to configure all three rules appropriately in their “Tools Scope” sections.
The “Session Check & Repair” rule is configured the same way it was discussed above. This is merely a request that uses up-to-date cookies from the Cookie Jar and attempts to make an authenticated request to the application. If it fails, it fires off another request to re-authenticate to the application. The entire process updates cookies in the Cookie Jar but does nothing to alter the current request being sent through the proxy.
The cookie jar rule should be self explanatory.
Unknown Host Burp Suite Reviews
And lastly, the “Cookie Attack” rule only invokes the extension I wrote.
Both provided inputs are stripped from the final request sent to the target. They are only used by the extension. The extension has a simple tab interface to control the inputs. I could have made the input that points at the target cookie part of this interface but chose to leave it “on the command line” so you can script SQLMap to rotate through cookies. Again, the two inputs are used by the extension to ingest the name of the targeted cookie and the payload(s) that will be applied to it.
After the extension is enabled and all the configurations are finished, SQLMap can be leveraged in the following different ways.
Creating a Request File
Place the following into a text file before feeding it to SQLMap.
You can also remove the cookies from the request file and input them on the command line.
You can change the verb to POST and move the inputs to either GET/POST parameters.
Using only the Command Line with Cookies
The following calls to SQLMap work and do not require a request file.
Using only the Command Line with GET/POST Parameters
The following calls to SQLMap also work.
Note that you do not need to mark inputs when using GET/POST parameters. Leave the payload parameter blank when doing so.
At the end of the day, this extension could be used by any tool that can push requests through Burp Suite. It wouldn’t be difficult to make it act on standard GET/POST parameters, as well.
Something to note about the following Python extension code. I utilized some debugging tools creating by Michał Bentkowski (@securitymb) found at the following link.
I was introduced to these tools by JakeMiller (@laconicwolf) via the following blog post.
These tools really help out when your extension is tossing errors around. They definitely made my life easier. Cheers, guys!