Reissuing requests with Burp Repeater – The Daily Swig

In this tutorial, you’ll use Burp Repeater to reissue an interesting request over and over again. This lets you study the target website’s response to different input without having to intercept the request each time. This makes it much simpler to probe for vulnerabilities, or confirm ones that were identified by Burp Scanner, for example.

If you haven’t completed our previous tutorial on getting started with Burp Proxy, we recommend doing so before continuing.

Sending a request to Burp Repeater

The most common way of using Burp Repeater is to send it a request from another of Burp’s tools. In this example, we’ll send a request from the HTTP history in Burp Proxy.

Step 1: Launch the embedded browser

In Burp, go to the Proxy > Intercept tab and make sure interception is switched off. Use the embedded browser to access the following URL, logging in if prompted:

https://portswigger.net/users?returnurl=/web-security/information-disclosure/exploiting/lab-infoleak-in-error-messages

When the page loads, click Access the lab to launch your own instance of a fake shopping website. This may take a few seconds to load.

Step 2: Browse the target site

In the browser, explore the site by clicking on a couple of the product pages. Notice that there aren’t any additional functions to audit, just a series of similar product pages.

Step 2: Study the HTTP history

In Burp, go to the Proxy > HTTP history tab. To make this easier to read, keep clicking the header of the leftmost column (#) until the requests are sorted in descending order. This way, you can see the most recent requests at the top.

Step 3: Identify an interesting request

Notice that each time you access a product page, the browser sends a GET /product request with a productId query parameter.

Let’s use Burp Repeater to look at this behavior more closely.

Step 4: Send the request to Burp Repeater

Right-click on any of the GET /product?productId=[...] requests and select Send to Repeater.

Go to the Repeater tab to see that your request is waiting for you in its own numbered tab.

Step 5: Issue the request and view the response

Click Send to issue the request and see the response from the server. You can resend this request as many times as you like and the response will be updated each time.

Testing different input with Burp Repeater

By resending the same request with different input each time, you can identify and confirm a variety of input-based vulnerabilities. This is one of the most common tasks you will perform during manual testing with Burp Suite.

Step 1: Reissue the request with different input

Change the number in the productId parameter and resend the request. Try this with a few arbitrary numbers, including a couple of larger ones.

Step 2: View the request history

Use the arrows to step back and forth through the history of requests that you’ve sent, along with their matching responses. The drop-down menu next to each arrow also lets you jump to a specific request in the history.

This is useful for returning to previous requests that you’ve sent in order to investigate a particular input further.

Compare the content of the responses, notice that you can successfully request different product pages by entering their ID, but receive a Not Found response if the server was unable to find a product with the given ID. Now we know how this page is supposed to work, we can use Burp Repeater to see how it responds to unexpected input.

Step 3: Try sending unexpected input

The server seemingly expects to receive an integer value via this productId parameter. Let’s see what happens if we send a different data type.

Send another request where the productId is a string of characters.

Step 4: Study the response

Observe that sending a non-integer productId has caused an exception. The server has sent a verbose error response containing a stack trace.

Notice that the response tells you that the website is using the Apache Struts framework – it even reveals which version.

In a real scenario, this kind of information could be useful to an attacker, especially if the named version is known to contain additional vulnerabilities.

Go back to the lab in your browser and click the Submit solution button. Enter the Apache Struts version number that you discovered in the response (2 2.3.31).

Congratulations, that’s another lab under your belt! You’ve used Burp Repeater to audit part of a website and successfully discovered an information disclosure vulnerability.

In this tutorial

1. Initial Installation
2. Intercepting HTTP traffic with Burp Proxy
3. Manually reissuing requests with Burp Repeater
4. Running your first scan

Source of this news: https://portswigger.net/burp/documentation/desktop/getting-started/reissuing-http-requests