Qual è la maschera in un frame WebSocket?

Question

Sto lavorando a un'implementazione websocket e non so quale sia il senso di una maschera in un frame.

Qualcuno potrebbe spiegare a me che cosa fa e perché è raccomandare?

0     1     2     3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-------+-+-------------+-------------------------------+ 
|F|R|R|R| opcode|M| Payload len | Extended payload length | 
|I|S|S|S| (4) |A|  (7)  |    (16/64)   | 
|N|V|V|V|  |S|    | (if payload len==126/127) | 
| |1|2|3|  |K|    |        | 
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + 
|  Extended payload length continued, if payload len == 127 | 
+ - - - - - - - - - - - - - - - +-------------------------------+ 
|        |Masking-key, if MASK set to 1 | 
+-------------------------------+-------------------------------+ 
| Masking-key (continued)  |   Payload Data   | 
+-------------------------------- - - - - - - - - - - - - - - - + 
:      Payload Data continued ...    : 
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 
|      Payload Data continued ...    | 
+---------------------------------------------------------------+ 

Answer 1

WebSockets sono definiti in RFC6455, che afferma in Section 5.3:

L'imprevedibilità della chiave mascheramento è essenziale per prevenire autori di applicazioni dannose selezionando byte che appaiono sul filo.

In un blog entry about Websockets ho trovato la seguente spiegazione:

mascheramento-chiave (32 bit): se è impostato il bit di maschera (e credetemi, è se si scrive per il lato server) qui puoi leggere per i byte non firmati che sono usati per xor il carico utile con. Viene utilizzato per garantire che i proxy shitty non possano essere abusati dagli aggressori dal lato client.

Ma la risposta più chiaramente ho trovato in un mailing list archive. Ci John Tamplin afferma:

In sostanza, WebSockets è unico in quanto è necessario per proteggere l'infrastruttura di rete , anche se si dispone di codice ostile in esecuzione nel client, completo il controllo ostile del server, e l'unico pezzo ci si può fidare del browser client . Avendo il browser genera una maschera casuale per ogni fotogramma , il codice del client ostile non può scegliere i modelli di byte che appaiono sul filo e l'uso che per attaccare l'infrastruttura di rete vulnerabili.

Come kmkaplan affermato, il vettore di attacco è descritto nel Section 10.3 del RFC.
Questa è una misura per impedire attacchi di avvelenamento della cache del proxy (vedere Paper about the attack). Quello che fa è creare un po 'di casualità. Devi eseguire XOR il payload con la chiave di mascheramento casuale.

A proposito: non è solo consigliato. È obbligatorio.

Answer 2

Da this article:

mascheramento dei WebSocket è richiesto il traffico dal client al server a causa della possibilità improbabile che codice dannoso potrebbe causare alcuni proxy rotti per fare la cosa sbagliata e utilizzare questo come un attacco di qualche tipo . Nessuno ha dimostrato che ciò potrebbe effettivamente accadere, ma poiché il fatto che potesse accadere era una ragione sufficiente per i venditori di browser a diventare nervosi, è stato aggiunto il mascheramento per rimuovere la possibilità che venisse utilizzato come attacco.

Quindi, supponendo aggressori erano in grado di compromettere sia il codice JavaScript eseguito in un browser e il server back-end, mascheramento è stato progettato per evitare che la sequenza di byte inviati tra i due punti finali di essere realizzato in modo speciale ciò potrebbe interrompere qualsiasi proxy interrotto tra questi due endpoint (in questo modo si intende proxy che potrebbero tentare di interpretare un flusso Websocket come HTTP quando in realtà non dovrebbero).

Il browser (e non il codice JavaScript nel browser) ha l'ultima parola sulla maschera generata in modo casuale utilizzata per inviare il messaggio, motivo per cui è impossibile per gli aggressori sapere quale flusso finale di byte il proxy potrebbe vedere sarà.

Si noti che la maschera è ridondante se il proprio flusso WebSocket è crittografato (come dovrebbe essere). Article dall'autore di Python's Flask:

Perché c'è un mascheramento? Perché apparentemente ci sono abbastanza infrastrutture rotte là fuori che consentono di passare l'intestazione di aggiornamento e quindi gestiscono il resto della connessione come una seconda richiesta HTTP che poi inserisce nella cache. Non ho parole per questo. In ogni caso, la difesa contro questo è fondamentalmente un forte numero casuale a 32 bit come chiave di mascheramento. O sai ... usa TLS e non usare i proxy shitty.