Co to jest maska w ramce WebSocket?

Pracuję nad implementacją websocket i nie wiem, jaki jest sens maski w ramce.

Mógłby mi ktoś wyjaśnić co to robi i dlaczego jest polecane?

  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 ...                |
 +---------------------------------------------------------------+
Author: Ashe, 2013-01-05

2 answers

Websockets są zdefiniowane w RFC6455, który stanowi w Sekcji 5.3:

Nieprzewidywalność klucza maskującego jest niezbędne, aby uniemożliwić autorom złośliwych aplikacji Wybór bajtów, które pojawiają się na przewodzie.

W wpisie na blogu o Websockets znalazłem następujące wyjaśnienie:

Klucz maskujący( 32 bity): jeśli bit maski jest ustawiony (i uwierz mi, jeśli piszesz po stronie serwera), możesz odczytać dla unsigned bajtów, które są używane do xor ładunku z. służy do zapewnienia, że gówniane proxy nie mogą być nadużywane przez napastników ze strony Klienta.

Ale najwidoczniej odpowiedź znalazłem w archiwum listy dyskusyjnej. Tam John Tamplin stwierdza:

Zasadniczo WebSockets jest unikalny, ponieważ musisz chronić sieć infrastruktury, nawet jeśli w kliencie działa wrogi kod, pełna wrogiej kontroli nad serwerem, a jedynym elementem, który can trust is the przeglądarka klienta. poprzez wygenerowanie przez przeglądarkę losowej maski dla każdego ramki, kod klienta nie może wybrać wzorców bajtów, które pojawiają się na przewodzie i użyć go do ataku na wrażliwą infrastrukturę sieciową.

Jak stwierdził kmkaplan, wektor ataku jest opisany w sekcja 10.3 RFC.
Jest to środek zapobiegający atakom zatruwania pamięci podręcznej serwera proxy (Zobacz artykuł o ataku). To, co robi, to tworzenie niektórych przypadkowość. Musisz XOR ładunek za pomocą Losowego klucza maskującego.

Przy okazji: to nie jest tylko zalecane. Jest to obowiązkowe .

 51
Author: Enno Gröper,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-03-17 13:41:10

From this article :

Maskowanie ruchu WebSocket od klienta do serwera jest wymagane ze względu na mało prawdopodobną szansę, że złośliwy kod może spowodować, że niektóre zepsute proxy zrobią coś złego i użyją tego jako pewnego rodzaju ataku. Nikt nie udowodnił, że to może się zdarzyć, ale ponieważ fakt, że może się zdarzyć, był wystarczającym powodem dla dostawców przeglądarek, aby uzyskać twitchy, maskowanie zostało dodane, aby usunąć możliwość korzystania z niego jako do ataku.

Zakładając więc, że atakujący byli w stanie zagrozić zarówno kodowi JavaScript wykonywanemu w przeglądarce, jak i serwerowi zaplecza, maskowanie jest zaprojektowane tak, aby zapobiec tworzeniu sekwencji bajtów wysyłanych między tymi dwoma punktami końcowymi w specjalny sposób, który mógłby zakłócić wszelkie uszkodzone proxy między tymi dwoma punktami końcowymi (przez broken oznacza to 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 ostateczne zdanie na temat losowo generowanej maski używanej do wysłania wiadomości, dlatego nie jest możliwe, aby atakujący wiedzieli, jaki będzie ostateczny strumień bajtów, który proxy może zobaczyć.

Zauważ, że maska jest zbędna, jeśli strumień WebSocket jest zaszyfrowany (tak jak powinien być). Artykuł od autora Flask Pythona:

Dlaczego w ogóle jest maskowanie? Bo widocznie jest tam tyle zepsutej infrastruktury, że pozwala przejść nagłówek upgrade, a następnie obsługuje resztę połączenia jako drugie żądanie HTTP, które następnie wpycha 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. Albo wiesz ... używaj TLS i nie używaj gównianych proxy.

 10
Author: Martin Konecny,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-07-10 20:21:02