Before starting an application penetration test, the system that will be used to attack the end application must be prepared. This involves configuring Burp Suite to become the interception proxy for various clients and traffic sources.
As with scoping for targets, it is important to reduce noise in the data we collect. We will use target whitelisting techniques, and work with the Burp Target feature to filter and reduce the clutter that testing modern applications can introduce.
Burp, or Burp Suite, is a graphical tool for testing web applications for security flaws. The tool is written in Java and was created by Dafydd Stuttard under the name of PortSwigger. Burp Suite is now actively developed by his company PortSwigger Ltd., which is based out of the United Kingdom.
Burp is available in two variants: the free version, called the Community Edition, and the Professional version. The Community Edition lacks several features and speed enhancements that the Professional variant provides.
We will cover the following topics in this chapter:
- Getting to know Burp Suite
- Setting up proxy listeners
- Managing multiple proxy listeners
- Working with non-proxy aware clients
- Creating target scopes in Burp Suite
- Working with target exclusions
- Quick settings before beginning
Burp can be downloaded for all the major operating systems from the PortSwigger website at https://portswigger.net/burp. For Windows systems, both x64-bit and x32-bit installers are available. A standalone Java JAR file is also available in case you want to run Burp as a portable application.
When you start Burp Suite, you will be prompted to provide settings to set up your Burp project before you begin using the tool.
The three options available are as follows:
Temporary project: Select this if you want to use Burp for a quick inspection or a task that you do not need to save. You can get started immediately when you select this option and hit
New project on disk: For a well-executed penetration test, it is very important to be able to record and retrieve logs of requests and responses that were part of the test. This option allows you to create a file on the disk that will store all the configuration data, requests, and responses, and proxy information that you set in Burp when you begin testing. A descriptive name can be provided to enable this file to be loaded in the future. A good rule of thumb is to create a name that provides information about the project itself. ClientName-TypeOfTest-DDMMYYYY is a good name to start with.
Open existing project: This option allows you to load any existing project files that have been created in the past using the
New project on diskoption. You can choose to pause the spider and scanner modules so that the project is loaded in a non-active state of attack.
Next will take you to a page where you can choose any save configuration from before or continue using Burp defaults. You also get the option of disabling extensions when Burp starts.
Start Burp to continue.
To use Burp as a tool for application penetration testing, it must be set as a Man in the Middle (MITM) proxy. An MITM proxy sits in between a client and a server, and allows the user to tamper or drop messages passing through. In its simplest form, Burp Suite is an MITM proxy for HTTP(S) traffic.
By default, Burp will listen on port
8080 on the localhost IP of
127.0.0.1. This can easily be changed, however, to an arbitrary free port on any IP address available on the system. To do this, follow these steps:
- Navigate to the
Proxy Listeners, confirm that the
Runningcheckbox is ticked in front of the proxy entry.
- If the checkbox refuses to check, even after you have clicked it, it very likely means that the port selected (default
8080) is being used by another process on the system. You can simply choose another port to start listening for connections:
If there is no
Proxy Listener listed at all (it's rare, but this does happen), follow these steps to set up a new proxy listener:
- Click on
- In the
Add a new proxy listenerwindow that opens, under the
Bindingtab enter a port to bind to, which would typically be
- Set the
Bind to addressto
Loopback only,and click
OKto create the listener.
If you plan on using Burp over the network, then you can select an interface from the drop-down list in front of the
Specific address option. Be careful when using this option as this allows any user on the network to proxy traffic through your system, and allows access to the contents of the
Proxy History, which may contain sensitive information, such as session cookies and login credentials. Enable this only if you trust the network you are on:
If the proxy listener checkbox does not toggle to a check, it very likely means that another process on the system is listening on that port. On Windows, you can use the
netstat -antob command to identify ports and the processes that are using the open port. On Linux and macOS, use the
netstat -lntp command. Both need to be run in an elevated environment on their respective operating systems.
- Redirect to host: When configured, Burp will forward every request to the specified host, regardless of the original target requested by the user agent.
- Redirect to port: When configured, Burp will forward every request to the specified port, regardless of the original port requested by the user agent.
- Force use of SSL: When configured, Burp will force HTTPS on all outgoing traffic, even when the request that originated from the user-agent was HTTP:
Certificate tab allows you to configure various SSL-related options, and to fix errors that may arise during a penetration test. The following options are available on this page:
- Use a self-signed certificate: A self-signed certificate is generated and given to the browser. This will always cause an SSL alert on modern browsers.
- Generate CA-signed per-host certificates: This is the default option selected when a new proxy listener is created. When Burp is first run, a self-signed Certificate Authority (CA) certificate is created. This certificate can be installed as a trusted root in your browser by clicking on the
Import / export CA certificatebutton, or from
http://127.0.0.1:8080/cert(when the proxy listener is on port
8080), so that the per host certificates can be accepted without any alerts.
Throughout the book, unless otherwise specified, we will be using the default option for SSL certificates.
Another very important feature that we must be aware of at this point is Burp's capability to chain multiple proxies. As with most settings in Burp, setting upstream proxy servers or SOCKS proxies can be configured in great detail.
To set an upstream proxy server, or to basically to configure Burp to forward the request to the destination web server, or to additional proxies, click on the User Options tab in the main window and scroll down to Upstream Proxy Servers. To configure an upstream proxy for all destinations, use a wildcard (*) operator.
Sometimes, customers require an IP address from which all attack traffic would originate to the end customer. In this case, simply running a Linux machine with a static IP on the internet and SSH with port forwarding enabled allows Burp to proxy its traffic through the SOCKS Proxy that this arrangement creates.
Burp Suite can provide multiple proxy listener interfaces if there is a requirement to do so. This simply means that Burp can start listeners on different ports and different IP addresses simultaneously, each with its own configurations and settings.
For example, if a thick client application you are testing has multiple components, some of which can be configured to use a proxy, and some can't, or if its communication ports are hardcoded, or if traffic from a network-based browser or service needs to be captured, then multiple proxy listeners, each with their own configuration, can be created.
You can disable a proxy listener simply by unchecking the checkbox next to the
Interface name, if required. Next, we will understand the working of the non-proxy-aware clients.
Common examples of non-proxy-aware clients are thick client applications or browser plugins that do not use the browser's proxy options. Burp's support for invisible proxying allows non-proxy-aware clients to connect directly to a proxy listener. This allows Burp to intercept and modify traffic based on target mappings.
Architecturally, this works by setting up a local DNS entry for the remote target that the non-proxy-aware client communicates with. This DNS entry can be made in the local hosts file, as follows:
The client then communicates with
127.0.0.1 instead of the actual IP address of
example.org. To complete the circuit, local listeners would have to be set up with invisible Burp proxy support on port
80 (or whatever other port the server is listening on). The non-proxy-aware client will then resolve the domain name to
127.0.0.1, and send requests directly to the listener on that interface.
Burp, by default, will forward requests to the destination based on the host header that was obtained from the request header of the client. However, an interesting problem presents itself here. As the DNS entry for the destination has been set to
127.0.0.1, Burp will resolve the destination incorrectly and forward the request to itself, creating a loop.
This can be fixed by using an IP address instead of the domain name/hostname in the
Redirect to host option under the
Request handling tab, as shown in the following screenshot:
If the client communicates to multiple domains, then Burp's hostname resolution feature, available under the
Project Options tab in the main window, can be used to individually map each request to the correct destination IP address. Each of these destinations should also be added to the host's file to ensure traffic destined for these hosts is sent via Burp.
Adding items to target scope allows you to affect the behavior of features throughout Burp. For example, you can do the following:
- You can set display filters to show only the items in scope. This is available under
Site mapand under
History,and is very useful when dealing with applications that use code from a lot of third parties.
Spidermodule is restricted to in-scope targets.
- You can configure the proxy to intercept the requests and responses for only in-scope items.
- In the Professional version of Burp, you can even automatically initiate vulnerability scans of in-scope items.
There are essentially two ways of adding scope items. The first, and the recommended way, is to obtain targets from proxy history. For this to happen, the following approach is taken:
- Set up your browser and Burp to talk to each other.
- Turn off interception mode in Burp and browse the application.
Start with the home page and browse to every link; log in to authenticated areas and log out; submit every form; navigate to every single path that is listed in the
robots.txt, and to every single link in the application's sitemap (if available); and, if applicable, access the application as different users (either with the same or different privilege levels).
Doing this will populate the sitemap for the application as seen under the
tab, as shown in the following screenshot:
Once targets and URLs are populated in the
Site map tab, you can right-click on any item and add that item to scope. This can be done both via the
Site map, or via the
The second method is to directly add items to the
Scope tab. Check the
Use advanced scope control to enable the older interface for scope addition, which allows far more granular control over the scope entries.
Let's take an example and create our scope for an imaginary penetration test. Let's assume the application in scope is at
http://mutillidae-testing.cxm/. Using the
Scope tab, we can add this and all future URLs from this application to the scope by setting the following:
Host or IP range:
This will add the application and any URLs on port
80 with the HTTP protocol to the scope.
You can also load a file containing a list of URLs that need to be in scope via the
Load button on the
Scope page. This list must be URLs/targets separated by newlines. Large files may take time to load and Burp may appear frozen for a while, but will resume working when the file has been loaded and parsed.
Just as we can add items to scope in Burp, we can also add items that need to be explicitly set out of scope. This, as is the case with in-scope items, can be added via two methods. The first is via the
History tab from the right-click context menu:
The second is from the
Target scope tab in the
Exclude from scope section. For example, if you want to exclude all sub-directories and files under
Host or IP range:
This will exclude all URLs under the
80 with the HTTP protocol.
You can also load a file containing a list of URLs that need to be excluded from scope via the
Load button on the
Scope page. This list must be URLs/targets separated by newlines.
- Enable server response interception: By default, Burp is not configured to intercept server responses. This can, however, be enabled using the
Intercept Server Responsesoptions under
Options. Enable interception of responses when
Was modifiedand when
- Enable the Unhide hidden form fields and select the Prominently highlight unhidden fields option: This can be found under the
panel. This is very useful when browsing an application that stores or uses hidden HTML form fields to make application decisions.
The hidden field is visible on the page and highlighted very conspicuously, allowing you to edit the contents directly in the page if required.
- Enable the Don't send items to Proxy history or other Burp tools, if out of scope option: This option can be found under
Miscellaneous. When enabled, this option prevents Burp from sending out-of-scope requests and responses to the
Historyand other Burp tools, such as
Target. These requests and responses are sent and received, but not logged in any of Burp's feature sets.
- Set a keyboard shortcut to issue a Repeater request: This is a very useful setting that can be enabled to avoid clicking the
Gobutton using the mouse when working with the Repeater module of Burp. Burp already allows items to be sent to
Historytab using Ctrl + R. Switching to the
Repeaterwindow can be achieved with Ctrl + Shift + R. Adding a shortcut to sending a request using
Repeatercompletes the chain of keystrokes required to pick an item from
History,and sending it forward.
- Schedule a Save state operation: Burp has a task scheduler that can be invoked for certain tasks, such as resuming and pausing scans and spidering. You can reach the task scheduler from
- One of the key operations that the task scheduler supports is the auto save state. Select
Save stateand click
- Select a file that will contain the save state and, if required, select the
In-scope items onlycheckbox, as shown in the following screenshot:
- Select a file that will contain the save state and, if required, select the
- Select when to start the task and the interval. During a busy engagement, saving every 30 minutes is a good interval to begin with: