Qualcuno può spiegarmi quale attacco attacca Sec-WebSocket-Key negli indirizzi di handshake WebSocket?
Non lo capisco nella RFC, né su google.
La descrizione di Wikipedia ( collegamento ) del protocollo sembra riassumerlo meglio.
Per citare:
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.
Modifica: rimossa la dichiarazione relativa alle protezioni di replay grazie a Steffen
Dalle Domande frequenti WebSockets a 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. ...
Quindi l'idea principale è che i WebSocket non possano essere utilizzati per parlare con socket reali, come server di posta, ecc. Questo è importante perché dal browser spesso i server fidati interni possono essere raggiunti e attaccati o utilizzati in modo improprio (inviando spam) in questo modo.
Oltre a ciò, si assicura anche che non vi sia alcun proxy che funzioni male, che restituisce il vecchio contenuto della cache invece di passare la connessione WebSockets direttamente al server.
Leggi altre domande sui tag websocket