Home > Blog > Repeating requests on-the-fly with Burp

Repeating requests on-the-fly with Burp

Gepubliceerd door admin on februari 14, 2015

When testing a web application’s behavior it often makes sense to re-submit web requests within a different context (using a different session ID or adding a cookie flag or parameter). The idea is to explore the website whilst logged in as a privileged user in one session and creating a site map of all available application functions and re-crawl in another session, as an unprivileged or unauthenticated user. This strategy will quickly reveal problems where restricted functions inadvertently are exposed to unauthorized users. Another example is to test for hidden parameters that enable 'debug' mode which allows for bypassing authorization schemes.

Let’s suppose we have a hunch that the tested application behaves differently when a cookie value of ‘debug=true’ is added and in order to test this we want to re-submit each request with the added cookie to observe any 'hidden' application features.


Burp has an excellent feature to automate this process with the 'Compare site maps function' which can be found in the context menu of the Site map under Target

Repeating requests with Compare Site maps

First create a site map of the normal application behavior, adding the application to Burp's target scope. Log in and explore the application's function by clicking around. Next log out of the application which has the side-effect of switching to the context of an unauthenticated user. You may want to remove the related URLs for logging in and logging out from the target scope in order to prevent things messing up when we ask Burp to repeat the requests.

Next add a Session Handling Rule under the Option tab with a Rule Action: Set a specific cookie or parameter value. The name and value should be 'debug' and 'true' respectively:


Choose 'Compare site maps' in the context menu of the Site map tab. This will guide you through a wizard that lets you configure two site maps to compare. Select the current site map containing the original requests. Choosing 'Request map 1 again in a different session context' will accomplish our goal of re-submitting previously mapped requests whilst adding the cookie as specified in the Session Handling Rules. Burp will present the resulting output and highlight the differences. 

Repeating requests on-the-fly

Sometimes you might find yourself in the situation where you don’t want to create a site map first and bombard the application with re-issued requests but instead take a more surgical approach of re-submitting each request (after a slight modification) on-the-fly, like DigiNinja suggests in this Tweet:


The previously used Session Handling Rules approach seems a good candidate for our needs. However, you may have noticed that when manually browsing the site the rule to add the cookie is not applied. In order to fix this you need to make sure that Proxy is selected in the Tools Scope section of the handling rule:


The problem is that Burp will apply the handling rule before each request and will not issue the original unmodified request.

Here is a simple trick: Just add a Rule Action:Check Session is valid just above the rule that modifies the cookie and enter a bogus value (i.e. one that never matches) in the Look For Expression field. Also, select Match indicates: valid session. This will trigger our first (original) request but since Burp will assume the session is invalid it will continue processing the next rule, hence adding the cookie and re-submit the request.


The sessions tracer will confirm that this works as expected:


There is one catch: the original request does not show up in the Proxy History. This is because Burp considers the ‘session validation’ request useless clutter. Fortunately there is a simple workaround: the BApp Store contains an extension called ‘Custom Logger’ that shows both the original and modified cookie requests and responses.