The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

WebSockets - Message Size Limit

R | Last updated: May 21, 2024 01:47PM UTC

Hi - I've dropped support a message about this, however, I just thought I'd try here too just in case anybody else has had a similar issue. I'm utilising the Montoya API in a Burp extension to test an app that uses WSS. The calls I'm using in the API are documented here: https://portswigger.github.io/burp-extensions-montoya-api/javadoc/burp/api/montoya/websocket/MessageHandler.html#handleBinaryMessage(burp.api.montoya.websocket.BinaryMessage) However, the app sends relatively large WebSocket messages (100-200k) from client to server. What I'm seeing, both in Burp Proxy > WebSockets history, and in my Java extension code is that these messages are fragmented so arrive over several messages. The size of any would be 65536 bytes maximum, but it seems arbitrary how they are divided up. According to Chrome browser tools > Network > WSS request > Messages the sizes are the intended size (e.g. 196681B). My code queries binaryMessage.payload().getBytes() within the handleBinaryMessage(BinaryMessage binaryMessage) override. But in Burp this is shown as several messages (To server) - e.g. of 58289B, 7247B, 58289B, 7247B, 58289B, 7247B, 73B. The total number of bytes adds up, but as the full message of 196681B represents a certain structure I am parsing in my code, I get errors within my Java implementation as only 58289B were available of the message. The fragmentation only seems to happen with Chromium and not Firefox. Is there a way in the API to detect when a message is fragmented, so that I can join it back together? Or is proxying WebSockets at the whim of the browser and how it decides to fragment data?

Hannah, PortSwigger Agent | Last updated: May 22, 2024 12:14PM UTC