Tuesday, March 22, 2011

Burp v1.4 preview - Testing access controls using your browser

In the previous post, we described how the "compare site maps" feature can be used to automate much of the laborious work involved in testing access controls. In some situations, however, performing a wholesale comparison like this may not meet your needs. It may be that you prefer to work in a more piecemeal way, individually testing the controls over a small number of key requests. Further, where a sensitive action is performed using a multi-stage process, simply re-requesting an entire site map in a different user context many be ineffective. In this situation, to perform an action, the user must typically make several requests in the correct sequence, with the application building up some state about the user’s actions as they do so. Simply re-requesting each of the items in a site map may fail to replicate the process correctly, and so the attempted action may fail for reasons other than the use of access controls.

For example, consider an administrative function to add a new application user. This may involve several steps, including loading the form to add a user, submitting the form with details of the new user, reviewing these details, and confirming the action. In some cases, the application may enforce access controls over some of these steps but not others. For example, the application may protect access to the initial form, but fail to protect the page that handles the form submission, or the confirmation page. The overall process may involve numerous requests, including redirections, with parameters submitted at earlier stages being retransmitted later via the client side. Each step of this process needs to be tested individually, to confirm whether access controls are being correctly applied.

The new version of Burp contains several features to facilitate this kind of testing. Firstly, when you are testing multi-stage functions in different user contexts, it is often helpful to review side-by-side the sequences of requests that are made by different users, in order to identify subtle differences that may merit further investigation. Burp now lets you:

  • Filter the proxy history based on the local proxy listener.

  • Open additional proxy history windows, each with its own filter.

To use these features to help test access controls, you need to use a separate browser for each user context you are testing, and create a separate proxy listener in Burp for use by each browser (you will need to update your proxy configuration in each browser to point to the relevant listener). For each browser, you can then open a separate proxy history window in Burp, and set the filter to show only requests from the relevant proxy listener. As you use the application in each browser, each history window will show only the items for the associated user context.

To open a new proxy history window, use the context menu on the main proxy history tab:

You can then use the filter bar on each window to show requests from different proxy listeners:

So far, this just gives you a way of separating the series of requests made by different user contexts. To actually evaluate access controls over a multi-stage process, you need to test each stage individually, reissuing the request in a different user context, and determining how this is handled by the application. This can often be a laborious process, and involves walking through the multi-stage process repeatedly using your browser, intercepting requests using the proxy, and updating the cookie in one or more requests so that they are issued in a different user context.

A further feature in the new version of Burp takes away some of this pain. It lets you select a request anywhere within Burp, and reissue the identical request from within your browser, within the browser's current session with the application. Using this feature, you can test access controls over a multi-stage process in the following way:

  • In your Burp proxy history, find the series of requests that are made when a higher privileged user performs the multi-stage process.

  • For each request, select the "request in browser in current session" option from the context menu. This gives you a unique URL to paste into your browser.

  • Paste the URL into the address bar of a browser that is logged in to the application as a lower privileged user who should not be able to perform the action. (This browser must be configured to use Burp as its proxy.)

  • If the application lets you, follow through the remainder of the multi-stage process in the normal way, using your browser.

  • Review the results to determine whether the lower privileged user was successful in performing the action.

This methodology, of manually pasting a series of URLs from Burp into your browser, is normally a lot easier than repeating a multi-stage process over and over, and modifying cookies manually using the proxy. In general, the new feature provides a highly efficient means of grabbing a request from the site map, or proxy history, or anywhere else, and repeating the request within your current browser session, to see how it is handled.

For people who are interested, the new feature is implemented as follows. When your browser requests the unique URL provided by Burp, Burp returns a redirection to the URL in the original request that you selected. When your browser follows the redirection, Burp replaces the outgoing request with the full request that you originally selected (headers and body), with the exception of the Cookie header, which is unmodified. When the browser receives the application's response to this request, it processes it in the context of the original URL, so all relative links, DOM access, etc. work correctly. Neat, huh?


Jacob said...

Great posts demonstrating the new functionality and how it can be used in a work flow.

I guess my next question is, when will the ability to have multiple contexts be available via configuration in Spider | Options | Application Login ? :)

It would be useful to be able to store/use multiple accounts.

Then a follow up feature request would be to define a "macro" consisting of 1 or more 'steps'/URLs to visit in succession?

Thanks again for the great tool.

PortSwigger said...

@Jacob Watch this space! Hopefully some of the other new features will do what you are looking for.

Anonymous said...

I hate java. But I love Burp. I even like the new logo.

The two newly described features are good. I'm awaiting the ability to use intruder with multi-step processes. And by waiting I mean writing my own proxy that can do same and discovering just how awesome you are for actually writing burp because writing a proxy sucks!

If there was more examples for the burp api I'd be inclined to delve further into java, but the initial investment looks to be too great.

Random: Do you have a publicly accessible list of feature requests?

PortSwigger said...


Testing multi-step processes in Intruder? Watch this space!

You can just email me with feature requests (contact link at bottom of page).

Anonymous said...

I wasn't looking to ask for more stuff just yet (public feature request list). :) I was more wondering what types of things people have been asking you for. If there were any items of interest to me, it would help motivate me to work with java and maybe write some extensions.

Last year in some random comments I asked for multi-step fuzzing. I figured it was sufficiently hard to do so I started working on my own when I didn't see burp updated within a month of my asking. ;) That broke down into writing my own proxy. Each path I took went deeper and deeper into tangential issues. I've only just started writing the actual multi-request fuzzer now. Sans fuzzer engine. :(

So, as happy as I am that you sound as if you've got it written and you'll blog about it in the next few days/weeks, I am also kind of hoping you don't because then I'll regret all the time I spent writing my own proxy (which has 1/16th as many features as Burp does).

Oh the learning experience!

Anyway, look forward to using the updated Burp Suite. Great job. I know plenty of app testers use Burp for their testing.

PortSwigger said...


Doh! Sorry about that. I normally keep fairly quiet about what I'm working on, since not everything gets finished and I don't want to disappoint people. But your effort wasn't wasted - I'm sure you learned a lot and it was hopefully fun. Anyway, you don't yet know if the new Burp features will meet your requirements. You'll find out soon enough!

dre said...

This is a very cool feature -- especially when testing not just 2 sets of credentials, but TONS of credentials.

However, I'd be more likely to build a nice URL list and run dirb (or other curl/etc HTTP automation) through the separate proxies. This way, I don't need to copy URLs from proxy histories into browsers and then I can just check the proxy histories afterwards, looking for 4xx/5xx errors or other differences.

I wonder if this would be useful for testing/debugging concurrency issues, such as when 2 or more credentials try to perform actions on the same objects/resources at the same time. I'm trying to think of other great uses for this!

Lauri said...

This is great feature!

I'm also looking for same functionality as dre. However, you can achieve something similar if you compare site maps.

Get sitemap and specify scope. Configure sessions in options - sessions. Go to sitemap and select compare sitemaps.