6

Can anyone explain me which attacks the Sec-WebSocket-Key in the WebSocket handshake addresses?

I don't understand it in the RFC, neither on google.

1
  • I tried to summarise the WebSocket protocol, see second half of this section. – Kiechlus May 26 '16 at 2:09
7

The Wikipedia description (https://en.m.wikipedia.org/wiki/WebSocket) of the protocol seems to sum it up best.

To quote:

In addition to Upgrade headers, the client sends a Sec-WebSocket-Key header containing base64-encoded random bytes, and the server replies with a hash of the key in the Sec-WebSocket-Accept header. This is intended to prevent a caching proxy from re-sending a previous WebSocket conversation,[25] and does not provide any authentication, privacy or integrity. The hashing function appends the fixed string 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 (a GUID) to the value from Sec-WebSocket-Key header (which is not decoded from base64), applies the SHA-1 hashing function, and encodes the result using base64.

Edit: removed statement regarding replay protections thanks to Steffen

8
  • 2
    "In summary it is a method of protection against replay attacks." - I would not call "attack". It is more for detecting if a proxy inadvertently cached data which it should have not cached. – Steffen Ullrich Jan 27 '16 at 5:10
  • That is what the article states, which if viewed from a security standpoint would stand to reason the cached data could be unique session identifiers which could be used to emulate the users requests. In essence working much like a xsrf token – jas- Jan 27 '16 at 11:46
  • see trac.tools.ietf.org/wg/hybi/trac/wiki/… for a more detailed explanation. It's not about replay, it is to make sure than one is talking to a WebSocket server and not a misbehaving proxy. – Steffen Ullrich Jan 27 '16 at 12:38
  • You mean misbehaving as in relaying inaccurate and possibly malicious content? – jas- Jan 27 '16 at 23:53
  • The problem is not relaying malicious content but broken proxies which don't understand the WebSocket protocol and simply assume this too be a normal request. These proxies don't build a tunnel but instead might serve cached content. Main problem are transparent proxies, since non-transparent are accessed with the tunnel building method CONNECT anyway. – Steffen Ullrich Jan 28 '16 at 5:32
3

From the WebSockets FAQ at the IETF:

By having a client send out an encoded random number and having a server give a response that can only be generated by aWebSocket server, the client can verify that they are indeed talking to a WebSocket server and not to some other kind of server. ...

Thus the main idea is that WebSockets cannot be used to talk to real sockets, like mail servers etc. This is important because from the browser often internal trusted servers could be reached and attacked or misused (sending spam) this way.

Apart from that it also makes sure that there is no misbehaving proxy which returns old cached content instead of passing the WebSockets connection directly to the server.

1
  • Apart from that it also makes sure that there is no misbehaving proxy which returns old cached content instead of passing the WebSockets connection directly to the server. Though the misbehaving proxy can always reply with the correct Sec-WebSocket-Accept header, pretending that it's a WebSocket server, doesn't it? – user3019105 Sep 10 '19 at 16:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.