Intro to Burp Part II: Sighting in your Burp Scope
This is Part II of our series on setting up and using Burp Suite. In this post, Ken Toler will be going over how to properly use Burp Scope during your web app assessments.
As Security Professionals, most of the time we have to step outside of the “nuke-it-all” mind set when conducting assessments. Web applications can make that process a bit tedious and we always want to make sure we’re setting ourselves up for a thorough assessment. That’s where identifying and setting your target really comes into play. You want to find that perfect balance between ensuring everything your targeting is touched and that you don’t go and unintentionally hit public or 3rd party services and sites.
I mentioned before that I am personally a huge fan of BurpSuite and this topic is no exception. BurpSuite offers many options in setting up your target, but you can certainly step on your own feet in more ways than one. This guide will get you set up with proper scoping as well as what to watch out for so you don’t end up roadblocking yourself.
A few notes before we get started:
In this tutorial, I’m using the professional edition of BurpSuite and while the instructions in this guide are the same, some of the screenshots may differ slightly. If you have any questions or something doesn’t look right, feel free to drop me a line and I’ll respond ASAP.
First, if you’re new to BurpSuite and need help installing, please reference my other guide here:
This article assumes you have BurpSuite setup and that you’ve had a chance to work with running your web traffic through the proxy.
The first setting we want to tweak is our Target Scope. This will tell BurpSuite what addresses or group of addresses you want to see web traffic for. There are a ton of options, but we’re going to focus on targeting by URL.
You’ll want to start by heading to the “Target” tab, and selecting the “Scope” tab on the second row of tabs.
Click the “Add” button and you’ll be presented with a screen to add a URL into your target scope. In this example, we’ll use https://www.hackthissite.org/
You should note that you can include a host or IP range here. URL’s should be added one at a time, but you can also use wildcards here. An example of this would be using *.com to reach all .com domain names or you could use *.google.com to reach sites in the google domain. This would include mail.google.com, music.google.com, www.google.com, etc.
Additionally, you can provide port numbers if you know your target application only works over a single port or port range. You can also provide a file variable or regex. This allows you to filter by particular files or pages. For example, if you only wanted to see calls to the logout page you may include something like “logout” here. For now, we’ll leave both of these additional options blank.
Go ahead and click “OK” and you’ll see your target added to the scope.
Next, we’ll add a catchall. Go through the same process, but instead of adding a URL, leave all of the input boxes blank and select “Any” for the protocol.
You’ll see that we have two targets in our scope. You can enable/disable these as you see fit, and since we’re only focusing on one site at the moment, let’s click the checkbox to deselect the enabled box for the “Any” target. Now any time you want to go back to viewing all the traffic, you will have this target rule to use.
Next, let’s take a look at exclude rules. BurpSuite has some nifty ones set up for us already. You’ll see the “File” I mentioned earlier filled out on most of these.
This excludes logout, login, exit, and signout pages from the scope. Without getting into too much detail, these are here so that when you’re running the scanning tools you don’t accidentally log out of an application during testing. Keep in mind though, these “File” settings are just guesses BurpSuite makes about applications in general. An example might be that your target application uses something like userlogout instead of logout to end a session, these settings won’t pick that up. You should aim to tailor these settings to your application and you can enable or disable these as you see fit for your assessment.
Keep One Eye Open
The next step is very important and it’s often missed in practice. You can think of the target tab as a variable in BurpSuite that doesn’t NECESSARILY have to be used in the other tools of the suite. It’s there for convenience, so we have to make sure that our tools are using our Target scope. Let’s head over to the “Proxy” tab and select “Options”
If you scroll down, you’ll see the subsections “Intercept Client Requests” and “Intercept Server Responses”. Make sure that the highlighted option is enabled and included for “And URL Is in target scope”
Don’t worry if they’re not there, we’re going to add them now.
Click “Add” under “Intercept Client Requests”
You’ll be presented with a window to fill out and select the following
Click “OK” and repeat this step for the “Intercept Server Responses” subsection.
This step makes sure that your Proxy uses the target scope when intercepting requests and responses and will not intercept traffic that does not match these patterns.
You may also want to take these same steps with the Spider and Scanner tools. Spider is located under the “Spider” tab in “Options” and Scanner settings are located under the “Scanner” tab under “Live Scanning”. You want to make sure “Use Suite scope” is checked as in both examples below
A clarification, traffic you’ve set in your browser to go through BurpSuite is still passed, and you can see this traffic in the proxy tab under “HTTP History”
Now, when I said that you could shoot yourself in the foot with these settings I meant it. Often times you’ll find yourself wondering why traffic isn’t passing through the proxy. Before freaking out, always be sure to double check the scope and intercept settings before moving on.
Additionally, you can tweak this traffic creatively during an assessment if you want to filter out traffic. You can narrow it down on either the target tab or the proxy tab depending on your preference. You can also conduct a more targeted assessment on a particular portion of a web application this way by getting rid of the noise.
I will usually start an application assessment with filters and target as broad as possible. I will usually include the login and logout functions just to see what the site responds with and visit each page manually. Then I’ll add the logout functions to the file filters before using scanner or spider to make sure that I don’t hit any external resources. If there is something particularly interesting with the application I will want to take a closer look at it.
Careful here though, filtering down too much could make it so that you miss important traffic. Typically I filter down to inspect a particular component or structure of an application. Perhaps you only want to look at the login mechanisms and know the ins and outs of the application. You can add those pages to the scope. It’s always smart to filter back out, and reinspect the broader picture with the knowledge of your findings.
I hope this post has been helpful, and that you feel like you can target applications effectively and accurately after reading it. As always feel free to send questions my way, I’m always happy to help. Happy Hunting!