My Struggle with Websockets Testing
Until a few months ago, I have only dealt with HTTP(S) endpoints. Then there was an application I was testing which I couldn’t figure out how it communicated to the server even though I am always logging every request with Burp Suite. This has happened to me in the past where I would just move on from the target. But this application is owned by a target I have a good relationship with, so no running from this one!
Getting Closure
Looking at the WebSockets History in the Proxy tab of Burp Suite, there were lots of history there. And it had always been there whenever I checked in the past.
Then I understood what was going on. After this, the thought that came to mind was to replay the requests. But there was no support for Websockets in Burp Repeater at the time 😩. Thanks to @Portswigger for the new feature.
Learning the Ropes
I learnt that Websockets have been around for a while but somehow didn’t learn about it until then. After knowing how it works, it remained how I could replay with these requests and find bugs in it.
During my study, I read about a lot of approaches that somehow didn’t work for me. But I kept looking anyway. Then I noticed most of the resources I had seen pointed to a particular link, http://websocket.org/echo.html; this webpage had all what was necessary to replay Websocket requests.
I was really excited about this; I have been wanting to do this for a long time! Then after a few weeks, I found out a tool, Advanced Rest Client (Free and open source API testing tool). The tool is similar to POSTMan but has a feature to test websockets. Now, I am able to not only replay requests but also save the requests for further testing.
Aaand finally!
The Portswigger team released a new feature to support replaying Websockets in Burp Repeater. It was great to finally have all I need in one application and to also organize my tests. Now, whenever I find an interesting request in the Websockets History in Burp Proxy tab, I can send it to Burp Repeater to test it out!
Oh! That’s not all!
This writeup would be incomplete without mentioning how it was like testing Websockets before the release of this feature in Burp! And this is also a need to know when you are reviewing Websocket Request after it had disconnected in Burp Repeater or reopening a Burp project file.
From my experience, I discovered that unlike HTTP requests, Websockets requests does not include authentication headers or cookies. But they contain messages (mostly JSON, containing key and value pairs) which is similar to the HTTP request body.
Replaying a request involves the following:
- Connect to the Websocket host
- Authenticate (if required)
- Send the message
Connecting to the Websocket host is easiest, you just click a button to connect to the host. Then you look out for the message used for authentication which sometimes contain the word “authenticate”. And send a message containing a particular command/action.
Thank you for your time. And I hope you enjoyed reading this.
Share on