8

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.

Improve this question
1
  • I tried to summarise the WebSocket protocol, see second half of this section.
    – Kiechlus
    Commented May 26, 2016 at 2:09

2 Answers 2

Reset to default
8

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

Improve this answer
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
    Commented Jan 27, 2016 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-
    Commented Jan 27, 2016 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
    Commented Jan 27, 2016 at 12:38
  • You mean misbehaving as in relaying inaccurate and possibly malicious content?
    – jas-
    Commented Jan 27, 2016 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
    Commented Jan 28, 2016 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.

Improve this answer
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
    Commented Sep 10, 2019 at 16:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .