In this second part of the Burp Suite series you will lean how to use the Burp Suite proxy to collect data from requests from your browser. You will explore how an intercepting proxy works and how to read the request and response data collected by Burp Suite.
The third part of the guide will take you through a realistic scenario of how you would use the data collected by the proxy for a real test.
There are more tools built in to Burp Suite that you can use the data that you collect with, but those will be covered in the fourth and final part of the series.
Burp Suite’s proxy is what is referred to as an intercepting proxy. That means that all traffic that comes through the proxy has the option to be caught and manually passed along by the proxy user. This allows you to manually inspect each request and choose how to react to it.
This can be good on a per-case basis, but it can also be very obvious to a user that something is wrong if you are using this as part of an actual professional pentest.
So, if you are just looking to capture a large amount of traffic at once and either monitor it as it flows or comb through it later, you can turn off the intercepting feature of the proxy and allow traffic to flow freely.
To toggle interception, head to the “Proxy” tab on the top row of tabs, then to the “Intercept” tab on the second row. By default, the third button should read, “Intercept is on.” Click on it to toggle interception on and off. For right now, leave it on.
Over in Firefox, navigate to your WordPress site at
localhost. You should see the spinning “loading” icon on your tab and Firefox going nowhere. This is because the request to your web server has been caught by Burp’s proxy.
Check your Burp Suite window. There will now be request data in your “Intercept” tab. This is the information that was sent from the browser to your WordPress server requesting the page that you navigated to. You won’t see any HTML or anything that would be returned from the server. You can get response data by heading to the “Options” tab under “Proxy” and checking “Intercept responses based on the following rules” and “Or Request Was Intercepted.”
In any case, you can take a look at the new tabs on the “Intercept” screen. Raw, Params, and Headers will be the most useful to you. They all essentially display the same data, but do so in different formats. Raw displays the raw request as it was sent. Params shows any parameters sent with the request. This is often where useful information like login details will be easily found. Headers will only show the request headers. This is useful when the request has HTML with it.
To forward the request to the server, press the “Forward” button. If you set up Burp to intercept the response, you will now see that filling your screen. Otherwise, the data will disappear when it’s sent off to the server.
Switch interception off. For this next part, just monitor traffic as it comes through the proxy. Browse around your dummy WordPress site. If you need to, find some nonsense content to fill the site up with, so you can see what it looks like to see more realistic traffic flow through Burp Suite.
All of the traffic that goes through Burp Suite’s proxy can be found on the “HTTP History” tab under “Proxy.” By default, the requests are listed in ascending order. You can change this to see the latest traffic on top by clicking the
# at the top of the request ID column on the far left of the table.
Be sure to spend some time clicking around your WordPress site, and watch Burp Suite as you do. You will see the list of your HTTP history filling up quickly. What may come as a surprise is the amount of requests being collected. Your browser will generally make more than one request per click. These requests can be for assets on the page, or they can come as part of redirects. Depending on themes or fonts that you have installed, you may even see requests going out to other domains. In a real world scenario, this will be extremely common, since most websites make use of independently hosted assets and content delivery networks.
Looking at a Request
Pick a request to take a look at. It’s best if you can find one with a MIME type of HTML. This means that it was a request for one of the website pages and contains some HTML for you to take a look at.
When you first select one, you will be shown the request in its raw form. The raw request will hold all of the information sent from Firefox to the server. This is just like the request that you intercepted. This time, you’re looking at it after the fact instead of in transit.
You can definitely use the raw request to pull key information from, if you’re more comfortable with it, but the Params and Headers tabs will prove much more simple to read in most cases. Take a look at the params. This will contain any variable information that the browser needs to pass to the browser. In the case of many basic HTML pages, it’ll probably just contain cookies. When you decide to submit a form, the information contained in the form will appear here.
The headers contain information about the request itself, its target, and your browser. The headers will specify if the request was a GET or POST request. They will also tell you what server or website is being contacted. The request will include browser information for the server to use and which language it should respond with. There is some overlap, and you’ll see some cookie information here too. It also may be useful to see which information or file types the browser will accept back from the server. Those are listed under “Accept.”
Looking at the Response
Click on the “Response” tab. This is all very similar to the request in terms of what type of information is available. Just like the request, the raw response is loaded with information in a fairly disorganized format. You can use it, but it’s better to break it down with the other tabs.
Instead of finding browser information in the headers, you will instead find server information. The headers will generally dell you what type of HTTP response was received from the server. You will also find information on what type of web server is running and what backend language is powering the page. In this case, it’s PHP.
The HTML tab will contain the raw HTML that the server sent the browser to render the page. You may or may not find anything interesting here, depending on what you’re looking for. This isn’t too different than viewing a page’s source from your browser.
Alright. You’ve installed and configured Burp Suite. You’ve proxied requests from Firefox through it and intercepted them. You’ve also allowed Burp Suite to collect multiple requests and evaluated them for useful information.
In the next guide, you’re going to put this to use to gather information for a brute force attack on WordPress’s login page.