# Lab: Burp Suite Introduction

[Burp Suite](https://portswigger.net/burp) is a framework of web application testing tools. It is widely regarded as the de facto tool to use when performing web app testing.

In this lab, you'll install Burp on your own system and become familiar with a few of Burp's key features: intercepting and modifying web requests. At the end of this tutorial, there will be instructions on how to demonstrate your progress, which you can include in your homework submission to receive credit.

In the next project, you'll be testing an insecure website--you may find it useful to use Burp to help with this process!

## Installing Burp Suite

To install Burp:

1. Download Burp Suite Community Edition via [this link](https://portswigger.net/burp/communitydownload) and install it on your system. To run Burp, you may also need to install Java (see [this link](https://www.java.com/en/download/)) if you don't already have it on your machine.

2. Next, open the Burp app you just installed (it might be named 'Burp Suite Community Edition'). You should be greeted with the following welcome screen:


3. In the welcome screen, click **Temporary project** and then **Next**.

4. Next, we'll be prompted to ask for what configuration we'd like to use. For now, select **Use Burp defaults**.


<!-- It can be incredibly useful to create a custom configuration file for your proxy or other settings, especially depending on your network configuration and/or if Burp Suite is being launched remotely such as via x11 forwarding. But for now, we'll stick with the default configuration. -->

5. Finally, click **Start Burp**!

> If you see a pop-up that says 'Update is ready to install', feel free to click 'Restart Burp'. If you do so, you will need to repeat the above steps once the update has installed.

Once Burp opens, you should see a screen that looks similar to this (make sure you are on the 'Dashboard' tab):


Now you're ready to use Burp! To test it, you'll run a tiny website as a demo and then start playing around with it using Burp!

## Target application: OWASP Juice Shop

Before we get started using Burp, we need a website to test. To do this, we'll run a deliberately-insecure website created called Juice Shop, which is maintained by OWASP, an organization that builds resources for promoting web security. The Juice Shop site is modeled like an online store, which gives us plenty of opportunities to interact with it.

You can load your own instance of the OWASP Juice Shop on your system using docker, similar to our course container, as follows:

1. Open a terminal on your *host system* (or a WSL terminal in Windows). This should be the same terminal you use to run `./run-container` to *start* the course container, not a terminal in the container itself.

2. From your terminal, run the following command:

$ you@host-or-wsl:$ docker run -p 3000:3000 bkimminich/juice-shop

This command downloads the Juice Shop container and starts it on your system. If all goes well, the late line of your terminal should say something like:

info: Server listening on port 3000

:::success

**What to expect**: This container is a bit different than our course container in that **it doesn't start a shell** for you to enter commands. Instead, it starts **its own webserver** for you to connect to it from a browser.

Containers are commonly used this way in practice--they can allow users to install and run whole applications very quickly. We'll use this model for running more containers throughout the course!
:::

To test the website, open your browser to http://localhost:3000, which should look like this:


Feel free to play around with the site to get a sense of what you can do. In the next section, we'll see how to inspect the website using Burp!

:::info
**Note**: if you ever can't reach the Juice Shop site, come back to this terminal and make sure it's still running. If necessary, you can exit the container with `Ctrl+C` and then restart it by running the command again.
:::

## Burp Suite Overview

Burp has a lot of tools to help with various aspects of web application testing. Our lab will focus on the following components, which will be most useful for the project:
- **Proxy**: Allows us to funnel traffic through Burp Suite for further analysis
- **Target**: How we set the scope of our project. We can also use this to effectively create a site map of the application we are testing.
- **Repeater**: Allows us to 'repeat' requests that have previously been made with or without modification.

The next few sections will describe the most important parts for each feature.

<!-- <details><summary>Here are some other features you can also use</summary>

- Intruder - Incredibly powerful tool for everything from field fuzzing to credential stuffing and more
- Sequencer - Analyzes the 'randomness' present in parts of the web app which are intended to be unpredictable. This is commonly used for testing session cookies
- Decoder - A tool that allows us to perform various transforms on pieces of data. These transforms vary from decoding/encoding to various bases or URL encoding.
- Comparer - A tool we can use to compare different responses or other pieces of data such as site maps or proxy histories (awesome for access control issue testing). This is very similar to the Linux tool `diff`.
- Extender - Similar to adding mods to a game like Minecraft, Extender allows us to add components such as tool integrations, additional scan definitions, and more!
- Scanner - Automated web vulnerability scanner that can highlight areas of the application for further manual investigation or possible exploitation with another section of Burp. This feature, while not in the community edition of Burp Suite, is still a key facet of performing a web application test.
</details> -->

## Burp Proxy: intercepting requests

One of Burp Suite's core features is a [*proxy*](https://en.wikipedia.org/wiki/Proxy_server), or a relay for web traffic on its way to some destination on the Internet. Proxies are a common method to implement caching, filtering, or to circumvent content blocking by relaying traffic through another source. The [Burp proxy](https://portswigger.net/burp/documentation/desktop/tools/proxy) allows us to view, modify, drop, or replay requests between a browser and the Internet, which we'll use to test/attack web applications.

To make the proxy easier to use, Burp contains its own browser (the "Burp browser") that automatically sends all requests to the proxy. It's possible, but not required, to also set up your own browser to relay traffic to Burp, but this requires extra configuration--if you're interested, see [this section](#Using-Burp-with-Firefox-and-FoxyProxy). Either way, the effect is that **Burp can intercept and, optionally, modify any web traffic that passes through it**. This means a few things:
- When Burp is in *Intercept mode*, Burp will require authorization before it sends a request
- Before a request is sent, you can modify it, similar to what an attacker might do
- You can also drop requests that you *don't* want to be sent. This can be useful to see observe what a request looks like (eg. clicking a button) without causing any effect on the server
- Finally, you can also send these requests to other Burp tools such as its *Repeater* and *Intruder*, which can modify them further to try and learn more about the target and possibly induce certain vulnerabilities

<!-- Generally speaking, proxy servers by definition allow us to relay our traffic through an alternative route to the internet. This can be done for a variety of reasons ranging from educational filtering (common in schools where restricted content is blocked) to accessing content that may be otherwise unavailable due to region locking or a ban. Using a proxy, however, for web application testing allows us to view and modify traffic inline at a granular level. Throughout this task, we'll explore the major components of the Burp Proxy including interception, request history, and the various configuration options we have access to.

During setup, we configured our web traffic to route through our instance of Burp Suite. By default, Burp will be set to 'intercept' our traffic. This means a few things:
-->

<!-- **Task 1:** By default, the Burp Suite proxy listens on only one interface. What is it? *Use the format `IP`:`PORT`*. -->

To use the Burp Proxy:
1. If you have any tabs open to the OWASP juice shop from earlier, close them. For the rest of this tutorial, we'll work exclusively with the built-in Burp browser.

1. In Burp suite, navigate to the Proxy tab and then the Intercept sub-tab. In the center of the Burp window, click on the button **Open Browser**. This should launch a custom version of Chrome that's automatically connected to the Burp proxy:


2. Back in the Burp window, turn on Intercept mode by toggling the Intercept button shown below to say **Intercept is on**:


When Interception is turned on, all requests made in the Burp browser are held by the proxy until you specifically decide to authorize them--this give you a chance to decide what to do with each request.

2. In the Burp browser, open the OWASP Juice Shop site at http://localhost:3000. Note that the page appears to be continuously loading--this is expected, since the proxy is holding the request! Switch back to Burp Suite; you should now see a request waiting in in Intercept tab:


The main part of the Intercept window shows the HTTP **headers and content** present in the request. In the first request for the Juice Shop page (which should look like the figure above), you should see the request type (`GET`), path (`/`) and a bunch of headers that the browser sets in the request.

Most of the headers you see right now are standard, [boilerplate](https://en.wikipedia.org/wiki/Boilerplate_code) headers that the browser sends with every request. On more complex site, you'll see other info here, including cookies, form data (for `POST` requests), and more.

The proxy controls let you decide what happens to this request:
- **Forward**: Allows this request to proceed to the server, as normal
- **Drop**: discards the request without sending it
- **Action**: has a menu of other tasks, allowing you to send the request to other burp tools, ignore future requests like this, and more
- (Not in the proxy controls) In the Intercept window, you can also **modify** anything you see in the content and the headers before forwarding. This lets you send custom requests!

For now, we don't need to modify the request, so let's just let the page load.

3. In the proxy controls, click **Forward**, to let this request proceed. You'll immediately see other requests pop up--these are requests to load other parts of the page. You can just click **Forward** for all of these, but notice how the URLs and paths change, and watch how the different parts of the site load in the browser as the requests complete--all of these requests make up a single web page!

5. You'll notice that manually approving each request can get pretty annoying. For now, **turn Intercept mode off** while we work with other Burp tools. In general, you can leave Intercept mode off unless you really need it.
It's also possible to configure Burp to auto-forward certain requests by URL patterns (see "Proxy Settings" for more info).

Now that we've seen how the proxy works, let's see what we can do with the information Burp learns by observing all our request.

<!-- **Task 3:** How about if we wanted to forward our request to Intruder?

**Task 4:** Burp Suite saves the history of requests sent through the proxy along with their varying details. This can be especially useful when we need to have proof of our actions throughout a penetration test or we want to modify and resend a request we sent a while back. What is the name of the first section wherein general web requests (GET/POST) are saved?
-->
<!-- **Task 5:** Defined in RFC 6455 as a low-latency communication protocol that doesn't require HTTP encapsulation, what is the name of the second section of our saved history in Burp Suite? These are commonly used in collaborate application which require real-time updates (Google Docs is an excellent example here).
-->
<!-- **Task 6:** Before we move onto exploring our target definition, let's take a look at some of the advanced customization we can utilize in the Burp proxy. Move over to the Proxy Settings or Options section of the Proxy tab and search for "Request Interception Rules". Here we can apply further fine-grained rules to define which requests we would like to intercept. Perhaps the most useful out of the default rules is our only AND rule. What is its match type?

**Task 7:** How about it's 'Relationship'? *In this situation, enabling this match rule can be incredibly useful following target definition as we can effectively leave intercept on permanently (unless we need to navigate without intercept) as it won't disturb sites which are outside of our scope - something which is particularly nice if we need to Google something in the same browser.* -->

## Burp Target: building a site map

As you work with a site, the **Target** tab builds a map of the possible URLs and target resources that make up the application. To try this out, do the following:

<!-- Perhaps the most important feature in Burp Suite, we'll now be turning our focus to the Target tab!

The Target tab in Burp allows us to perform arguably some of the most important parts of a web application penetration test: defining our scope, viewing a site map, and specifying our issue definitions (although this is more useful within report generation and scanning).

When starting a web application test you'll very likely be provided a few things:

- The application URL (hopefully for dev/test and not prod)
- A list of the different user roles within the application
- Various test accounts and associated credentials for those accounts
- A list of pieces/forms in the application which are out-of-scope for testing and should be avoided

From this information, we can now start to build our scope within Burp, something which is incredibly important in the case we are planning on performing any automated testing. Typically this is done in a tiered approach wherein we work our way up from the lowest privileged account (this includes unauthenticated access), browsing the site as a normal user would. Browsing like this to discover the full extent of the site is commonly referenced as the 'happy path'. Following the creation of a site map via browsing the happy path, we can go through and start removing various items from the scope. These items typically fit one of these criteria:

- The item (page, form, etc) has been designated as out of scope in the provided documentation from the client
- Automated exploitation of the item (especially in a credentialed manner) would cause a huge mess (like sending hundreds of password reset emails)
- Automated exploitation of the item (especially in a credentialed manner) would lead to damaging and potentially crashing the web app

Once we've removed any restricted or otherwise potentially dangerous items from our scope, we can move onto other areas of testing with the various tools within Burp Suite.

:::info
For reference, here is the PortSwigger documentation for Burp Target: https://portswigger.net/burp/documentation/desktop/tools/target
:::

### Tasks

1. Before leaving the Proxy tab, go back to the Intercept sub-tab and turn intercept off. We'll still see the pages we navigate to in our history and the target tab, just having Intercept constantly stopping our requests for this next bit will get old fast.
-->

1. In the **Intercept** tab, make sure you have turned off Interception Mode, if you have not done so already.

2. In the Burp Browser, you should see the Juice Shop site loaded from earlier. In the bottom-right corner, you should see a (somewhat obscurely-worded) prompt regarding cookies. Click the button labeled **Me want it!**, which allows the site to set cookies. (This is similar to prompts you see on other websites asking you to accept cookies.)


4. In Burp Suite, go to the **Target** tab. The request viewer should show a list of all the requests and responses the Proxy has observed, like the figure below. You can click on any request to see the request content and how the server responded:


7. The left sidebar shows a *site map*: a listing of all the URL paths and resources the proxy knows about for each site. You can expand this list to see the different pages and assets that make up the Juice Shop site (ie, `http://localhost:3000`).

##### Setting the scope

8. Before continuing, it's helpful to tell Burp that we want to focus on the Juice Shop site. To do this, right click on the site url (`http://localhost:3000`) and select **Add to scope** and then click **Yes** in the popup. This will cause Burp to automatically forward any requests not part of the target scope, which will help avoid dealing with unnecessary requests later.

##### Building the site map

9. Now, we want to gather some info about the site. Back in the Burp Browser, try to explore the various pages. You should see these changes reflected in the site map! This is useful for exploring large sites that auto-fetch content from many different places--the map shows the total set of paths observed for you to explore.

<!-- What do we call this representation of the collective web application?
-->
<!-- **Task 9:** What is the term for browsing the application as a normal user prior to examining it further? -->

<!-- **Task 10:** One last thing before moving on. Within the target tab, you may have noticed a sub-tab for issue definitions. Click into that now.

The issue definitions found here are how Burp Suite defines issues within reporting. While getting started, these issue definitions can be particularly helpful for understanding and categorizing various findings we might have. Which poisoning issue arises when an application behind a cache processes input that is not included in the cache key?
-->
## Burp Repeater: modifying and replaying requests

Finally, the [Burp Repeater](https://portswigger.net/burp/documentation/desktop/tools/repeater) allows us to repeat requests we've already made. These requests can either be reissued as-is or with modifications. Let's try out the repeater by making a request that the site normally wouldn't allow:
<!--
To start, click 'Login' (this might be 'Account' depending on the version of Juice Shop) in the top right corner of Juice Shop in order to navigate to the login page.


**Task 11:** Try logging in with invalid credentials. What error is generated when login fails?

But wait, didn't we want to send that request to Repeater? Even though we didn't send it to Repeater initially via intercept, we can still find the request in our history. Switch over to the HTTP sub-tab of Proxy. Look through these requests until you find our failed login attempt (hint: the more recent requests are at the bottom). Right-click on this request and send it to Repeater and then send it to Intruder, too!

**Task 12:** Now that we've sent the request to Repeater, go to the Repeater tab. Let's try adjusting the request such that we are sending a single quote (') as both the email and password. What error is generated from this request?
-->
1. Back on the Juice Shop site, go to the **Customer Feedback** page in the sidebar on the left. Submit a review.

2. In the Burp Target view, find the `POST` request that corresponds to your feedback submission, which should look like the figure below. (If it doesn't show up, you can also look for it under Proxy > HTTP history.)


3. Once you've found the request, right-click on it and select **Send to Repeater**. This sets up the request in Burp so we can modify it.

5. Switch to the **Repeater** tab, which should show the contents of your request, like this:

6. **Task**: modify your request to **submit a zero-star review** and click **Send**. You should see a response indicating that your feedback was accepted! This means the server isn't sanitizing reviews that don't meet their expectations, which is not good!

:::success
You just exploited a vulnerability in the site, yay! :tada: Once you submit your zero-star review, go back to the Burp Browser--the customer feedback page should now show a green banner saying you solved a challenge.

**To show you completed this lab, take a screenshot of this banner** and submit it with your homework for this part. (If you already clicked away from the banner, you can go to the **About Us** page from the side menu and scroll through the "Customer Feedback" images until you see your review, then take a screenshot of this instead.)
:::

<!-- Next, click on 'Contact Us' then 'Customer Feedback' (depending on the version of Juice Shop this also might be along the top of the page next to 'Login' under 'Contact Us').

With the Burp Proxy on, submit feedback. Once this is done, find the POST request in your HTTP History in Burp and send it to Repeater.

What field do we have to modify in order to submit a zero-star review?
-->
<!-- ## Burp Sequencer

While not as commonly used in a practice environment, Sequencer represents a core tool in a proper web application pentest. Burp Sequencer, per the Burp documentation, is a tool for analyzing the quality of randomness in an application's sessions tokens and other important data items that are otherwise intended to be unpredictable. Some commonly analyzed items include:

- Session tokens
- Anti-CSRF (Cross-Site Request Forgery) tokens
- Password reset tokens (sent with password resets that in theory uniquely tie users with their password reset requests)

We'll take a quick peek at how we can use Sequencer to examine the session cookies which Juice Shop issues.

:::info
For reference, here is the PortSwigger documentation for Burp Sequencer: https://portswigger.net/burp/documentation/desktop/tools/sequencer
:::

### Task 14

Switch over to the HTTP history sub-tab of Proxy.

We're going to dig for a response which issues a cookie. Parse through the various responses we've received from Juice Shop until you find one that includes a 'Set-Cookie' header (make sure to look at the "Response" tab of each request, not the "Request" tab).

Once you've found a request response that issues a cookie, right-click on the request (not the response!) and select 'Send to Sequencer'.

Change over to Sequencer and select 'Start live capture'.

Let Sequencer run and collect ~10,000 requests. Once it hits roughly that amount hit 'Pause' and then 'Analyze now'.

Parse through the results. What is the effective estimated entropy measured in? -->

# Extra resources

<!-- ## [optional] Burp Intruder

Burp Intruder can be used for many things ranging from fuzzing to brute-forcing. At its core, Intruder serves one purpose: automation.

While Repeater best handles experimentation or one-off testing, Intruder is meant for repeat testing once a proof of concept has been established. Per the Burp Suite documentation, some common uses are as follows:

- Enumerating identifiers such as usernames, cycling through predictable session/password recovery tokens, and attempting simple password guessing
- Harvesting useful data from user profiles or other pages of interest via grepping our responses
- Fuzzing for vulnerabilities such as SQL injection, cross-site scripting (XSS), and file path traversal

To accomplish these various use cases, Intruder has four different attack types:

1. Sniper - The most popular attack type, this cycles through our selected positions, putting the next available payload (item from our wordlist) in each position in turn. This uses only one set of payloads (one wordlist).
2. Battering Ram - Similar to Sniper, Battering Ram uses only one set of payloads. Unlike Sniper, Battering Ram puts every payload into every selected position. Think about how a battering ram makes contact across a large surface with a single surface, hence the name battering ram for this attack type.
3. Pitchfork - The Pitchfork attack type allows us to use multiple payload sets (one per position selected) and iterate through both payload sets simultaneously. For example, if we selected two positions (say a username field and a password field), we can provide a username and password payload list. Intruder will then cycle through the combinations of usernames and passwords, resulting in a total number of combinations equalling the smallest payload set provided.
4. Cluster Bomb - The Cluster Bomb attack type allows us to use multiple payload sets (one per position selected) and iterate through all combinations of the payload lists we provide. For example, if we selected two positions (say a username field and a password field), we can provide a username and password payload list. Intruder will then cycle through the combinations of usernames and passwords, resulting in a total number of combinations equalling usernames x passwords. Do note, this can get pretty lengthy if you are using the community edition of Burp.

<p style="text-align: center;"><i>Intruder Attack Type Selection</i></p>

For our purposes, we'll be returning to the SQL injection vulnerability we previously discovered through using Repeater.

:::info
For reference, here is the PortSwigger documentation for Burp Intruder: https://portswigger.net/burp/documentation/desktop/tools/intruder
:::

### Task 15

Download the wordlist for the following tasks here. This is a shortened version of the [fuzzdb SQLi platform detection list](https://github.com/fuzzdb-project/fuzzdb/blob/master/attack/sql-injection/detect/xplatform.txt).

Return to the Intruder in Burp. In our previous task, we passed our failed login attempt to both Repeater and Intruder for further examination. Open up the Positions sub-tab in the Intruder tab with this request now and verify that 'Sniper' is selected as our attack type.


Burp attempts to automatically highlight possible fields of interest for Intruder, however, it doesn't have it quite right for what we'll be looking at in this instance. Hit 'Clear' on the right-hand side to clear all selected fields.


Next, let's highlight the email field between the double quotes ("). This will be whatever you entered in the email field for our previous failed login attempt.


Now click 'Add' to select our email field as a position for our payloads. Note the added characters around the string you highlighted.


Next, let's switch to the payloads sub-tab of Intruder. Once there, hit 'Load' and select the wordlist you previously downloaded in question five that is attached to this task.


Almost there! Scroll down and uncheck 'URL-encode these characters'. We don't want to have the characters sent in our payloads to be encoded as they otherwise won't be recognized by SQL.


Finally, click 'Start attack'. What is the first payload that returns a 200 status code, showing that we have successfully bypassed authentication?

-->

<!-- Since we now have Burp Suite running, the proxy service will have started by default with it. In order to fully leverage this proxy, we'll have to install the CA certificate included with Burp Suite (otherwise we won't be able to load anything with SSL). To do this, start by launching Firefox. -->

## Using Burp with Firefox and FoxyProxy

The default Burp browser uses Chromium, which is the open-source version of Google Chrome.

Chrome is sometimes extra-vigilant about blocking certain kinds of attack payloads, so some attacks may be more successful using Firefox. (To check if Chrome is blocking your attack, you can look in the console view under View > Developer > Developer tools and look for any errors that seem relevant to your attack.)

We can configure a standard version of Firefox to use burp by setting it up to send traffic to Burp's proxy. There are several ways to do this in Firefox, we recommend using an extension called [FoxyProxy](https://addons.mozilla.org/en-US/firefox/addon/foxyproxy-standard/). See the next sections for instructions on how to configure and use FoxyProxy to set up Firefox with Burp.

### Installing FoxyProxy

To do this:

1. In Firefox, go to the [FoxyProxy addon page](https://addons.mozilla.org/en-US/firefox/addon/foxyproxy-standard/), which looks like this:
Once you open the link in Firefox, you should see this:


2. Click **Add to Firefox** to install the addon (you can accept any prompts)

3. Find the FoxyProxy icon in your extensions toolbar in the top-right of the Firefox window. (If you don't see FoxyProxy in your toolbar, you might have to click on the puzzle piece icon and add FoxyProxy to the toolbar.) The FoxyProxy icon should look like this:


4. In the FoxyProxy menu, click **Options**:


5. Switch to the **Proxies** tab, and click **Add** in the top left:


6. Enter in the following settings, as shown in the figure below:
- Title (can be anything you want): Burp
- Hostname: 127.0.0.1
- Port: 8080


7. Click **Save**. FoxyProxy now knows how to connect to Burp!

:::warning
**Warning**: By default, Firefox **not** send traffic to Burp--it only does so when you turn on the proxy! See the next section for details.
:::

### Turning on the proxy

Firefox will only forward traffic to Burp when the proxy is enabled. To do this:

1. Open the FoxyProxy extension menu, which should be in the top-right of your Firefox toolbar. If you can't find it, click on the puzzle-piece icon.

2. Click on **Burp**. This turns on the proxy


When the proxy is on, all traffic from Firefox is being sent to Burp. When Burp is in intercept mode, you should see it begin to intercept requests!

:::warning
**Super important**: If you haven't done so already, [**set your target scope**](#Setting-the-scope) in Burp to the site you are attacking. This will make sure that Burp only intercepts traffic for this website. This is especially important if you are using Firefox as your default browser--if your target scope isn't set, Burp will intercept traffic from *all of your tabs*, which is probably not what you want!

**In fact, when Intercept mode is on, loading almost any *real* website (not our assignments) will give the warning, "Your connection is not secure"**--this is because Firefox knows that something is intercepting your traffic, which is normally a security risk! This happens because all modern websites use HTTPS, which is designed to detect this behavior. We'll learn more about HTTPS later in the course.

The security warnings should normally not affect your work on the project, so long as you set your target scope in Burp. If you *really* want Burp to be able to intercept HTTPS sites using Firefox, see [this section](#Optional-Install-Burps-CA-certificate-in-Firefox).
:::

### Optional: Install Burp's CA certificate in Firefox

All of the websites you will attack in this course will use plain HTTP. To intercept HTTPS traffic using Burp, your browser needs to be configured to use Burp's CA certificate, which convinces the browser that communications intercepted by BUrp are authentic. The Burp browser is already configured to do this for you. If you want to set up Firefox this way, expand the instructions below.

<details><summary><b>Click to expand</b></summary>

<!-- Before we can start using Burp Suite to intercept web traffic, we'll have to fix a certificate warning. We need to install a CA certificate as Burp Suite acts as a proxy between your browser and the internet - it allows the Burp Suite application to read and send HTTPS data (we will explain this more later in the course, but for now, you need to do this for the lab). -->

<p style="text-align: center;"><i>A certificate warning that will appear unless we install Burp's CA Certificate.</i></p>

With Firefox, navigate to the following address: http://localhost:8080

You'll be greeted with the following website:


Click on 'CA Certificate' in the top right to download and save the CA Certificate.

Now that we've downloaded the CA Certificate, click on the 3 bars in the top right and go to 'Settings'. Search for 'Certificates' in the search bar.


Click on 'View Certificates...'


Next, in the Authorities tab click on 'Import'


Navigate to where you saved the CA Certificate we downloaded previously. If you left it as default, it should be called 'cacert.der' in the root directory. Click 'Open' once you've selected this certificate.

Finally, select the following two options as in the below screenshot:


Select 'OK' once you've done this. Congrats, we've now installed the Burp Suite CA Certificate!
</details>