Burp Suite Tutorial – Web Application Penetration Testing (Part 1)
Burp Suite from Portswigger is one of my favorite tools to use when performing a Web Application Penetration Test. The following is a step-by-step Burp Suite Tutorial. I will demonstrate how to properly configure and utilize many of Burp’s features. After reading this, you should be able to perform a thorough web application penetration test. This will be the first in a two-part article series.
Don’t Go To Jail!
What we will cover:
- Outbound SOCKS Proxy Configuration
- Intercept & Scope Configuration
- Manual Application Walkthrough
- Using The Spider & Discover
- Using The Repeater Tab
- Using The Intruder Tab
- Text Specific Searching
- Using The Automated Scanner
Disclaimer: Testing web applications that you do not have written authorization to test is illegal and punishable by law.
Burp Suite Tutorial – Configure Outbound SOCKS Proxy
Depending on the scope of your engagement, it may be necessary to tunnel your burp traffic through an outbound socks proxy. This ensures that testing traffic originates from your approved testing environment. I prefer to use a simple SSH which works nicely for this purpose. SSH out to your testing server and setup a socks proxy on your localhost via the ‘–D’ option like this.
ssh –D 9292 –l username servername
Navigate to the Options tab located near the far right of the top menu in Burp. From the “Connections” sub-tab, Scroll down to the third section labeled “SOCKS Proxy”. Type in localhost for the host option and 9292 for the port option.
Now burp is configured to route traffic through your outbound SSH tunnel. Configure your browser’s proxy settings to use burp. Navigate to www.whatismyip.com and ensure your IP address is coming from your testing environment.
#ProTip I use a separate browser for web application testing. This ensures I don’t accidently pass any personal data to one of my client’s sites such as the password to my gmail account for example.
I also prefer to use a proxy switching addon such as “
SwitchySharp” for Google Chrome. This allows me to easily switch back and forth between various proxy configurations that I might need during different engagements. Here is what my configuration settings look like for Burp.
Figure #2 – SwitchySharp Proxy Settings
Burp Suite Tutorial – Configure Intercept Behavior
The next thing I do is configure the proxy intercept feature. Set it to only pause on requests and responses to and from the target site. Navigate to the “Proxy” tab under the “Options” sub-tab. The second and third headings display the configurable options for intercepting requests and responses. Uncheck the defaults and check “URL Is in target scope”. Next turn intercept off as it is not needed for the initial application walkthrough. From the “Intercept” sub-tab ensure that the toggle button reads “Intercept is off”
Figure #3 – Proxy Intercept Settings
Burp Suite Tutorial – Application Walkthrough
For some reason, a lot of people like to skip this step. I don’t recommend this. During the initial walkthrough of your target application it is important to manually click through as much of the site as possible. Try and resist the urge to start analyzing things in burp right a way. Instead, spend a good while and click on every link and view every page. Just like a normal user might do. Think about how the site works or how it’s “supposed” to work.
You should be thinking about the following questions:
- What types of actions can someone do, both from an authenticated and unauthenticated perspective?
- Do any requests appear to be processed by a server-side job or database operation?
- Is there any information being displayed that I can control
If you stumble upon any input forms, be sure to do some manual test cases. Entering a single tick and hit submit on any Search form or zip code field you come across. You might be surprised at how often security vulnerabilities are discovered by curious exploration and not by automated scanning.
Burp Suite Tutorial – Configure Your Target Scope
Now that you have a good feel for how your target application works its time to start analyzing some GETs and Posts. However, before doing any testing with burp it’s a good idea to properly define your target scope. This will ensure that you don’t send any potentially malicious traffic to websites that you are not authorized to test.
#ProTip I am authorized to test www.pentestgeek.com. *You* are not.
Head over to the “Target” tab and then the “Site map” sub-tab. Select your target website from the left display pane. Right click and choose “Add to scope’. Next highlight all other sites in the display pane, right click and select Remove from scope. If you’ve done this correctly your scope should look something like the image below.
Figure #4 – Scope Settings
Burp Suite Tutorial – Initial Pilfering
Click on the “Target” tab and the “Site Map” sub tab. Scroll down to the appropriate site branch and expand all the arrows until you get a complete picture of your target site. This should include all of the individual pages you browsed as well as any javascript and css files. Take a moment to soak all of this in, try and spot files that you don’t recognize from the manual walkthrough. You can view the response of each request in a number of different formats located on the “Resposne” tab of the bottom right display pane. Browse through each respond searching for interesting gems. Things you might be surprised to find include:
- Developer comments
- Email addresses
- Usernames & passwords if you’re lucky
- Path disclosure to other files/directories
- Etc…
Burp Suite Tutorial – Search Specific Keywords
You can also leverage burp to do some of the heavy lifting for you. Right click on a node, from the “Engagement tools” sub-menu select “Search”. One of my favorite searches is to scan for the string “set-cookie”. This lets you know which pages are interesting enough to require a unique cookie. Cookies are commonly used by web application developers to differentiate between requests from multiple site users. This ensures that user ‘A’ doesn’t get to view the information belonging to user ‘B’. For this reason it is a good idea to identify these pages and pay special attention to them.
Figure #5 – Search Specific Keywords
Burp Suite Tutorial – Using Spider and Discover
After a good bit of manual poking and prodding it’s usually beneficial to allow burp to spider the host. Just right click on the target’s root branch in the sitemap and select “Spider this host”.
Figure #6 – Spider Feature
Once the spider has finished, go back to your site-map and see if you picked up any new pages. If you have, take a manual look at them in your browser and also within burp to see if they produce anything interesting. Are there any new login prompts, or input boxes for example? If you’re still not satisfied with all that you have found you can try Burp’s discovery module. Right click on the target site’s root branch and from the “Engagement tools” sub-menu select “Discover Content”. On most sites this module can and will run for a long time so it’s a good practice to keep an eye on it. Make sure that it completes or shut it off manually before it runs for too long.
Burp Suite Tutorial – Using The Repeater
The Repeater tab is arguably one of the most useful features in Burp Suite. I use it hundreds of times on every web application that I test. It is extremely valuable and also incredibly simple to use. Just right click on any request within the “Target” or “Proxy” tab and select “Send to Repeater”. Next click over to the “Repeater” tab and hit “Go”. You will see something like this.
Figure #7 – The Repeater
Here you can manipulate any part of the HTTP request headers and see what the response looks like. I recommend spending some good time here playing with every aspect of the HTTP request. Especial any GET/POST parameters that are besting sent along with the request.
Burp Suite Tutorial – Using The Intruder
If you are limited on time and have too many requests and individual parameters to do a thorough manual test. The Burp Intruder is a really great and powerful way to perform automated and semi-targeted fuzzing. You can use it against one or more parameters in an HTTP request. Right click on any request just as we did before and this time select “Send to Intruder”. Head over to the “Intruder” tab and click on the “Positions” sub-tab. You should see something like this.
Figure #8 – Intruder Positions
I recommend using the “Clear” button to remove what is selected at first. The default behavior is to test everything with an ‘=’ sign. Highlight the parameters you wan’t to fuzz and click “Add”. Next you need to go to the “Payloads” sub-tab and tell Burp which test cases to perform during the fuzzing run. A good one to start off with is “Fuzzing – full”. this will send a number of basic test cases to every parameter that you highlighted on the “Positions” sub-tab.
Figure #9 – Intruder Payloads
Burp Suite Tutorial – Automated Scanning
The last thing that I do when testing a web application is perform an automated scan using Burp. Back on your “Site map” sub-tab, right click on the root branch of your target site and select “Passively scan this host”. This will analyze every request and response that you have generated during your burp session. It will produce a vulnerability advisor on the “Results” sub-tab located on the “Scanner” tab. I like to do the passive scan first because it doesn’t send any traffic to the target server. Alternatively you can configure Burp to passively analyze requests and responses automatically in the “Live scanning” sub-tab. You can also do this for Active Scanning but I do not recommend it.
When doing an active scan I like to use the following settings.
Figure #10 – Active Scan Settings
Burp Suite Tutorial – End Of Part1
Hopefully you’ve learned some useful techniques for performing Web Application Penetration Testing. In
Part 2, we will go over some more of Burp’s features. We will cover reporting and exporting session data for collaboration with other pentesters. I look forward to seeing you there. Thank you for reading and as always, Hack responsibly.
Source: pentestgeek.com
![[WAF-FLE] Web application firewall: fast log and event console](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgNUiNj5SjQeu8VhkRyfVjV4mP1bHFkRLpos0NqOznjOFmrqXmnTaqDd-0btKDqtpn3Ay_K8B6Vy75b8yyJyCeSZrUY7NJPG0GRBfEbdmFs1A7fpWMRKQa5jzzm8JOrTc3zAC7GIumQmTk/s72-c/waf-fle.png "[WAF-FLE] Web application firewall: fast log and event console")
0 comments: