PortSwigger's "Manipulating WebSocket messages to exploit vulnerabilities" Walkthrough

This post is a walkthrough of PortSwigger’s “modifying serialized objects” lab. You will need to have Burp Suite set up, as well as a Portswigger Academy account.

Log in to your Academy account and then view the lab at https://portswigger.net/web-security/websockets/lab-manipulating-messages-to-exploit-vulnerabilities. This is accessible from the “all labs” view or from the WebSockets page.

Challenge Information

Click the “Access the Lab” button and you will be taken to a temporary website that is created for your account. This will be in format https://<random string here>.web-security-academy.net/.

To solve this lab, we need to tamper with a WebSockets message to pop an alert in the chat agent’s window.

This is from PortSwigger’s WebSockets blog post and likely covers what we’ll need to do:

Here’s the website, a shopping site that has a Live Chat option:

If we go to /chat and send a message, the chat agent bot responds back:

Inspecting WebSockets traffic

If you do not have Burp Suite up and running with a proxy configured, use this post to do so now. Then send some new chat messages.

Proxy > HTTP history will show you the HTTP requests for various webpages, but we have to go elsewhere to view the chat traffic.

In Proxy > WebSockets history, you should be able to see all chat messages sent and received, plus a couple of status messages.

If you click into the first one, you’ll see that it’s a status of READY. The bottom half of the screen shows the message contents:

Then, a “CONNECTED” message:

The next one is the “hi Hal” message shown earlier. This message is being sent to the server (from the client).

Then, a similar version of this message (now attributed to “You”) is sent back from the server, to the client:

Then the bot responds back, and we only see this message as it is delivered from the server, to the client. This makes sense because we are not intercepting traffic sent by the chat bot’s client to the server:

And the conversation continues, if we answer back to Hal.

Lab Solution

If we try to send a message from the browser with an XSS payload, we have a problem: the brackets are getting encoded.

To circumvent this, we can select a chat message from our WebSockets history, then modify it in Burp Suite. But first, which message should we choose?

Since we want the message to be shown to the chat bot, we have to intercept a request being sent to the server, not to the client. If you intercept a “to client” message, you will only XSS yourself, not the chat bot.

Pick a message in your WebSockets history within Burp Suite, then right-click and select Send to Repeater:

In the Repeater view, you should see the original message:

Modify the message to include your XSS payload. Here we’re using <img src=x onerror=alert(1)>.

Then send the message. You should see more messages update on the right-hand side, as the to-client message is sent and additional new Hal messages.

Go back to your browser and you should see an alert, as both you and Hal have been XSSed.

And with that, the lab is solved!

As mentioned before, if you see the alert but the lab does not get marked as solved, you have only XSSed yourself. Make sure you are intercepting and modifying a message to the server (so it persists on both pages) instead of just modifying the “to client” messages that dictate what is shown on your page.