Edit websocket requests with Burp

30th Dec 2018

As most of the people out there, Burp is my favourite security tool. Sadly, when you're dealing with websockets, it lacks several features. In order to edit and replay requests, you have to chain another proxy (after applying some customizing).

Some background info on Websockets

Websocket requests are different than HTTP ones: they are a constant flow of information, instead of a continue pairing of questions/answers.
To use a metaphor, using HTTP is like talking with a walkie-talkie, you say something and wait for the reply. Websockets, on the other hand, are like a tight conversation with an old friend: you both talk all the time, jumping on subjects and maybe answering something you said two or three phrases ago.

I guess that example just gave an heart attack to a couple of network engineers.

Anyway, that's why you can't have the good old features like the Repeater and the Intruder that we're used to use in Burp. There isn't a specific request that you can repeat endlessly, but each request has its own context validity.

The right tool for the right job

After all, Burp is not useless: using its own certificate, it's possible to inspect incoming and outgoing connections over secure channels.
But the most useful feature is the Upstream proxy. Basically you're telling Burp to hand over the outgoing reply to another proxy, listening on a specific IP/port.

In our case the next proxy is WSProxy.
This tool has been developed by another security researched facing the same issue of editing websocket data.
The installation is pretty straightforward, simply follow the instructions available in the GitHub repository.

Tweaking WSProxy

Out of the box, WSProxy has some naive features; you can replay and fuzz requests. However, what if we have a custom protocol that checks the integrity of the incoming data?
We can't send the same message over and over since each message has his own context and is valid in that specific context. What we have to do is to edit data on the fly accordingly to the structure defined by the application.

That's why I forked the original repository and added a couple of hooks that will be invoked before sending the message to the remote server. There's an hook for text and binary data, your custom function will be invoked where you can perform permutations following the application logic.

See it in action

You can run a quick example using this Echo test page. If you edit the editTextData function adding the edited string to the data, you'll see that the remote server is replying using the modified request.

exports.editTextData = function (data) {
  data += " edited";

  return data;

Please remember that in Burp you'll see the original message, since your code hasn't ran yet. Moreover, the log field on the website displays the original data as well since it's added using JavaScript, fetching the string directly from the input field.


Websockets are getting frequently common and very used these days. We have to do some "magic" to hack them, but thanks to Open Software it's possible to always tweak our tools for our needs.

Let me know if this short guide helped you in getting a bounty!


Blog Comments powered by Disqus.