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.
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.
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!