WebSocket: от новичка до мастера за 5 минут

Node.js
WebSocket: от новичка до мастера за 5 минут

Команда Ali CBU набирает сотрудников, заинтересованные друзья добавляют меня в WeChat casperchen, добавляют свой блог или адрес github в предыдущем приложении, резюме можно отправлять напрямую416394284@qq.com👈

1. Обзор содержания

Появление WebSocket позволяет браузерам иметь возможности двусторонней связи в реальном времени. В этой статье представлены подробности того, как WebSocket устанавливает соединения, обменивается данными и форматом фреймов данных. Кроме того, дается краткое введение в атаки безопасности на WebSockets и то, как протокол защищает от подобных атак.

2. Что такое веб-сокет

HTML5 предоставляет сетевую технологию для полнодуплексной связи между браузером и сервером, которая относится к протоколу прикладного уровня. Он основан на транспортном протоколе TCP и мультиплексирует канал квитирования HTTP.

Для большинства веб-разработчиков приведенное выше описание немного скучно, но запомните несколько моментов:

  1. WebSocket можно использовать в браузере
  2. Поддержка двусторонней связи
  3. легко использовать

1. В чем преимущества

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

  1. Поддержка двусторонней связи, более в режиме реального времени.
  2. Лучшая поддержка двоичного кода.
  3. Меньше затрат на контроль. После создания соединения, когда клиент ws и сервер обмениваются данными, заголовок пакета данных, контролируемого протоколом, имеет небольшой размер. В случае отсутствия заголовка заголовок от сервера к клиенту составляет всего 2~10 байт (в зависимости от длины пакета данных), и необходимо добавить дополнительную 4-байтовую маску от клиента к сервер. Протокол HTTP должен содержать полный заголовок для каждой связи.
  4. Расширения поддерживаются. Протокол ws определяет расширения, и пользователи могут расширять протокол или реализовывать собственные подпротоколы. (например, поддержка пользовательских алгоритмов сжатия и т. д.)

Что касается последних двух пунктов, студенты, которые не изучали спецификацию протокола WebSocket, могут не понимать ее интуитивно, но это не влияет на изучение и использование WebSocket.

2. Чему научиться

Для изучения протоколов уровня сетевых приложений наиболее важным часто являетсяпроцесс установления соединения,Учебник по обмену данными. Конечно, формат данных неизбежен, потому что он напрямую определяет возможности самого протокола. Хороший формат данных делает протокол более эффективным и масштабируемым.

Нижеследующее в основном сосредоточено на следующих моментах:

  1. Как установить соединение
  2. Как обмениваться данными
  3. формат кадра данных
  4. Как сохранить связь

Три, вводный пример

Прежде чем официально представить детали протокола, давайте рассмотрим простой пример, чтобы получить интуитивное представление. Примеры включают сервер WebSocket, клиент WebSocket (веб-страницу). Полный код можно найти наздесьоказаться.

Здесь сервер используетwsэта библиотека. чем знакомыйsocket.io,wsОн легче и больше подходит для учебных целей.

1. Сервер

Код выглядит следующим образом, прослушивая порт 8080. При поступлении нового запроса на подключение протокол распечатывается и клиенту отправляется сообщение. Также распечатайте журнал, когда сообщение получено от клиента.

var app = require('express')();
var server = require('http').Server(app);
var WebSocket = require('ws');

var wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', function connection(ws) {
    console.log('server: receive connection.');
    
    ws.on('message', function incoming(message) {
        console.log('server: received: %s', message);
    });

    ws.send('world');
});

app.get('/', function (req, res) {
  res.sendfile(__dirname + '/index.html');
});

app.listen(3000);

2. Клиент

Ниже приведен код для инициации подключения WebSocket к порту 8080. После установления соединения журнал распечатывается и одновременно отправляется сообщение на сервер. После получения сообщения от сервера журнал также распечатывается.

<script>
  var ws = new WebSocket('ws://localhost:8080');
  ws.onopen = function () {
    console.log('ws onopen');
    ws.send('from client: hello');
  };
  ws.onmessage = function (e) {
    console.log('ws onmessage');
    console.log('from server: ' + e.data);
  };
</script>

3. Запуск результатов

Вы можете просмотреть журналы сервера и клиента соответственно, которые здесь не раскрываются.

Вывод сервера:

server: receive connection.
server: received hello

Вывод клиента:

client: ws connection is open
client: received world

4. Как установить соединение

Как упоминалось ранее, WebSocket повторно использует канал рукопожатия HTTP. В частности, клиент согласовывает протокол обновления с сервером WebSocket через HTTP-запрос. После завершения обновления протокола последующий обмен данными осуществляется по протоколу WebSocket.

1. Клиент: подать заявку на обновление протокола

Сначала клиент инициирует запрос на обновление протокола. Видно, что используется стандартный формат HTTP-сообщений, который поддерживает толькоGETметод.

GET / HTTP/1.1
Host: localhost:8080
Origin: http://127.0.0.1:3000
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: w4v7O6xFTi36lq3RNcgctw==

Значение заголовка запроса ключа следующее:

  • Connection: Upgrade: указывает, что протокол должен быть обновлен.
  • Upgrade: websocket: указывает, что вы хотите перейти на протокол веб-сокета.
  • Sec-WebSocket-Version: 13: указывает версию веб-сокета. Если сервер не поддерживает версию, необходимо вернутьSec-WebSocket-Versionзаголовок, который содержит номер версии, поддерживаемой сервером.
  • Sec-WebSocket-Key: со следующим заголовком ответа сервераSec-WebSocket-AcceptОн упакован и обеспечивает базовую защиту от вредоносных подключений или непреднамеренных подключений.

Обратите внимание, что в приведенном выше запросе отсутствуют некоторые несущественные заголовки запроса. Поскольку это стандартный HTTP-запрос, заголовки запроса, такие как Host, Origin и Cookie, будут отправляться как обычно. На этапе рукопожатия ограничения безопасности, проверка разрешений и т. д. могут выполняться через соответствующие заголовки запроса.

2. Сервер: реагировать на обновление протокола

Содержимое, возвращаемое сервером, выглядит следующим образом: код состояния101Указывает на переключение протокола. На этом обновление протокола завершено, и последующие взаимодействия данных основаны на новом протоколе.

HTTP/1.1 101 Switching Protocols
Connection:Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: Oy4NRAQ13jhfONC7bP8dTKb4PTU=

Примечание: каждый заголовок начинается с\r\nзаканчиваться дополнительной пустой строкой в ​​конце\r\n. Кроме того, код состояния HTTP, возвращаемый сервером, может использоваться только на этапе установления связи. После этапа квитирования можно использовать только определенные коды ошибок.

3. Расчет Sec-WebSocket-Accept

Sec-WebSocket-AcceptСогласно заголовку запроса клиентаSec-WebSocket-KeyРассчитано.

Формула расчета:

  1. будетSec-WebSocket-Keyи258EAFA5-E914-47DA-95CA-C5AB0DC85B11сшивание.
  2. Дайджест вычисляется SHA1 и преобразуется в строку base64.

Псевдокод выглядит следующим образом:

>toBase64( sha1( Sec-WebSocket-Key + 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 )  )

Проверьте предыдущий результат возврата:

const crypto = require('crypto');
const magic = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11';
const secWebSocketKey = 'w4v7O6xFTi36lq3RNcgctw==';

let secWebSocketAccept = crypto.createHash('sha1')
	.update(secWebSocketKey + magic)
	.digest('base64');

console.log(secWebSocketAccept);
// Oy4NRAQ13jhfONC7bP8dTKb4PTU=

5. Формат фрейма данных

Обмен данными клиента, сервера, определение формата фрейма данных. Поэтому мы сначала рассмотрим формат фрейма данных WebSocket, прежде чем объяснять обмен данными.

Наименьшая единица связи между клиентом WebSocket и сервером — это фрейм, который состоит из одного или нескольких фреймов для формирования полного сообщения.

  1. Отправитель: разрежьте сообщение на несколько фреймов и отправьте его на сервер;
  2. Получатель: получает кадры сообщения и повторно собирает связанные кадры в полное сообщение;

Целью этого раздела является объяснениеФрейм данныхформат. Подробные определения см.RFC6455, раздел 5.2.

1. Обзор формата фрейма данных

Унифицированный формат фрейма данных WebSocket приведен ниже. Учащиеся, знакомые с протоколом TCP/IP, должны быть знакомы с такими диаграммами.

  1. Слева направо единицы измерения — биты. НапримерFIN,RSV1каждый занимает 1 бит,opcodeзанимает 4 бита.
  2. Содержимое включает в себя идентификацию, код операции, маску, данные, длину данных и т. д. (расширится в следующем подразделе)
  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 ...                |
 +---------------------------------------------------------------+

2. Подробное объяснение формата фрейма данных

Для предыдущей схемы обзора формата, здесь есть объяснение каждого поля.Если есть что-то неясное, вы можете обратиться к спецификации протокола или оставить сообщение для связи.

FIN: 1 бит.

Если он равен 1, то это означает, что это последний фрагмент (фрагмент) сообщения (сообщения), если он равен 0, то это означает, что это не последний фрагмент (фрагмент) сообщения (сообщения).

RSV1, RSV2, RSV3: 1 бит каждый.

В общем все 0. Когда клиент и сервер договариваются об использовании расширения WebSocket, эти три флага могут быть ненулевыми, а значение значений определяется расширением. Если значение не равно нулю, а расширение WebSocket не используется, подключение завершается ошибкой.

Opcode: 4 бита.

Код операции, значение Opcode определяет, как следует анализировать последующую полезную нагрузку данных. Если код операции неизвестен, получатель ДОЛЖЕН разорвать соединение. Дополнительные коды действий:

  • %x0: указывает кадр продолжения. Когда Opcode равен 0, это указывает на то, что в этой передаче данных используется фрагментация данных, и текущий полученный кадр данных является одним из фрагментов данных.
  • %x1: указывает, что это текстовый фрейм (фрейм)
  • %x2: указывает, что это двоичный кадр (кадр)
  • %x3-7: зарезервированные коды операций для определенных впоследствии неуправляющих кадров.
  • %x8: указывает, что соединение разорвано.
  • %x9: указывает, что это операция проверки связи.
  • %xA: указывает, что это операция pong.
  • %xB-F: зарезервированные коды операций для определяемых впоследствии управляющих кадров.

Mask: 1 бит.

Указывает, следует ли маскировать полезные данные. При отправке данных с клиента на сервер данные нужно маскировать, при отправке данных с сервера на клиент маскировать данные не нужно.

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

Если Mask равно 1, то ключ маскирования определяется в ключе маскирования, и этот ключ маскирования используется для демаскирования полезной нагрузки данных. Для всех фреймов данных, отправляемых клиентом на сервер, Маска равна 1.

Алгоритм и назначение маски объясняются в следующем разделе.

Payload length: длина полезных данных в байтах. 7 бит, или 7+16 бит, или 1+64 бит.

Предположим, что число Payload length === x, если

  • x равно 0~126: длина данных составляет x байт.
  • x равно 126: следующие 2 байта представляют собой 16-разрядное целое число без знака, значением которого является длина данных.
  • x равно 127: следующие 8 байтов представляют собой 64-битное целое число без знака (старший бит равен 0), а значение целого числа без знака представляет собой длину данных.

Кроме того, если длина полезной нагрузки занимает более одного байта, двоичное представление длины полезной нагрузки осуществляется в сетевом порядке (сначала значащие биты).

Masking-key: 0 или 4 байта (32 бита)

Все кадры данных, передаваемые от клиента к серверу, полезные данные маскируются, маска равна 1 и содержит 4-байтовый ключ маскирования. Если Маска равна 0, Маскирующий ключ отсутствует.

Примечание. Длина данных полезной нагрузки, исключая длину ключа маски.

Payload data: (х+у) байт

Данные полезной нагрузки: включая данные расширения и данные приложения. Среди них данные расширения — это x байт, а данные приложения — y байт.

Расширенные данные: если расширение не согласовано, данные расширенных данных составляют 0 байтов. Все расширения должны объявлять длину данных расширения или способ расчета длины данных расширения. Кроме того, то, как используется расширение, должно быть согласовано на этапе рукопожатия. Если присутствуют данные расширения, длина данных полезной нагрузки ДОЛЖНА включать длину данных расширения.

Данные приложения: Произвольные данные приложения после расширенных данных (если есть расширенные данные) занимают оставшуюся позицию фрейма данных. Длина данных приложения получается путем вычитания длины расширенных данных из длины данных полезной нагрузки.

3. Алгоритм маски

Маскирующий ключ представляет собой 32-битное случайное число, выбранное клиентом. Операция маскирования не влияет на длину полезных данных. Операции маскирования и демаскирования используют следующие алгоритмы:

Во-первых, предположим:

  • original-octet-i: i-й байт исходных данных.
  • преобразованный октет-i: i-й байт преобразованных данных.
  • дж: дляi mod 4результат.
  • masking-key-octet-j: это j-й байт ключа маски.

Алгоритм описывается следующим образом: XOR исходного октета-i с маскирующим-ключом-октетом-j для получения преобразованного-октета-i.

j = i MOD 4 transformed-octet-i = original-octet-i XOR masking-key-octet-j

6. Передача данных

Как только клиент WebSocket и сервер устанавливают соединение, последующие операции основаны на передаче кадров данных.

WebSocket согласноopcodeразличать вид операции. Например0x8означает отключение,0x0-0x2Представляет взаимодействие данных.

1. Фрагментация данных

Каждое сообщение WebSocket может быть разделено на несколько фреймов данных. Когда получатель WebSocket получает кадр данных, онFINзначение, чтобы определить, был ли получен последний кадр данных сообщения.

FIN=1 указывает, что текущий кадр данных является последним кадром данных сообщения.В это время получатель получил полное сообщение и может его обработать. FIN=0, приемник также должен продолжать отслеживать и принимать оставшиеся кадры данных.

также,opcodeВ случае обмена данными он представляет тип данных.0x01представляет текст,0x02Представляет собой двоичный файл. и0x00Он специальный, указывающий на то, что кадр продолжения (continuation frame), как следует из названия, означает, что кадр данных, соответствующий завершенному сообщению, не получен.

2. Пример фрагментации данных

Посмотрите прямо на пример, чтобы быть более ярким. Следующий пример взят изMDN, что является хорошей демонстрацией разделения данных. Клиент отправляет сообщение серверу дважды, и сервер отвечает клиенту после получения сообщения, Здесь в основном это зависит от сообщения, отправленного клиентом на сервер.

первое сообщение

FIN=1, что означает, что это последний фрейм данных текущего сообщения. После того, как сервер получит текущий фрейм данных, он может обработать сообщение. opcode=0x1, указывающий, что клиент отправляет текстовый тип.

второе сообщение

  1. FIN=0, код операции=0x1, что указывает на то, что текстовый тип отправлен, а сообщение не было отправлено, и есть последующие кадры данных.
  2. FIN=0, код операции=0x0, что указывает на то, что сообщение не было отправлено, и есть последующие кадры данных.Текущий кадр данных должен быть связан с предыдущим кадром данных.
  3. FIN=1, код операции=0x0, что указывает на то, что сообщение было отправлено, последующего фрейма данных нет, и текущий фрейм данных необходимо соединить с предыдущим фреймом данных. Сервер может собрать связанный фрейм данных в полное сообщение.
Client: FIN=1, opcode=0x1, msg="hello"
Server: (process complete message immediately) Hi.
Client: FIN=0, opcode=0x1, msg="and a"
Server: (listening, new message containing text started)
Client: FIN=0, opcode=0x0, msg="happy new"
Server: (listening, payload concatenated to previous message)
Client: FIN=1, opcode=0x0, msg="year!"
Server: (process complete message) Happy new year to you too!

Семь, поддержание соединения + сердцебиение

Чтобы поддерживать двустороннюю связь между клиентом и сервером в режиме реального времени, WebSocket должен гарантировать, что TCP-канал между клиентом и сервером остается подключенным, а не отключенным. Однако для соединения, в котором нет обмена данными в течение длительного времени, если оно все еще поддерживается в течение длительного времени, ресурсы включенного соединения могут быть потрачены впустую.

Однако некоторые сценарии нельзя исключать: хотя клиент и сервер давно не обмениваются данными, им все равно нужно поддерживать связь. В это время для достижения можно использовать сердцебиение.

  • отправитель -> получатель: пинг
  • Получатель -> отправитель: pong

Операции ping и pong соответствуют двум управляющим фреймам WebSocket.opcodeсоответственно0x9,0xA.

Например, чтобы отправить пинг с сервера WebSocket клиенту, требуется только следующий код (используяwsмодуль)

ws.ping('', false, true);

Восемь, роль Sec-WebSocket-Key/Accept

Как упоминалось ранее,Sec-WebSocket-Key/Sec-WebSocket-AcceptОсновная роль заключается в обеспечении базовой защиты и сокращении вредоносных подключений и случайных подключений.

Функции можно приблизительно резюмировать следующим образом:

  1. Предотвратите получение сервером недопустимого подключения через веб-сокет (например, http-клиент случайно запрашивает подключение к службе веб-сокета, и сервер может напрямую отклонить соединение)
  2. Убедитесь, что сервер понимает соединение через веб-сокет. Поскольку протокол http используется на этапе рукопожатия ws, соединение ws может быть обработано и возвращено сервером http.В это время клиент может использовать Sec-WebSocket-Key, чтобы убедиться, что сервер распознает протокол ws. (Не 100% страховка, например, всегда есть какие-то скучные http-серверы, которые обрабатывают только Sec-WebSocket-Key, но не реализуют протокол ws...)
  3. Sec-WebSocket-Key и другие связанные заголовки запрещены, когда в браузере инициируется запрос ajax и установлен заголовок. Это может избежать случайного обновления протокола запроса (обновление веб-сокета), когда клиент отправляет запрос ajax.
  4. Может предотвратить обратный прокси-сервер (не понимающий протокол ws) от возврата неправильных данных. Например, обратный прокси получает два запроса на обновление ws-соединения до и после, обратный прокси возвращает первый запрос в кеш, а затем напрямую возвращает кешированный запрос, когда приходит второй запрос (бессмысленный возврат).
  5. Основной целью Sec-WebSocket-Key не является обеспечение безопасности данных, так как формулы расчета конверсии Sec-WebSocket-Key и Sec-WebSocket-Accept являются общедоступными и очень простыми, а основная функция заключается в предотвращении некоторых распространенных непредвиденных ситуаций. (не специально).

Акцент: преобразование Sec-WebSocket-Key/Sec-WebSocket-Accept может дать только базовые гарантии, но безопасно ли соединение, безопасны ли данные, является ли клиент/сервер легальным клиентом ws, сервером ws, на самом деле Фактической гарантии нет.

Девять, роль маски данных

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

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

Ответ по-прежнему два слова:Безопасность. Но не для предотвращения утечки данных, а для предотвращения таких проблем, как атаки с отравлением кеша прокси, которые существовали в более ранних версиях протокола.

1. Атака с загрязнением кеша прокси

Ниже приводится отрывок из речи о безопасности в 2010 году. В нем упоминаются возможные проблемы с безопасностью, вызванные недостатками в реализации протокола прокси-сервера.источник удара.

"Экспериментально мы показываем, что текущая версия механизма согласия WebSocket уязвима для атак с отравлением кеша прокси. Несмотря на то, что рукопожатие WebSocket основано на HTTP, который должен быть понятен большинству сетевых посредников, рукопожатие использует эзотерическое "обновление". Механизм HTTP [5]. В нашем эксперименте мы обнаружили, что многие прокси-серверы не реализуют должным образом механизм обновления, что приводит к успешному рукопожатию, даже если последующий трафик через сокет будет неправильно интерпретирован прокси-сервером».

[TALKING] Huang, L-S., Chen, E., Barth, A., Rescorla, E., and C.

          Jackson, "Talking to Yourself for Fun and Profit", 2010,

Прежде чем формально описать этапы атаки, мы предполагаем следующих действующих лиц:

  • Злоумышленники, серверы, контролируемые самими злоумышленниками (называемые «злыми серверами»), ресурсы, созданные злоумышленниками (называемые «злыми ресурсами»)
  • Жертвы, ресурсы, к которым жертвы хотят получить доступ (называемые «ресурсами правосудия»)
  • Сервер, к которому на самом деле хочет получить доступ жертва (сокращенно «Justice Server»).
  • Промежуточный прокси-сервер

Атака Шаг 1:

  1. атакующийбраузер взлой серверИнициируйте соединение WebSocket. Согласно вышеизложенному, первым является запрос на обновление протокола.
  2. Фактическое поступление запроса на обновление протоколапрокси-сервер.
  3. прокси-серверПеренаправлять запросы на обновление протокола назлой сервер.
  4. злой серверсогласен на подключение,прокси-серверпереслать ответ наатакующий.

Из-за ошибки в реализации обновления,прокси-серверЯ думал, что то, что было перенаправлено раньше, было обычным HTTP-сообщением. Следовательно, когдаПротокольный серверсогласен на подключение,прокси-серверДумал, что сессия окончена.

Атака Шаг 2:

  1. атакующийПо ранее установленному соединению, через WebSocket интерфейс кзлой серверОтправляет данные, и данные представляют собой тщательно сконструированный текст в формате HTTP. который содержитРесурсы правосудияадрес и поддельный хост (указывающий насервер правосудия). (см. позднее сообщение)
  2. запрос поступаетпрокси-сервер. Хотя предыдущее соединение TCP используется повторно,прокси-серверДумал, что это новый HTTP-запрос.
  3. прокси-серверВ направлениизлой серверпроситьзлые ресурсы.
  4. злой сервервозвращениезлые ресурсы.прокси-серверкэшированныйзлые ресурсы(адрес правильный, но хостсервер правосудияадрес г.).

В этот момент жертва может выйти на сцену:

  1. потерпевшийпройти черезпрокси-сервердоступсервер правосудияизРесурсы правосудия.
  2. прокси-серверПроверьте URL-адрес и хост ресурса и обнаружите, что есть локальный кеш (подделка).
  3. прокси-сервербудетзлые ресурсыВернуться кпотерпевший.
  4. потерпевшийпешка.

P.S. Тщательно построенное «сообщение запроса HTTP», упомянутое ранее.

Client → Server:
POST /path/of/attackers/choice HTTP/1.1 Host: host-of-attackers-choice.com Sec-WebSocket-Key: <connection-key>
Server → Client:
HTTP/1.1 200 OK
Sec-WebSocket-Accept: <connection-key>

2. Текущие решения

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

Следует отметить, что это только ограничивает браузер для маскировки полезной нагрузки данных, но злоумышленники могут реализовать свой собственный клиент и сервер WebSocket.Если они не будут следовать правилам, атака может быть проведена как обычно.

Однако добавление этого ограничения в браузер может значительно увеличить сложность и масштаб атаки. Если такого ограничения нет, вам нужно всего лишь разместить фишинговый сайт в Интернете, чтобы обмануть людей для посещения, и вы можете запустить масштабную атаку за короткий промежуток времени.

10. Запишите это

Есть довольно много вещей, которые WebSocket может написать, например, расширения WebSocket. Как согласовать и использовать расширения между клиентом и сервером. Расширения WebSocket могут добавить к самому протоколу множество возможностей и возможностей, таких как сжатие данных, шифрование и мультиплексирование.

Из-за нехватки места я не буду расширять его здесь Заинтересованные студенты могут оставить сообщение для обмена. Если в статье есть ошибки или неточности, просьба указать.

11. Ссылки по теме

RFC6455: спецификация веб-сокета

Спецификация: детали маски фрейма данных

Спецификация: формат кадра данных

server-example

Написание веб-сервера

Атаки на сетевую инфраструктуру (для предотвращения чего предназначены операции маскирования данных)

Разговор с самим собой ради удовольствия и выгоды (с описанием атаки)

What is Sec-WebSocket-Key for?

10.3. Attacks On Infrastructure (Masking)

Talking to Yourself for Fun and Profit

Why are WebSockets masked?

How does websocket frame masking protect against cache poisoning?

What is the mask in a WebSocket frame?

Категории