Testing web applications for security flaws is sometimes difficult due to the peculiar behaviors of applications. One curious behavior is an application that modifies and validates cookies on a per-request basis—that is, every new request sent to the application must contain the valid cookie sent in the previous response. This implementation does nothing to prevent cross-site request forgery attacks and it makes the life of a penetration tester more difficult because it prevents us from using Burp’s Repeater tool, for example, to quickly perform fuzzing on a request and use Burp’s Intruder tool to perform a customized automated scan. Thankfully Burp’s cookie-jar feature comes to the rescue.
Although it appears odd to add a new cookie value in every request, this step successfully prevents the “parallel” submission of multiple requests to an application. If multiple simultaneous requests with the same cookie value are sent to the app, only one will succeed; the others will be rejected because the app expects a new cookie value once the previous value is used. This restriction acts as an effective control against exploiting race conditions present in the application code without actually modifying the code to fix this vulnerability. (Read more about Testing Race Conditions in Web Applications.)
The scenario
Let’s consider a demo application that displays this behavior. The demo adds the following header in the HTTP response:
set cookies: uniqueID=Xyzabc123mnq
The next request should have this new uniqueID cookie value to succeed because the value of uniqueID is validated at the server and the new value of uniqueID is generated and included in the response header. If the recent uniqueID value is not included in a subsequent request, the application does not display the expected behavior.
This app mechanism introduces a new challenge to manual testing. While using Repeater, the cookie value from the current response needs to be manually added to the next request, which defeats the purpose of using the Repeater for fuzzing. Using Intruder on any post request also resulted in only one request being tested successfully.
This implementation does not affect browsers because the updated cookie values are included by default in the subsequent request. Burp tools such as Repeater, Intruder, etc. do not have this property by default. To effectively test these websites using Repeater and Intruder, we need to use Burp’s cookie-jar and session-handling features.
The following demo with Burp’s Repeater demonstrates how to do this.
Request 1
Analyze the demo application using Repeater.
Request 2
Copy uniqueID value 101 from the response and use it for the next request.
Request 3
Sending the same request again without updating the uniqueID cookie value results in the following application response.
In this and similar OWASP test cases if you are testing for data validation/authorization, you need to manually copy the value of uniqueID cookies from the responses and modify them in the next Repeater request. This step needs to be carried out for every payload that you want to test.
That can take a lot of time!
Similarly, while using Intruder to test payload positions for multiple cross-site scripting or SQL-injection payloads, the first request from Intruder will be tested successfully and the rest will be rejected by the application—because Intruder will not include the latest uniqueID cookie value in subsequent requests.
To solve this problem, Burp should automatically copy the cookie values from Repeater and Intruder responses and send the updated cookies value in the subsequent request.
The solution
Burp maintains a cookie jar that stores all of the cookies issued by websites you visit. The cookie jar can be updated by tools such as proxy, Repeater, Intruder, Scanner, and Extender. Using Burp’s cookie-jar and session-handling rules, we can instruct Burp to include the latest cookies values while sending requests through Repeater and Intruder.
For example, if Repeater is selected in the cookie jar option and the latest request is sent from Repeater, then the cookie jar will contain cookies values that came from Repeater’s responses. We can verify this using the Open Cookies Jar feature.
We need to add the session-handling rule “Use cookies from the session handling cookie jar” and select Repeater/Intruder in the Scope tab. By selecting Repeater/Intruder in Scope, Burp will automatically update outgoing requests with cookies from the cookie jar.
Steps to add rules
For cookie jar:
Navigate to Options->Sessions->Cookies jar
For adding and editing rules:
Navigate to Options->Sessions->Session Handling Rules->Add/Edit
By default with its Spider and Scanner tools, Burp has a “Use cookies from Burp’s cookies jar” rule within Scope.
Default Burp option:
Now click on the Edit option under Session Handling Rules, go to the Scope tab, and add Repeater and Intruder. This will allow Burp to apply updated cookies to the requests from Repeater and Intruder.
Install Logger++ (used to log the requests and responses made by all Burp tools) from the BApp Store, available in Burp’s Extender tool, to view the request (the updated request with cookies values from the cookie jar).
References
https://portswigger.net/burp/help/options_sessions.html
The post Efficient Application Testing With Burp’s Cookie Jar appeared first on McAfee.