Ho studiato il protocollo Websocket ( RFC 6455 ). La sezione 10.3 parla specificamente del frame masking, che impedisce l'avvelenamento della cache dai server proxy http.
In che modo il frame masking previene l'avvelenamento della cache? In che modo una cache di proxy è "avvelenata"? Perché il mascheramento si applica solo ai messaggi dal client al server e non viceversa?
Questo attacco può essere applicato anche a lunghi metodi di polling (in particolare XHR)?
Sono molte domande. Ci atteniamo solo al problema principale e alla tecnica di mitigazione:
C'è la possibilità che la mia connessione possa essere delegata o altrimenti esaminata da un proxy di memorizzazione nella cache. E c'è una buona possibilità che io possa ingannare il proxy se riesco a ottenere i dati corretti nella mia richiesta e i dati desiderati nella risposta. L'idea di base è stata dimostrata in un documento chiamato Parlare con te stesso per divertimento e profitto .
Come cliente attaccante, quello che voglio fare è spingere il contenuto fino al server che contiene una stringa di richiesta apparentemente valida:
... something ...
GET /jquery-latest.min.js HTTP/1.1
Host: code.jquery.com
...
... something that triggers the desired response from the server
L'unico requisito è quello di trovare un modo per far sì che il server invii una stringa desiderata, che in genere non è troppo difficile. Quindi il server esegue pappagicamente la risposta desiderata:
HTTP/1.1 200 OK
content-type: text/javascript
... my trojaned javascript file
Per quanto riguarda il server e il client, stiamo solo passando le stringhe avanti e indietro. Nessun vero motivo di preoccupazione, nessun danno fatto, nessun vettore possibile per l'exploit.
Ma un proxy che osserva il traffico vedrebbe che assomiglia molto a una richiesta HTTP, e quindi sembra molto simile a una risposta HTTP. E se il proxy è abbastanza ingenuo (e molti lo sono), aggiornerà la cache di conseguenza, in modo che la prossima volta qualcuno richieda collegamento tramite il proxy, riceveranno la mia versione di Trojan invece del codice reale fornito da CDN.
Per evitare questo, il traffico in una direzione (in questo caso da client a server) è leggermente criptato. Non deve essere crittograficamente sicuro in quanto non ti interessa se qualcuno può decodificarlo. Devi solo assicurarti che il client non possa prevedere quale stringa trasmetterà sulla rete. E dal momento che non può prevedere il suo traffico di rete, non può utilizzare questo meccanismo per attivare un server proxy per aggiornare la sua cache.
Il proxy vedrà solo un evento memorizzabile nella cache se ENTRAMBI la richiesta AND response contengono ciò che assomiglia al traffico HTTP. Quindi solo una direzione deve essere confusa.
Questo non si applica a XHR, poiché le richieste XHR sono richieste HTTP "normali" e sono ben comprese dai proxy.
In che modo il frame masking previene l'avvelenamento della cache?
L'idea è di impedire che il contenuto del frame venga interpretato come una richiesta / risposta HTTP in corso maneggiando i dati del frame.
In realtà credo che sia totalmente inutile.
Supponiamo di aver scritto un semplice client WebSocket (effettivamente vero), in quanto mittente del frame posso scegliere il dword masking. Tutto quello che devo fare è creare un frame di dati casuali con alcune intestazioni HTTP nel mezzo e applicare l'algoritmo di mascheramento xor. Quindi invia quel fotogramma nella mia WebSocket usando la stessa maschera, il mascheramento xor di WebSocket causerà semplicemente che le parti HTTP siano scritte in chiaro sul filo.
I tuoi, TonyWilk
Leggi altre domande sui tag websocket