CODEWITHSUNDEEP
javascriptwebwebsocket
notallama
notallama

Reputation: 1079

Why do WebSockets use a hash in handshake?

To open a Websocket, the client connects to a tcp socket on a server, and then starts a handshake.

The client's handshake contains a base64 encoded key (Sec-WebScoket-Key).

The server is supposed to respond with SHA-1(key + magic_constant), base64 encoded. magic_constant is a protocol-specific string (Sec-Websocket-Accept).

What's the purpose of this? i'm not seeing any obvious security reasons for doing so. it doesn't authenticate either party. a single SHA-1 computation isn't much for a proof of work.

Upvotes: 5

Views: 1511

Answers (1)

kanaka
kanaka

Reputation: 73119

The purpose of this part of the handshake is to make sure that both sides of the connection are genuine WebSocket participants. It is designed to be easy to implement for real WebSocket clients and servers but difficult for an attacker to trick an HTTP client, server or proxy into pretending to be a WebSocket participant. In particular, it would be bad if a piece of malicious JavaScript running in a browser could open a WebSocket connection to a normal HTTP server because once the connection is established then the JavaScript would have full control of what is sent over the channel and could try all kinds of malformed over oversized data to attempt to breach or take down the server.

Update:

As @notallama points out, it's easy to create a malicious WebSocket client or just use telnet to send malicious data. The difference is that with WebSockets, the attack comes from a trusted context (the user's browser and the user's network). Browsers load untrusted code from the Internet but are often used to connect to HTTP server and intermediaries that are not exposed to the Internet at large. As an extreme example, imagine if instead of WebSockets, browsers could open raw TCP connections (no enforced CORS, hash check, etc). Now a malicious piece of JavaScript can do anything it wants on the users home network (or worse, their work place intranet).

In particular, the HyBi working group spent an inordinate amount of time addressing a theoretical vulnerability in HTTP intermediaries that would allow cache pollution by using a WebSocket connection to fool the intermediary to think they are talking to a normal HTTP client.

Upvotes: 3

Related Questions