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.

 GitHub: https://github.com/PortSwigger/bambdas/blob/main/Proxy/HTTP/FilterAuthenticated.bambda

The Problem

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 A AND B, or A OR 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.

The Solution

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…

FilterAuthenticated

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 Authorization header is present in the request.
  • See if sessionCookieName is set.
    • If sessionCookieValue is set, then also keep requests and responses where sessionCookieName with sessionCookieValue is present.
    • If sessionCookieValue is not set, then also keep requests and responses where sessionCookieName is present.

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.

 GitHub: https://github.com/PortSwigger/bambdas/blob/main/Proxy/HTTP/FilterAuthenticated.bambda

The post Para Bailar La Bambda: Contributing to Burp Suite’s New Filtering Capabilities appeared first on LRQA Nettitude Labs.

Silencing the Collective Groan

Security headers. Everyone’s encountered them. Security testers find them on every web application test, and it can be tedious work identifying these weaknesses that usually have low impact and low probability of exploitation. Vendors find them on reports, and they sink down the list of priorities. No-one likes finding security header misconfigurations.

If you expect the next few words to have said, “But now there is Yasha and it will all be unicorns and rainbows!” — no, Yasha is not going to solve all these things! But it can make things easier.

Yasha is a new tool I’ve written that helps with more contextual and accurate testing of headers.

 GitHub: https://github.com/nettitude/yasha

A lot of security header scanners simply take into account a single web page, but that’s rarely enough to get a full picture for all the headers across entire web applications. The other option is for testers to filter and trawl through all their requests or make a best-effort attempt: a time-consuming exercise in tedium!

But there are other ways, and Yasha is one of those.

Enter Yasha

Technically, all the information we need to analyse headers is in Burp (you are using Burp for web application testing, right?). By the end of an engagement, the proxy history should have a very representative sample of requests and responses.

This is how Yasha works: it uses this history and analyses it to find security header misconfigurations. In some cases, it can’t really tell and needs a human being to analyse things. This is the case for deciding what URLs need no-caching directives, and complex content security policy headers; in these cases, Yasha helpfully produces output that can help with the process.

It also helps with reporting. It groups output by base URLs and emits colour-coded output for screenshots. But more importantly, it uses a Markdown file as a source and filters out the irrelevant bits before outputting it as copy-and-paste-ready HTML for pasting into all sorts of editors.

All this should make for an easier time with testing and reporting security header misconfigurations with the added bonus of increasing accuracy.

Caveat Emptor

Yasha was a tool that I used myself to help with testing, and that I offered to fellow testers with the important caveat that it had not hit version 1.0 yet. The thing is, I haven’t encountered every security header, and there are a lot of new scenarios that warrant expanding the code and checks.

That hasn’t changed, and while it is being released now, the hope is that wider usage will help fine-tune and improve its accuracy across a wide range of use cases. So if you would like to use Yasha, I would recommend ensuring you turn on JSON logging with the command-line flag, and double-checking the analysis by using Burp’s history with filters or Bambdas.

At any rate, even with this, I hope the tool proves useful and takes some of the tedium out while giving back with more accuracy across entire web applications.

You can find Yasha at the link below.

 GitHub: https://github.com/nettitude/yasha

The post Introducing Yasha – Yet Another Security Header Analyser appeared first on LRQA Nettitude Labs.