A great deal of security tools involve simply finding what you need — they have magnets for needles in a haystack! PortSwigger’s Burp Suite is no different, and in this post I will introduce the new Bambda feature as well as a (hopefully helpful!) Bambda I wrote,
FilterAuthenticated, which was subsequently contributed to the PortSwigger Bambda repository.
A large part of security testing is learning to accumulate, handle and process significant amounts of data, in what is usually a short span of time for an engagement. Modern software and systems are simply so complex and varied that learning to filter out and focus is half the battle in finding weaknesses.
Perhaps the most iconic representation of this to any app tester is Burp Suite’s proxy history and Repeater. All the traffic accumulated while testing is in your proxy history — a recent engagement of mine showed 9186 requests and responses. All the interesting requests you’ve played with are sitting in row after row of Repeater tabs. PortSwigger has a solution for the latter problem with the new Organizer tab where interesting requests and responses can be set aside with comments.
For the problem of sifting through proxy history, there’s always been scope and filters. It’s possible to configure Burp Suite to only accumulate in-scope traffic, but that runs the risk of missing calls to subdomains or APIs sitting on other domains, as well as externally loaded JS files. Another tool is the filter settings.
You can really narrow down what you are looking for with this. The trouble starts with when you want something much more granular. If you are looking for
B, then regular expressions are your best bet. Even then, it can feel like you are using a sabre for needlepoint. For example, what if you are looking for requests made with a cookie value? You could simply search by value, but you’ll then find responses setting the cookie thrown in. A regular expression could get you there, but it’s still a search against the whole request and response.
Enter Bambdas. This is an alternative method of filtering where you can write code to intelligently filter requests and responses. What’s more, you can seamlessly convert an old-fashioned filter into a Bambda (though not the other way around, as Bambdas are much more powerful). For example, the default filter as a Bambda is:
At first glance, this seems a very obtuse way to do something simple, and some programming experience will definitely come in handy in writing these. But where Bambdas really shine is when you want to perform more complex filtering that intelligently understands the structure of a request and response. The good news for anyone wanting to write one is that Burp Suite will assist with built-in error-checking and code completion:
If you want to get started, it’s worth taking a look at the introduction to Bambdas on PortSwigger’s website, as well as Bambdas others have written for the official collection at https://github.com/PortSwigger/bambdas. Speaking of which…
I’ve written and contributed a Bambda to the collection myself! This was originally written for Portswigger’s Bambda launch competition, but with some encouragement from fellow pentesters I decided to send it in as a contribution to the Bambda repository too. After some very helpful feedback from the reviewers, it now exists in a more slimmed-down and streamlined version in the repository.
FilterAuthenticated is a pretty big Bambda at about 44 lines of code. It also comes with four configuration variables at the top, and allows someone to filter out authenticated requests and responses in their history. This is useful when gathering sessions for the Auth Analyzer plugin for example, or to look for missing cache headers (which are more important for sensitive responses). Authenticated responses and requests are also a great place to hunt for weaknesses in a large scope, and this filter makes this possible.
As mentioned, the
FilterAuthenticated Bambda has four config variables at the top. The first two can help filter out images, JS, and CSS files, or out-of-scope requests. The last two are for defining a session cookie name or value. If they are not set, then the filter will look for
Authorization headers. The logic goes like this:
- Find requests that have responses.
- Keep them if the
Authorizationheader is present in the request.
- See if
sessionCookieValueis set, then also keep requests and responses where
sessionCookieValueis not set, then also keep requests and responses where
- Keep them if the
It was pretty fun to write something as complex as this for a filter and find it actually worked. What’s more is that it’s pretty quick: it only takes slightly longer than the traditional filter to run on a ~9,000 request history.
You can find
FilterAuthenticated alongside other useful Bambdas below.