Configure Burp Suite to use the forwarded local port as a SOCKS proxy; Use the ProxySwitch browser extension to send only selected sites towards Burp Suite and through the VPN On Windows, using PuTTY, you can use the following configuration to forward local port 31337 to your jump host on port 2222. Burp Suite is a suite of web application testing tools that help you intercept, modify and automate your interactions with a web application. If you do CTFs, this will make your life a lot easier. And if you want to get into web application, Burp Suite is a great tool to have. This post covers installation, configuration, and the Target. Chrome browser proxy option. Firefox browser proxy option Now click on manual proxy enter the Proxy address and port number depending on the changes you have done in your burp suite proxy. If you have a default setting in your burp suite with localhost 8080 port then enter it and check to Use this proxy server for all protocols.
- Burp Suite Proxy Settings Chrome
- Burp Proxy Free
- Burp Proxy Free Download
- What Is Burp Proxy
- Burp Suite Free Download
In this post I will discuss the different features of burp suite, how to use them and how they are useful. I will also discuss how to set it up with different browsers and some advanced tips for the pro version. Also note that some of the tabs are only available in the pro version. This won't be a full on guide to everything as that is likely to be spread over a few posts.
What is Burp Suite?
Burp Suite (burp) is a web application testing tool designed by Portswigger. Currently it is the industry standard for web application penetration testing. It is also widely used by many individuals who partake in bug bounty hunting. This post discusses a few key features of the suite and some interesting tips along the way.
Before we go anywhere you're going to need to setup your environment. In order to do this you'll need two things; a Testing Browser & of course burp suite - this can be the free version or the pro version. I'll explain how to setup burp suite with both Firefox & Chrome, however these are not the only two browsers available.
My personal preference as a testing browser is FireFox Developer Edition with the foxyproxy plugin for setting proxy settings. Photoshop portable online. Firefox Dev edition has several benefits over normal firefox however it works just the same. The main reason for using it vs normal vanilla firefox is that there are extra dev tools built in plus there is a cool dark theme which is always nice.
Step 1: Download the software you need; browser, plugins & burp suite, all of which are linked above.
Step 2: Open burp and setup the browser proxy settings.
- Open Firefox and install foxyproxy if you haven't already, next left click on the fox icon next to the address bar, this will bring up the foxyproxy config window.
- Open Firefox and install foxyproxy if you haven't already, next left click on the fox icon next to the address bar, this will bring up the foxyproxy config window.
Select 'Add new proxy', in host/IP address enter
127.0.0.1and port as
8080then select OK to save. These values are the default listener settings for Burp Suite.
Now that we have firefox configured, move over to burp and either select to create a temporary project or a project with a name and file location(note this is only available in the pro version of burp). Generally if you're delivering a job it is useful to have a project file which will store all of your traffic.
Within Burp navigate to the
proxy tab>options> Proxy Listenersand insure that there is one running on
Step 3: To test we have a listener set up, navigate to Firefox, right click on
foxy proxyand select the proxy we setup earlier. Then, browse to a web site or IP. If the listener is configured correctly it should show a request within the proxy tab in burp. You have the option to forward or drop the request. Now that this is setup you can turn intercept off and all traffic will still flow through burp however intercept will allow you to 'play' with requests.
The setup for chrome on windows is much the same as Firefox, as it can be configured to use foxy proxy. Specifically setting up chrome with foxy proxy is the same as it is on Firefox. Install the extension from the chrome web store and you should be good to go.
Only available in the pro version
Project files very useful as I mentioned earlier, they store all of the traffic sent in a session including both in scope and out of scope hosts which can be useful to view later.
Essentially think of a project file like a temporary save location for information stored in your burp session that can be loaded at a later date. They work along side being able to save your session to disk which is accessible from the burp menu in top left hand corner of the screen
burp > save state.
The target tab is one of the most useful tools within burp as it holds the site map for target sites that you are testing. Within the target tab there are two sub tabs, the Scope tab and Site map. Specifically the main information for an application that you are testing is held within the site-map tab.
It can be configured so that only targets that are within scope are displayed. To do this first you'll need to configure the sites within scope. Navigate to
Target > Scope then
Include in scope. This option will allow you to either paste a URL from the address bar or add manually using the
add button. Additionally you can load a list of targets from a text file using the
Load button, this can be very useful for adding in several hosts at a time.
Top tip for open scoped engagements, if a scope states that
*.domain.com is within scope you can add this to burp's scope using:
^*.domain.com$. This will add all potential sub-domains into scope, what this also means is should you identify other hosts while browsing the main target they will automatically be added to scope and displayed in the site-map.
Besides displaying all of the hosts browsed to in a burp session the site map tab can be tuned to only view the hosts you have set that are within scope. This can be achieved by clicking on the bar just below
Site map and selecting
Show only in-scope items. This will allow you to only view targets you've set as in scope. The image below demonstrates where this option can be found.
This menu area also allows you to tweak what is displayed, it can be useful to view only requests that have generated types of errors.
The spider tab can be used for discovering content on a site however I don't use if very often as it does generate masses of traffic. Additionally it can cause issues with the target applications if not tuned correctly.
To use it correctly, I suggest you disable the auto-form submission and auto login 'features' to insure minimal traffic generation. Doing so will prevent burp from attempting to flood the target site with form submissions of
Only available in the pro version
The scanner tab is very useful as it picks up on 'low hanging fruit' vulnerabilities within an application. However like all of the other tools within the suite it can be tuned to work better. By default the options for it are pretty good but with tuning it can be great!
Pairing Intruder with Scanner
Only available in the pro version
To tune the scanner there is a little known trick that will allow you to pinpoint scanning. This can be achieved by trapping a request that has parameters you want to scan then, right clicking on it and sending it to intruder. Once the request is in intruder manually select the areas in which you want to scan then select
Actively scan insertion points. This will send the scanner off against only the points in which you've selected instead of randomly scanning points in the app/target.
This can be very useful for pinpointing vulnerabilities in applications that would otherwise be missed potentially.
The repeater tool is arguably the most useful and powerful section within the burp suite tool set. It allows requests to be passed to it and modified then resent to the server. During a test I will spend a lot of time in here playing with requests and modifying different parameters to see their responses.
Specifically it has two main uses, the first of which allows free manipulation of requests. Allowing you to target specific parameters and functions within an application. The second while not a feature or possibly not the intended use, it can be used as a clipboard/archive or interesting requests for you to go back to look at. Imagine you're looking at an application which shows signs of processing certain characters differently, you can right click and send this to repeater to look at later. Having the request in repeater will allow you to manipulate it at a later time.
The intruder tool has many many functions, however in this post I am only going to discuss a few of these. Mainly it can be used for fuzzing, error checking & brute-forcing.
In order to utilise intruder, select an interesting request either from the proxy intercept or another you've previously saved in repeater. Right click and select
send to intruder. When the request is within intruder select the positions tab to select your inputs, this will look similar to the image below.
The payload positions are up to you to set, however burp will auto-select what it thinks are parameters, you can clear this using the clear button, then select your own ones by selecting the parameter then choosing
add §. There are four attack types available to use in intruder, the subsections below explain what each does.
The sniper attack takes one wordlist as an input and iterates over over each parameter, one at a time. If you have multiple insertion points, it will enumerate the first parameter with all the payloads from the wordlist supplied and move on to the next and so on. It is best used when you're wanting to fuzz either single or multiple parameters with the same wordlist.
Like the sniper attack, the battering ram uses a single wordlist however it will iterate over multiple parameters with the same payload for all the parameters. This can be useful when you're looking at how different parameters react to certain payloads.
The pitchfork attack type runs through multiple parameters at the same time using different payloads for each parameter. This takes a single or multiple wordlists but will iterate through the words in the list split across selected parameters. An example of this is shown:
The cluster bomb attack type will take multiple wordlists and is useful when you have multiple parameters. It will run through over multiple parameters by using all the possible combinations of payloads from the multiple wordlists. So if you have multiple parameters, it will enumerate over one of the parameters with all the payloads from its respective wordlist, while the other parameters have the first payload from their respective wordlists loaded.
This can be very useful for when you are brute-forcing logins or other parameters/forms requiring two or more inputs.
Brute Forcing Basic Authentication
A scenario where intruder can be very useful is when it comes to brute-forcing a HTTP basic authentication login mechanism. In order to do this, first you must issue a base request with any values as the username and password, send this to intruder. I've included an example below.
Notice the bottom header
Authorization: Basic YWRtaW46YWRtaW4= this is the login value of admin:admin in
base64. In order to attack this we're going to use some of burp's more advanced intruder settings.
Mainly the custom iterator function, which allows you to split payloads up by a certain character or set of characters of your choosing. In this example I'll be demonstrating a brute-force using a wordlist, which in other words is a dictionary attack as opposed to a pure brute-force attack.
Using a custom iterator allows you to generate your own custom payload string consisting from several substrings. For each substring you can specify what the separator is which is basically a suffix. The Intruder calls these substrings “positions”.
Setting up the attack, the first thing to do is select the base64 string in the
Authorization: Basic header and change the attack type to
sniper. Next go to the
Payload tab and select the
Custom iterator option from
Payload type menu.
position 1 from the
Position menu and load your usernames list in this . Put a colon(
:) in the Separator for
position 1 text box.
Then change the position to
2 then in position 2, load the values you want to use for password guessing, just as you did for position 1.
After you’ve set your two positions you need to tell the Intruder to encode the payload string using Base64 encoding. To do this go to Payload processing section and click Add button. Select Payload encoding option and then Base64.
By default burp intruder will URL encode select characters, I recommend that you remove the
= symbol as it is used by base64 for padding and this can introduce issues later on.
When this is done simply select start attack, burp will now run through the usernames and passwords you've provided.
As with all of the tools within burp suite, each has a useful function. The decoder tool is all in the name, it decodes a select type of character sets and encoding types:
- Plain Text
- URL Encoding
- ASCII Hex
Each of which can also be encoded into using the decoder tool. This is particularly useful for when you encounter parameters and data within requests which is encoded. By default burp will attempt to auto detect the encoding however you can manually select which type of encoding to decode as too. Decoder can also be used to take checksums of strings, using a variety of hashing functions, these are located in the
hash drop-down menu.
The sequencer tool has many functions but its main use is for checking the entropy of tokens and cookies. It is accessible by sending requests to it that can then be replayed in the 100s or 1000s to check the randomness of created values. This can be very useful for testing the randomness of cookie or CSRF token generation, mainly a use when testing authentication and authorization but can also be used for testing UUID and GUID values too.
Comparer is essentially a diff tool to allow you to check the differences between two or more requests either based upon the words or bytes. This is useful when an application reacts differently to certain characters or words being used, it can be useful to identify more information about injection type vulnerabilities. To use it simple right click on a request and select send to comparer, then select a second request and do the same. Then navigate to the comparer tab and your requests should be there now. Simply select bytes or words, this will show a comparison of the requests you've sent and highlight the differences.
Finally the extender tab is where add-ons/plugins for burp are located. Housed within this tab is where extensions can be installed and added. Additionally all information surrounding various environment files such as Jython and Jruby can be set within this tab. This allows for usage of other 3rd party extensions build by developers that have been approved by Portswigger. Also located within this tab is information surrounding all of the APIs that Burp suite uses, allowing you to write your own extension. For more information on creating an extension check out Portswigger's site here.
If you want to learn more information about certain aspects of burp suite that you're unsure of. The application does have a very comprehensive inbuilt help function. This is located in the help tab in the top menu bar.
Did you enjoy this? Check out the other #ltr101 posts here or consider buying my book.
In my last post I covered setup for Burp Suite, as well as the Proxy and Target tabs.
This blog post will cover the Spider, Intruder and Repeater tools, which start to show the usefulness and power of Burp Suite. Since everything is more fun with examples, I’ll be using practice hacking sites to demo some of these features. : )
If you don’t have Burp Suite set up yet, check out this blog post first.
First up is the Spider tool, which is a web crawler. Burp’s website states:
Burp’s cutting-edge web application crawler accurately maps content and functionality, automatically handling sessions, state changes, volatile content, and application logins.
In other words, it programmatically crawls a website(s) for all links and adds them to the Site Map view in the Target tab. If you worked through the last post and its examples, then you have already (passively) used the Spider tool.
Why is this useful? Having a complete site map helps you understand the layout of a website and makes you aware of all the different areas where vulnerabilities might exist (for example, seeing the gear icon on a page means that data can be / has been submitted). Doing that by browsing through the website is time-consuming, especially if you have a very complex website.
The Spider tool does all of that for you by recursively finding and requesting all links on a given website.
Make sure you set your scope before you run the Spider tool!
We covered scope in the last blog post, but it’s a way of limiting what websites are shown to you within Burp, and what websites are used by other tools (which sites do you want to be sending requests to?)
In this example, I’ll be using XSS Game first. First, I turn FoxyProxy on in my browser, and make sure that the settings in the Proxy > Options tab match my FoxyProxy options.
Next, I go to the Target > Scope tab to set my scope. I add a new scope and type “xss-game”. If you do not set a scope when spidering, it will crawl things outside of your intended target. Depending on what those sites are, that might be bad. 🙃
If you go to Spider > Control, you can see that the scope defaults to “Use suite scope”, which is the scope we just defined. You can also set a custom scope if needed, which will function separate from the scope applied to other tools.
To start spidering, you have a few different options. As we saw in the last blog post, you can right-click a request from numerous places (Proxy > HTTP History, Proxy > Intercept, Target > Site Map, etc.) and send the request to other tools.
In the Target > Site Map view, you can see that I’ve already visited one site from XSS Game (I visited the splash page).
Right-click this and select “Spider this branch”. In other views, you can right-click a request and say “Spider from here”.
When I do this, I can see that the Spider tab has lit up orange.
If I want to see how many requests are being made, or if I need to stop the tool for some reason (maybe things are getting recursively crazy), go to Spider > Control.
If the “Spider is running” button is grey/depressed, that means it’s currently running. You can press the button to stop it, and then clear any upcoming queues if need be.
Here are the results:
In this case, the results aren’t that impressive. We probably could have found most of those by just browsing. But, hopefully it’s clear how this would be useful for much larger websites.
Form Submissions and Other Options
I also ran the Spider tool on a local copy of OWASP’s WebGoat tool (which meant that I had to add
localhost to my scope before Spidering). WebGoat is an intentionally vulnerable web app used to teach various attacks, and includes two different login accounts.
When I started running the Spider tool, I saw this pop-up in Burp:
I already knew the login (it was provided), so I typed “guest” and “guest” into the username and password fields. But then the form submission pop-up appeared again. If this was a bigger application, then this would get very annoying very quickly.
If we got to the Spider > Options tab, and scroll down, we see that there’s automated responses that we can choose for a login form:
It defaults to “prompt for guidance” but we could change the settings with our known credentials.
If you scroll up or down on the Spider > Options tab, you’ll see that there are automated responses for other forms as well. Be sure to look this over and either modify the field values, turn automated form submission off, etc.
The Options tab is also where you can turn off “passive spidering” (where Burp adds information to your Site Map as you browse). Max link depth and parameterized requests per URL can also be configured on this page.
The Spider tool is a web crawler that recursively requests every link it finds, and adds it to the Site Map. Before you use it, it is important to set the scope (Target tab) and also define the Spider’s behavior when it encounters logins or other forms.
The Proxy tool lets you intercept requests, and the Site Map and Spider tools help show the breadth and depth of a target. But finding malicious payloads (or CTF flags) happens at the single-request level.
The Repeater tool is a manual tampering tool that lets you replay individual requests and modify them. This is often called “manual” testing.
I’ll be showing the Repeater tool on the XSS Game website (I’m doing this in Firefox; Chrome has a XSS blocking feature).
In the Proxy > HTTP History or Target > Site Map view, right-click on a single request and select “Send to Repeater”. The Repeater tab should light up orange. Here, I’m right-clicking on a
/level1 request for XSS Game where I’ve sent a query (“hi”).
This will show up in the Repeater view as a numbered tab (which you can rename).
If I click “Go” it will send the request again, and I can see that the query string of “hi” (once again) did not allow me to move to the next level of XSS Game.
Let’s try this again and swap out “hi” for “alert(‘hi’)”. I can do this by highlighting “hi” and typing my new payload.
Then, I can click Go. I see in the output that my script tags are still intact, which means that my XSS attack might work. From here, I have two options. I can either:
- Copy/paste my payload into the website and do it manually, or
- Use Burp to automate a browser request.
I want to do the second option, so I right-click anywhere in the Response area, and say “Request in browser” and select “original session”.
This will pop-up a window with a temporary link. If you copy/paste this into your browser, then you will be redirected to the website with the payload you created in Burp.
Once again, yes, this is a simple example, but it simplifies a lot of the trial-and-error that might occur while testing out a page.
Better yet, you also get forward and back history buttons, so if you want to go back to a previous request you made, it has already been saved in your history, and it’s easily accessible.
Additionally, the response payloads will likely be much bigger in a “real” website. You can use the buttons at the bottom of the Response view to search for terms (i.e. “Success!') matching strings or regexes.
Lastly, the responses can be viewed in a variety of ways. You can see the raw response, just the headers, the HTML, or the rendered page.
Burp Suite Proxy Settings Chrome
Repeater is a manual tampering tool that lets you copy requests from other tools (Proxy, Target, etc.) and modify them before sending them again to the target. The Repeater makes it easy to modify the payload, and also provides links so that you can quickly repeat the attack in the browser.
The last tool covered in this post is the Intruder tool. Imagine if we wanted to login to an application but we didn’t know the username or password. We could copy a login request over to the Repeater tool, and then manually select the username and password and replace it each time with some options from a list.
Of course, we’d have to do this hundreds or even thousands of times. If we want to automate a process like this, where we have a changing parameter and a known set of values that we want to try, then it’s time to use the Intruder tool.
I’m going to use OWASP’s WebGoat site for this example, since it has a login form. I have this running locally. I go to the login form on the site, and try a username/password combination (I know the correct combination but for this example, let’s pretend that I don’t know).
In the Proxy > HTTP History tab, I find the request that corresponds to my guess.
I right-click on the request view and select “Send to Intruder”. I should see the Intruder tab light up orange, denoting that there’s new activity in that tool.
Burp Proxy Free
If we click over to the Intruder tab, we see this. **It’s a very good idea to double-check these values each time, as the Intruder tool is going to send a LOT of requests to your target. ** Make sure it’s correct so you’re not sending these requests to someone else!
Next, click on the Positions tab. Burp Suite has helpfully identified what it thinks are values that we want to parameterize. In this case, the session ID, the username and the password.
If we want to set this ourselves, we can click “Clear”. Then, highlight the value you want to parameterize and click Add. This will add squigglies around the word. Parameterizing values means that we can programmatically change the value in our requests.
In this example, I’ve parameterized the username and password values. Then, I selected “Clusterbomb” as the attack type. This means that it will try every username and password combination that I give it (factorial options).
Next, click the Payload tab. Since we have two payloads (username and password), we will have to set each one individually. You can select one at a time from the first section:
We’ll use “Simple list” as the payload type for this, but there are many other options, like “numbers” which could be used to find IDs or change a value in a longer string of characters.
If you have the Pro version, then you can use pre-defined lists in Burp. If you are using the free version, you can either load in a list (i.e. “Rock you” for passwords, etc.) or create your own list. For this example, I will make my own list of 4 possible usernames by typing them in and clicking add. Since Payload Set “1” was selected in the Payload Sets section, this applies to my first parameter, which is username.
Next, I have to set the Payload Set to “2” and make some possible passwords.
Now I can see that I’ve got a request count of 12, which makes sense. I’ve got 4 usernames and 3 passwords. If I try every combination (since I set my attack type to “Clusterbomb”), then I will have 12 requests.
Next, I click “Start Attack” in the Payload Sets options. If you have the free version, your attacks will be throttled, so big lists will take a long time. 12 requests should go pretty quickly, though.
I’ll see a pop-up window that lists all the attacks. In “real” attacks, this would be much longer, so I can use the Grep – Match tool in Intruder > Options, or just sort by HTTP status code or response length to find the interesting responses.
In this case, it’s obvious since we have such a short list. The last combination, which is “guest” / “guest”, returns a much longer response than the other attempts. This is the correct set of credentials (the added response length is from the login cookie we received).
Burp Proxy Free Download
As with the other tools, the Options tab is worth checking out. You can limit the number of threads/retries/etc. You can also use the Grep sections to sort through your attack results easier.
What Is Burp Proxy
The Intruder tool automates requests when we have positions whose values we want to swap out, and we have a set of known values for those positions. We can configure the attack with user-, list- or Burp-defined values for each position, and use grep and other tools to sort through the results.
Burp Suite Free Download
After discussing Burp Suite setup, and the Proxy and Target tools in the last blog post, this post discussed the Spider, Repeater and Intruder tools. Spider is used to more thoroughly map out a site, Repeater is used for manually tampering and replaying requests, and Intruder is used to automate a large number of requests with parameterized values.