javascript - Why do WebSockets use a hash in handshake? -


to open websocket, client connects tcp socket on server, , starts handshake.

the client's handshake contains base64 encoded key (sec-webscoket-key).

the server supposed respond sha-1(key + magic_constant), base64 encoded. magic_constant protocol-specific string (sec-websocket-accept).

what's purpose of this? i'm not seeing obvious security reasons doing so. doesn't authenticate either party. single sha-1 computation isn't proof of work.

the purpose of part of handshake make sure both sides of connection genuine websocket participants. designed easy implement real websocket clients , servers difficult attacker trick http client, server or proxy pretending websocket participant. in particular, bad if piece of malicious javascript running in browser open websocket connection normal http server because once connection established javascript have full control of sent on channel , try kinds of malformed on oversized data attempt breach or take down server.

update:

as @notallama points out, it's easy create malicious websocket client or use telnet send malicious data. difference websockets, attack comes trusted context (the user's browser , user's network). browsers load untrusted code internet used connect http server , intermediaries not exposed internet @ large. extreme example, imagine if instead of websockets, browsers open raw tcp connections (no enforced cors, hash check, etc). malicious piece of javascript can wants on users home network (or worse, work place intranet).

in particular, hybi working group spent inordinate amount of time addressing theoretical vulnerability in http intermediaries allow cache pollution using websocket connection fool intermediary think talking normal http client.


Comments

Popular posts from this blog

jquery - How can I dynamically add a browser tab? -

node.js - Getting the socket id,user id pair of a logged in user(s) -

keyboard - C++ GetAsyncKeyState alternative -