Hi there!

Today we will see how to add components to the Burp Suite interface that are useful for conveniently managing different scenarios. In detail, we will focus on how to create new tabs for processing HTTP requests and responses.

But as always, let’s start with a use case and explore some ways it can be handled. We are analyzing a mobile application that adds an encryption layer to the HTTP request and response bodies. The mobile application encrypts the body using AES before sending the request and decrypts the response body in the same way, as it is encrypted by the backend application. I mention mobile applications because this scenario is more common in the mobile world, but over the years, we have also seen web applications behaving in a similar manner, encrypting and decrypting in the browser using JavaScript libraries.

A simple Flask Python application that does this job is the following (encryption/decryption stuff taken obviously from StackOverflow – necessary Python packages: flask and pycryptodome):

Hi there!

In the last article of the series we learned how to develop the most commonly used type of Burp extensions during a penetration test, namely HttpHandler plugins (or HttpListener in the old APIs). These plugins allow us to inspect or modify all HTTP requests exiting from every tool in Burp Suite and all incoming responses. Today we will see how to do a similar thing when our target application uses WebSockets.

WebSocket is a stateful full-duplex protocol supported by modern browsers, usually employed in applications that need real-time updates. Until a few years ago, Burp Suite only partially supported WebSockets (I used OWASP Zap for WebSocket testing instead, as it supported them better). Then Burp Suite improved its support over this technology and now WebSockets are well integrated in the Proxy and Repeater tools.

Speaking of extensions, WebSocket support was introduced only with the Montoya API, which is another reason to choose them over the previous APIs, even though they don’t currently support Python and Ruby. Over the years, I’ve come across many applications that used WebSockets and for which I needed an extension (which was often already available publicly for the HTTP counterpart), and the lack of support for this technology was a sore point. Now, as we will see, we can finally inspect and modify WebSocket requests in a similar way to what we did for HTTP requests.

As always, we start from a test scenario that uses WebSocket. For the purpose, I made a few small changes in one of the examples of the Flask-SocketIO project (an integration of SocketIO for Flask). The app.py example of that project runs a simple chat server using SocketIO and it is perfect for our purposes, because it can use WebSocket for communications.

Hi there!

Today we will cover how to develop the type of extension most commonly used during a penetration test, namely HttpHandler plugins (or HttpListener in the old APIs). These plugins allow us to inspect or modify all HTTP requests exiting from every tool in Burp Suite and all incoming responses. It is possible to inspect and modify the traffic of specific tools in Burp Suite through other types of plugins as well, but these HttpHandler plugins provide access to all outgoing and incoming traffic.

With the new Montoya API, we can also inspect and modify WebSocket traffic, one of the features I have been eagerly awaiting for a long time (or better, the feature I have been waiting for the most). Before Montoya API we could write great plugin to handle encryption, signature, encodings, etc. in HTTP requests and responses and we had to keep our fingers crossed that the application didn’t use WebSockets. Otherwise, we could use Burp Suite only in standard scenarios and we had to switch to much more inconvenient tools in more complex ones.

Let’s consider the following example scenario: we have an application that adds a SHA256 hash of the body in an HTTP Header (usually things are a little more complex with for example a HMAC-SHA but let’s keep things simple). If we intercept a request and modify a parameter in the body without regenerating the hash, the request will be rejected by the backend. In the Proxy and Repeater, we can consider manually regenerating the SHA256 for each request we send, but this could significantly slow down the testing process and be quite annoying…

Hi there!

I have been thinking for a long time about releasing a course or lessons on developing extensions for Burp Suite (and to tell you the truth, I had already created a draft course with accompanying extensions some time ago), and what better opportunity than the release of a new API to start the project!

Burp Suite is an exceptional suite of tools that currently stands unparalleled in the world of web application penetration testing. In addition to the HTTP proxy, it provides fuzzing tools, an excellent automated scanner, a request repeater tool, and more. However, personally, the tool I find most remarkable since I started using Burp is undoubtedly the Extender.

The Extender offers a set of APIs that allow for convenient and effective extension of every tool offered by Burp Suite. It provides full control to the penetration tester over all outgoing requests and incoming responses, enabling enhanced customization and flexibility. Thanks to it, over time, third-party plugins have been developed that can support frameworks and protocols, handle complex situations, identify issues, integrate Burp Suite with external tools, and, more generally, make the life of a penetration tester easier by maximizing effectiveness and results.