Что такое маска в кадре WebSocket?

Я работаю над реализацией websocket и не знаю, что такое чувство маски в кадре.

Может кто-нибудь объяснить мне, что он делает и почему он рекомендует?

  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 ...                |
 +---------------------------------------------------------------+

Ответ 1

Веб-узлы определены в RFC6455, который гласит Раздел 5.3:

Непредсказуемость ключа маскировки необходимо предотвратить выбор авторов вредоносных приложений байты, которые появляются на проводе.

В записи о веб-узлах я нашел следующее объяснение:

masking-key (32 бит): если бит маски установлен (и, верьте мне, это если вы пишете для серверной части), вы можете читать здесь беззнаковые байты, которые используются для xor полезной нагрузки. Он использовался для обеспечения того, чтобы злоумышленники не могли злоупотреблять злоумышленниками со стороны клиента.

Но наиболее явный ответ я нашел в архиве рассылки . Там Джон Тамплин утверждает:

В принципе, WebSockets уникален тем, что вам необходимо защитить сеть инфраструктуры, даже если у вас есть враждебный код, запущенный на клиенте, полный враждебное управление сервером, и единственной частью, которой вы можете доверять, является клиентский браузер. Благодаря тому, что браузер генерирует случайную маску для каждого фрейм, код враждебного клиента не может выбрать шаблоны байтов, которые появляются на проводе и использовать это для атаки уязвимой сетевой инфраструктуры.

Как указано в заявлении kmkaplan, вектор атаки описан в Раздел 10.3 RFC.
Это мера, предотвращающая атаки отравления кэша прокси-сервера (см. Бумага об атаке). Что он делает, создает некоторую случайность. Вы должны XOR полезную нагрузку с помощью случайного маскирующего ключа.

Кстати: это не просто рекомендуется. Он обязателен.

Ответ 2

Из в этой статье:

Маскирование трафика WebSocket от клиента к серверу требуется из-за маловероятной вероятности того, что вредоносный код может привести к тому, что некоторые сломанные прокси делают неправильную вещь и используют это как какую-либо атаку. Никто не доказал, что это может произойти на самом деле, но поскольку тот факт, что это могло произойти, было достаточным основанием для того, чтобы разработчики браузеров становились дергающимися, маскировка была добавлена, чтобы исключить возможность его использования в качестве атаки.

Таким образом, предполагая, что злоумышленники смогли скомпрометировать как код JavaScript, выполняемый в браузере, так и серверный сервер, маскирование предназначено для предотвращения последовательности байтов, посланных между этими двумя конечными точками, создаваемых особым образом, которые могут нарушить любые сломанные прокси-серверы между этими двумя конечными точками (сломанными это означает прокси, которые могут пытаться интерпретировать поток websocket как HTTP, когда на самом деле они не должны).

Браузер (а не код JavaScript в браузере) имеет последнее слово на случайно сгенерированной маске, используемой для отправки сообщения, поэтому злоумышленники не могут понять, какой конечный поток байтов может видеть прокси-сервер быть.

Обратите внимание, что маска избыточна, если ваш поток WebSocket зашифрован (как и должно быть). Статья от автора Python Flask:

Почему маскировка вообще? Потому что, видимо, там есть достаточно разбитая инфраструктура, которая позволяет пропустить заголовок обновления, а затем обрабатывает остальную часть соединения как второй HTTP-запрос, который он затем загружает в кеш. У меня нет слов для этого. В любом случае защита от этого в основном является сильным 32-битным случайным числом в качестве маскирующего ключа. Или вы знаете... используйте TLS и не используйте shitty proxies.