Co to jest maska ​​w ramce WebSocket?

Question

Pracuję nad implementacją websocket i nie wiem, jakie znaczenie ma maska ​​w ramce.

Czy ktoś może mi wyjaśnić, co robi i dlaczego jest polecany?

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 są zdefiniowane w RFC6455, który stwierdza w Section 5.3:

Nieprzewidywalność klucza maskowania jest niezbędne, aby zapobiec autorom złośliwych aplikacji z wybierając bajty, które pojawiają się na drucie.

W blog entry about Websockets znalazłem następujące wyjaśnienie:

maskujący klucz (32 bitów): Jeśli bit maski jest ustawiony (a uwierzcie mi, to jeśli piszesz po stronie serwera) możesz tu odczytać niepodpisane bajty, które są używane do Xor ładunku z. Służy do zapewnienia, że ​​zasrane serwery proxy nie mogą być nadużywane przez intruzów po stronie klienta:.

Ale najjaśniejsza odpowiedź znalazłem w mailing list archive. Tam John Tamplin stwierdza:

Zasadniczo WebSockets jest wyjątkowy, trzeba chronić infrastrukturę sieci , nawet jeśli mają wrogi kod uruchomiony w kliencie, pełne wrogiego kontrolę nad serwerem, a jedyny kawałek możesz zaufać przeglądarce klienta . Po wygenerowaniu przez przeglądarkę losowej maski dla każdej ramki , wrogi kod klienta nie może wybrać wzorów bajtów, które wyglądają na na drucie i użyć go do ataku na podatną infrastrukturę sieciową.

Jak stwierdził kmkaplan, wektor ataku jest opisany w Section 10.3 dokumentu RFC.
Jest to środek zapobiegający atakom na pamięć podręczną proxy (patrz Paper about the attack). Co robi, tworzy pewną losowość. Musisz XOR ładunku z losowym kluczem maskującym.

Przy okazji: Nie jest to zalecane. Jest to obowiązkowe.

Answer 2

Od this article:

Maskowanie websocket ruch od klienta do serwera jest wymagane ze względu na mało prawdopodobnym przypadku, że złośliwy kod może powodować pewne niedziałających serwerów proxy, aby zrobić coś złego i używać tego jako atak jakiegoś . Nikt nie udowodnił, że tak naprawdę może się zdarzyć, ale ponieważ fakt, że mogło się to wydarzyć, był wystarczającym powodem, dla którego producenci przeglądarek mogli się wstydzić, dodano maskowanie, aby usunąć możliwość użycia go jako ataku.

Więc zakładając, że napastnicy byli w stanie zagrozić zarówno kod JavaScript wykonywany w przeglądarce, a także z serwerem backend, maskowanie jest zaprojektowany, aby zapobiec sekwencję bajtów przesyłanych pomiędzy tymi dwoma punktami końcowymi są wykonane w sposób szczególny może to zakłócić wszelkie zepsute proxy pomiędzy tymi dwoma punktami końcowymi (przez zerwane oznacza to serwery proxy, które mogą próbować zinterpretować strumień websocket jako HTTP, podczas gdy w rzeczywistości nie powinny).

Przeglądarka (a nie kod JavaScript w przeglądarce) ma ostateczny głos na losowo wygenerowanej masce użytej do wysłania wiadomości, dlatego nie jest możliwe, aby atakujący wiedzieli, jaki jest ostateczny strumień bajtów, które może zobaczyć proxy będzie.

Należy pamiętać, że maska ​​jest zbędna, jeśli strumień WebSocket jest zaszyfrowany (tak jak powinien być). Article od autora kolby Pythona:

Dlaczego maskowanie jest w ogóle? Ponieważ najwyraźniej istnieje wystarczająco uszkodzona infrastruktura, która pozwala nagłówkowi aktualizacji przejść, a następnie obsługuje resztę połączenia jako drugie żądanie HTTP, które następnie pakuje do pamięci podręcznej. Nie mam na to słów. W każdym razie, obrona przed tym jest w zasadzie silną 32-bitową liczbą losową jako kluczem maskującym. Lub wiesz ... korzystasz z TLS i nie używasz zasranych proxy.