This tutorial is yet another introduction to Burp Suite. It explains how to install and use Burp Suite, fundamental tool used by bug hunters (but not only) on daily basis to test web applications.
“Burp Suite created by PortSwigger Web Security is a Java based software platform of tools for performing security testing of web applications. The suite of products can be used to combine automated and manual testing techniques and consists of a number of different tools, such as a proxy server, a web spider, scanner, intruder, repeater, sequencer, decoder, collaborator and extender.”
In order to pass HTTP traffic to Burp from our browser, we will use Foxyproxy an Addon for Firefox and Chrome. Requests made in the browser can be viewed, edited and analysed in Burp to find web application vulnerabilities. Later sections of this tutorial will show how to use Burp Suite for specific tasks so that you can get accustomed to using it.
Before you start reading this tutorial there are some concepts you should probably know:
If you don’t know much about this you can have a read at: http://www.cs.rpi.edu/~kotfid/ne1/CCNA_chapter2.pdf
This 300 pages book can also help you in your journey: http://write.flossmanuals.net/data/messages/afzalkhalil/ccna_studyguide.pdf
There is a very good explanation about HTTP in the “Web Application Hacker’s Handbook” which you can buy on Amazon or check other free sources such as https://www.tutorialspoint.com/security_testing/http_protocol_basics.htm.
Download the following tools:
For Ubuntu open the terminal and run the following commands:
sudo add-apt-repository ppa:webupd8team/java # to add the Oracle’s repository
sudo apt-get update
sudo apt-get install oracle-java8-installer
Open this page in the browser http://www.oracle.com/technetwork/java/javase/downloads/index.html, download the Java JDK and install it.
Install Foxyproxy for Firefox or Chrome and restart the browser.
Download links are:
Click on Foxyproxy’s icon and click “Options”:
Click “Add new proxy”. In the “Proxy details” section → “Manual Proxy Configuration” insert the following values for Server and Port:
In the “General” section, give the proxy a name and select a colour. Then save.
Now start the proxy you just created by right clicking on the Foxyproxy icon and selecting the newly created proxy.
You have downloaded Burp Suite for either Windows or Linux. On windows you can double-click on Burp executable to start it. On Linux you can do the same or download the plain jar file, open a terminal in the folder where you downloaded Burp and run the following command:
java -jar burpsuite_community_v1.7.30.jar
Note. The jar file might be called differently.
Start Burp Suite with default settings.
You can see several tabs: Target, Proxy, Spider, Scanner, Intruder, Repeater, Sequencer, Decoder, Comparer, etc.
This tutorial will explain how to use Burp’s tools in the order you would probably use them at the start of a web application security assessment or bug bounty.
The proxy is used to intercept requests from your browser. These can be modified on-the-fly or can be viewed together with their responses in the "HTTP history" tab.
Click “Proxy” → “Intercept” → “Intercept On” to stop intercepting requests.
If you open a page in the browser with “intercept is on”, Burp will display the request sent from your browser and until you press “forward” or “intercept is on”, it won’t submit the request to the web application’s server and receive a response. What you will see in the browser is a page which keeps on waiting for a response. That’s because Burp hasn’t sent the request yet.
In few more words:
Click “Intercept is on” to turn off interception. This will grab all the requests sent from the browser through Burp’s proxy. Burp will send them to the right destination only if you stop intercepting or if you press the “forward” button which will forward the request to the web server. It is good to have “intercept is on” only when you know that you want to intercept a specific request to change it on-the-fly. The requests will be stored in “Proxy” → “HTTP history” for later user, even if you don’t have “intercept is on”.
If intercept is on and you don’t really want to send the request forward, click “drop”. This will not send the request to the destination. Probably you will see an error in your browser showing that the request was not submitted. Another reason why you would like to you use “drop” is when you want to see how a request is made but not necessarily send it to the web server. For example you have clicked on a “submit” button on the target site and the request has been submitted and intercepted. Now click on “action” → “Send to repeater” (or CTRL+r) and then “drop”. This way the request will be available immediately in repeater for you to modify without prior submitting the original request. You might want to do this in case every request of this type generates a lot of traffic or creates a new entry in a database.
Click “Proxy” → “Options” to see your proxy’s settings.
As you can see the default port used by Burp for its proxy is port 8080. That is the same you chose for Foxy Proxy. If you want to choose a different port or have multiple proxies you can. Just remember to create the same configuration both in Burp and Foxy Proxy. For example you might want to have port 8080 for Foxy Proxy on Firefox and port 8089 for Foxy Proxy on Chrome. You can use the same ports on both browsers if you want.
If you have the following Foxy Proxy configuration: IP: 127.0.0.1 Port: 1337, then you must have the same configuration in Burp Proxy, IP: 127.0.0.1 Port: 1337. This is because the communication goes as follow:
Foxy Proxy makes sure all the requests are sent to Burp’s Proxy.
Installing Burp's certificate in your browser will help you intercepting traffic sent by sites using SSL/HTTPS. The browser will not complain that your connection is not secure if you install Burp’s certificate as a trusted CA authority. You are telling the browser that Burp with its certificate is OK to encrypt/decrypt HTTPS traffic.
Try to open any pages without installing the certificate and you will see that the browser complains that the connection is not secure (e.g. https://www.facebook.com).
“By default, when you browse an HTTPS website via Burp, the Proxy generates an SSL certificate for each host, signed by its own Certificate Authority (CA) certificate. This CA certificate is generated the first time Burp is run, and stored locally. To use Burp Proxy most effectively with HTTPS websites, you will need to install Burp's CA certificate as a trusted root in your browser.
Note: If you install a trusted root certificate in your browser, then an attacker who has the private key for that certificate may be able to man-in-the-middle your SSL connections without obvious detection, even when you are not using an intercepting proxy. To protect against this, Burp generates a unique CA certificate for each installation, and the private key for this certificate is stored on your computer, in a user-specific location. If untrusted people can read local data on your computer, you may not wish to install Burp's CA certificate.”
Go back to your browser and type:
This will open Burp proxy’s page on your local machine (The port could be different if you configured Burp to use a different one) where you can download Burp’s SSL certificate.
Download the certificate and install it in Firefox:
If you want to install the certificate in Chrome:
If you visit any sites running on HTTPS, you shouldn't see any warnings.
Open a page in the browser with Foxyproxy on (e.g. https://www.indeed.co.uk)
Open “Proxy” → “HTTP History” to see the HTTP requests sent from the browser to Burp. In this tab you can view information related to the requests.
You can see the hostname (the site), the HTTP method used to send the request, the URL of the page/request, if parameters were sent with the request, if it has been edited by you, the HTTP status of the request, the length of the response (the size of page), the MIME type of the page (what type of page are we viewing? An HTML page? A Script? An image?), the extension of the page and finally the title of the page.
Order the list by the last request received by clicking the hashtag symbol which is the title of the first column to the left.
Click on any line in "HTTP history" to see the request sent by the browser and the response sent by the application.
Click “Filter” to show the filter options for the “HTTP History”. Enable all the MIME types. This way you will see pictures and binaries in the HTTP History (this can be very useful).
Click anywhere in Burp’s main window to make the filter disappear.
Why is the “HTTP history” important during a test?
Click “Target” → “Site Map”. You will see several websites included in the site map. These are all the sites that you have visited since you started opening pages in the browser. Of course during a web application assessment, you don’t want to see all of them because they are not part of your scope and therefore you should not test them (legally speaking, you are not authorised to test these sites.)
Select "Use Advanced scope control".
Let's add a target to our target scope. A way to do so is to select the website we want to test in the Proxy's HTTP history tab. Click "Proxy" → "HTTP history".
Right click on one of the lines showing the site you opened in the browser. This will open a small menu, very useful to Burp’s users. This menu and some of its functionalities will be explained in this tutorial.
Click “Add to scope” in the small menu. Click “No” in the message displayed by Burp. You just added the site to your scope.
Go back to the Scope tab under Target.
You can notice few things from the screenshot above:
Select the target's line and click “Edit”. Modify the options as follows to include all the protocols, all the ports and all the subdomains for the site in scope then press OK.
Go back to the “Site Map” tab and click “Filter”. Select all MIME types (as you did for the HTTP history) and select “Show only in-scope items”.
Click in the main window to hide the filter tab. Click on the little arrow situated on the left of the targeted website to view the pages that you currently opened/requested.
The “Site Map” section is very important. Here you will see quite clearly the structure of the site.
As you can see, there are folders and files just like in a file manager. The yellow icons are used for folders and can be opened to show the files stored in that folder. The icons with a small engine wheel show URLs sent with parameters. For example:
If you right click on any of the folders or files you will open a small menu. Click “Remove from scope”, if you want to remove any folders or files from your list. You can see the exclusions in the “Scope” tab.
Another important section of the “Site Map” tab is the “Issues” section which is available only in Burp’s Pro version. Burp Suite analyses passively each requests and responses and if it finds any vulnerabilities, it will be displayed in this section. “Passive scanner” will not send any requests to find the vulnerability but it will just analyse your traffic. Burp suite pro has a feature called “Active scan” which actively sends requests to find vulnerabilities. Active scan is not available for the free version of Burp Suite.
The spider is another important Burp’s feature. The spider lets you find the components of a site.
How does a spider work?
It is quite simple. When you open a page (e.g. https://www.indeed.co.uk) you will be able to click on buttons and links to reach other parts of the site. Several URLs (or part of URLs) can be seen in the response provided by the web application’s server. A spider takes all the URLs and requests them by sending an HTTP request to retrieve that file/page/folder. As soon as the spider receives a response from the web application, it reads the content of the response to see if there are more URLs to be opened and so on, until all the possible links have been opened. This tells you a few things:
Before using Spider there are a couple of settings you might want to change in “Spider” → “Options”.
In “Forms Submission” Click “Don’t Submit Forms”. A Form is that part of a website where you have input fields and a button (not always) to submit the details you just entered. A form could be a login prompt (username and password with “login” button), it could be a search component, a contact form, etc.
Why is better not to submit forms when spidering?
Imagine a site where you have several pages that when opened have a contact form in it. Burp spider will input some semi-random data in the input fields and submit the form, then read its response. What happens to the data you submitted? It is possible that the data you submitted will be sent via email to one or more of your client’s employees (it’s a contact form so you should expect someone to read what you sent). This can be very annoying in the case you submitted hundreds of emails. Clients don’t like this. When you find a form, try to submit it manually to see the resulting page. In cases where you are sure there is no danger you can activate spidering on forms again.
Set “Don’t submit Login forms” in “Application Login”. Similar to the paragraph above, you don’t want to submit login forms in case the client doesn’t want you to try a bruteforce attack against login pages. You can do this manually, it won’t take long.
The spider Engine has 2 useful options.
How do you spider a site?
Go to “Target” → “Site Map” then right-click on the site you want to spider and select “Spider this host”. This will spider the entire site. If you prefer to spider a specific folder, right-click the folder of the site in the “Site Map” area and select “Spider this branch”.
When you activated spidering against a site/folder, go back to “Spider” → “Control” to see how many requests have been queued (How many requests the spider has to send). This will tell you if you found an area of a site with hundreds of requests to be made.
This is what happens if you try to spider indeed.co.uk:
This is why it is important to select only specific areas to be spidered in the case you have to test a huge website and don’t want to spend your spidering resources requesting very similar pages (e.g. if the site is posting job adds, you can assume that all job adds will have a similar structure. If one of these pages is vulnerable, all the others will be as well. You don’t need to see/request all of them to know).
Repeater as the name suggests, lets you repeat/replay a request. It shows you the request in the left pane. You press Go and Burp sends the request. You can go back and forth to see all the requests and responses you have sent to repeater (these are not added to the sitemap and HTTP history tabs unless you add them yourself). The response is shown in the right pane.
This is useful because:
In order to send a request to repeater go to “Target” → “Site Map” tab or into the “Proxy” → “HTTP History” tab and select the request you want to repeat. Right-click and “Send to Repeater” or CTRL+R.
Indeed.com lets you find jobs and people to hire. Let’s try to find someone with “penetration testing” skills.
Try opening the following request into the browser, find it in “HTTP History” and send it to repeater:
Click “Go” and see the resulting response.
From the screenshot above you can notice few things:
Try to change the value of the parameters of the request to see what happens to the response. Note:
“Burp Intruder is a powerful tool for automating customized attacks against web applications. It can be used to automate all kinds of tasks that may arise during your testing.”
Few of the automated tasks you might want to achieve are:
The following example will show you how to use intruder to brute force numeric IDs.
The following request (http://example.com/groupmembers.asp?groupid=1300) allows unauthenticated users to view the member’s directory of the group with id equal to 1300. Users’ email addresses are disclosed in the page (yes, users log in with their email addresses).
If you tried to open the same URL and change the groupid to 1299 you would be redirected to the login page and no emails would be shown to you. This is probably because some groups don’t exist anymore or their members are private. This is why you want to use intruder to catch the pages with email addresses of regular users.
Why would you want to see the email addresses of all the users subscribed to the site? To later perform a brute force against a login page!
When you access the above page, the URL will be added to the Proxy HTTP History. Right click on the line of the request and left-click “Send to Intruder”.
Click the “Intruder” tab and you will be presented with the “Target” tab. This shows you your target host and port. There is nothing to be changed here. Click “Positions” and you will see something like this:
Two points to notice from the screenshot above:
Leave Sniper selected and click “Clear §” on the right side of the screen. This will deselect the parameters. What we want from this exercise is to brute force only 50 group ids (we don’t want to send too many requests at this moment).
Select the number of the “groupid” parameter and change it to 1300. Now select the two zeros of 1300 and click “Add §”:
As you can imagine, whatever payload you choose will go between the “§” signs to substitute the “00”. We want to test IDs 1300 up to 1350.
Click “Payloads” tab.
“Payload Sets” allows you to select the “Payload set” which is the injection point you selected (in this case it is only one) and the payload type. Burp intruder has several payload types. The most used are probably “simple list” (you can choose a file with payloads one per line) and “Numbers” (you can choose a way to brute force numeric IDs).
“Payload options” allows you to change the way you use a payload type. In the case of “simple list”, it lets you choose a file or one of Burp’s default lists.
“Payload processing” allows you to modify the payload on the fly. For example you can add a prefix or suffix to the payload.
“Payload encoding” allows you to choose if you want to URL encode specific characters. Some web applications require specific characters to be encoded or the request will fail.
Select “Payload type” → “Numbers” and input the following options:
Here we are telling Burp to use numbers from 00 to 50. We start from 00 because the part of the parameter we selected is made up by 2 zeros (Remember the “13§00§”?). We also want a minimum and a maximum number of integers equal to 2 meaning Burp should send 00, 01, 02 and not just 0, 1, 2, etc.
We will cover Burp Intruder options in the next tutorials.
Click Intruder in the top bar and “Start Attack”:
Burp will start sending the payloads as you specified.
From the screenshot above you can notice few points:
Point #2 and #3 clearly tell you that some requests give you back the page of a group (the ones with HTTP code 200 and a greater response length) and others redirects you to the login page (HTTP code 302 and response length 392).
During a real-world attack scenario you would probably enumerate all the group IDs, then find all the email addresses for the users and then if allowed by the engagement rules, perform a brute force attack.
Decoder lets you decode/encode strings into different formats such as URL, Base64, HTML encoding. As said above web application will accept/need encoded characters in order to understand specific requests.
Comparer lets you compare requests and responses. This can be useful when you submitted 2 requests and changed the value of a parameter. The resulting response differs from the first one by few bytes. You want to know where in the page something has changed.
Burp has more features that would be good to discuss. This tutorial won’t go into more details but later tutorials will show other ways to exploit Burp’s potential.