Why masking websocket

According to the RFC , the formula is as follows:. There will be some differences because of the way Lua handles array positions.

CVE is a good example of needing to inspect masked WebSocket traffic. In this example, the exploit is using java. Runtime to execute a Netcat command. The images below show both the masked and unmasked traffic. Figure 5: CVE exploit unmasked. This could reduce the number of times the signature would call the Lua script and be more certain of the type of traffic being passed to the script.

The init function of the lua script grabs whichever buffer is needed. If there is then we can extract a 4 byte key using substring from the payload. Remember that all arrays in Lua begin with 1 not 0. In this function we start decoding right after the 4 byte key, so we set i in the for loop to 7. WebSockets - Why do we need to mask data from client to server? As I mentioned here , the WebSockets protocol is, at this point, a bit of a mess due to the evolution of the protocol and the fact that it's being pulled in various directions by various interested parties.

I'm just ranting about some of the things that I find annoying The client MUST mask all frames sent to the server. In this case, a server MAY send a close frame with a status code of protocol error as defined in Section 7. The masking in itself is relatively painless to achieve but it interacts poorly with the albeit badly designed deflate-stream extension and forcing the client to mask zero length frames seems unnecessary - though I agree that special cases don't really seem warranted.

The RFC doesn't explain why masking from client to server is considered essential but a search through the discussion list brings up plenty of hits. The best descriptions of why can be found here and here. Masking of WebSocket traffic from client to server is required because of the unlikely chance that malicious code could cause some broken proxies to do the wrong thing and use this as an attack of some kind. Nobody has proved that this could actually happen, but since the fact that it could happen was reason enough for browser vendors to get twitchy, masking was added to remove the possibility of it being used as an attack.

The idea being that since the API level code generating the WebSocket frame gets to select a masking key and mask the data supplied by the application code the application code cannot in any meaningful way dictate the data that ends up passing through the potentially broken intermediaries and therefore can't cause trouble.

Since the masking key is in the frame intermediaries can be written to understand and unmask the data to perform some form of clever inspection if they want to. Categories : Rants , Socket Servers. Sorry, something went wrong. Because there is no payload, there doesn't seem to be any point to send a mask, because there is nothing to mask. It adds 4 bytes of overhead and I can't see why this is necessary. You could probably argue both ways, but I'm not sure the RFC clarifies this.

In any case, technically speaking I can't see any reason to send a mask on such a frame. Skip to content. Star New issue. Jump to bottom. Labels question. Linked pull requests. Copy link.