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 Next.
• 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 disk option. You can choose to pause the spider and scanner modules so that the project is loaded in a non-active state of attack.

Clicking on 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.

Click 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:

1. Navigate to the Proxy | Options tab.
2. Under Proxy Listeners, confirm that the Running checkbox is ticked in front of the proxy entry.
3. 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:

1. Click on Add.
2. In the Add a new proxy listener window that opens, under the Binding tab enter a port to bind to, which would typically be 8080.
3. Set the Bind to address to Loopback only, and click OK to 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:

A proxy listener can be configured for various Request handling use cases. The following options are available here:

• 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:

The 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 certificate button, 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.

• Use a custom certificate: This option allows Burp to use a custom PKCS#12 format certificate.

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.

A non-proxy-aware client, in this context, is a client that makes HTTP requests but has no easy way to configure proxy options, or has no proxy support at all.

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:

127.0.0.1 example.org

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.

The target scope settings can be found under the Target | Scope tab. This allows you to configure in-scope targets for the penetration test that you are currently executing.

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 Target | Site map and under Proxy | History, and is very useful when dealing with applications that use code from a lot of third parties.
• The Spider module 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:

1. Set up your browser and Burp to talk to each other.
2. 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 Target | Site map 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 Target | Site map, or via the Proxy | History tab.

The second method is to directly add items to the Target | 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 Target | Scope tab, we can add this and all future URLs from this application to the scope by setting the following:

• Protocol: HTTP
• Host or IP range: mutillidae-testing.cxm
• Port: ^80$
• File: ^*

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 Target | 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 Proxy | 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 /javascript, then the following options can be applied:

• Protocol: HTTP
• Host or IP range: mutillidae-testing.cxm
• Port: ^80$
• File: ^/javascript/.*

This will exclude all URLs under the /javascript/ directory on port 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 Target | Scope page. This list must be URLs/targets separated by newlines.

Both the Include in scope option and Exclude from scope option are case insensitive. /javascript/, /JavaScript/, and /jAvAscrIPt/ all mean the same for the Target | Scope feature of Burp.

This section highlights five quick settings that can be enabled/set/configured before beginning a test to become productive immediately:

• Enable server response interception: By default, Burp is not configured to intercept server responses. This can, however, be enabled using the Intercept Server Responses options under Proxy | Options. Enable interception of responses when Request | Was modified and when Request | Was intercepted.

• Enable the Unhide hidden form fields and select the Prominently highlight unhidden fields option: This can be found under the Proxy | Options | Response Modification 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 Proxy | Options | Miscellaneous. When enabled, this option prevents Burp from sending out-of-scope requests and responses to the Proxy | History and other Burp tools, such as Scanner and 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 Go button using the mouse when working with the Repeater module of Burp. Burp already allows items to be sent to Repeater via the Proxy | History tab using Ctrl + R. Switching to the Repeater window can be achieved with Ctrl + Shift + R. Adding a shortcut to sending a request using Repeater completes the chain of keystrokes required to pick an item from Proxy | 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 Project Options | Misc | Scheduled Tasks.
• One of the key operations that the task scheduler supports is the auto save state. Select Save state and click Next:

• 1. Select a file that will contain the save state and, if required, select the In-scope items only checkbox, as shown in the following screenshot:

• 2. Select when to start the task and the interval. During a busy engagement, saving every 30 minutes is a good interval to begin with:

• 3. Click finish to activate the Scheduled Task, as shown in the following screenshot:

In this chapter, we learned to prepare the Burp Suite application. We configured Burp Suite to make it the interception proxy for various clients and traffic sources. In the next chapter, we will learn how to configure the client and set up mobile devices.