WebSocket. Краткий экскурс в пентест ping-pong протокола

"Краткость - сестра таланта" - именно так сказал Антон Павлович Чехов, и теперь говорю я. Сегодня, завтра и до конца дней площадки речь пойдет о WebSocket-ах: "Что это?", "Как работает?" и главное - "Как это взламывать?" (в целях этичного хакинга конечно). Начнем с простого и будем идти к более сложному, пробираясь через тернии к звёздам. Приятного чтения.

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

Оглавление

• Начнем с основ

  • Давайте углубляться

    • Компоненты WS

    • Как работает это рукопожатие?

• Основы есть, теперь к теме "а как с ним работать?"

  • SocketSleuth

  • Вспомним и про Owasp Zap

• Уязвимости WebSocket

  • Манипулирование сообщениями WebSocket

  • Манипулирование рукопожатием WebSocket

  • Использование межсайтовых WebSockets

  • Как находить?

  • CSWSH

    • Как обнаружить?

    • Эксплуатация

    • "Bypass protection"

• Инструменты для автоматизированного тестирования

• Заключение

Начнем с основ

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

Протокол имеет две схемы URI:

• ws: / host [: port] path [? query] для обычных соединений.

• wss: / host [: port] path [? query] для туннельных соединений TLS.

Вот основные характеристики и особенности WebSocket:

1. Установка соединения: WebSocket начинается с установки соединения через HTTP (обычно используется стандартный порт 80 или защищенный порт 443). После успешной установки соединения клиент и сервер могут обмениваться данными в реальном времени;

2. Двусторонняя связь: WebSocket поддерживает как отправку данных от клиента к серверу, так и от сервера к клиенту. Это позволяет строить интерактивные веб-приложения, где клиент и сервер могут обмениваться информацией без задержек;

3. Низкая задержка: WebSocket обеспечивает низкую задержку (лаг) по сравнению с традиционными методами долгой опросы (long polling) или периодическими запросами;

4. Протокол на основе кадров (frame-based protocol): Данные в WebSocket упаковываются в кадры (frames), что делает их эффективными для передачи и обработки;

5. Поддержка защиты (Security): WebSocket может использовать шифрование для обеспечения безопасности передаваемых данных, используя wss:// вместо ws:// в URL;

6. Поддержка разных типов данных: WebSocket позволяет передавать различные типы данных, включая текст, бинарные данные и даже произвольные объекты;

7. Событийная модель: WebSocket использует событийную модель для обработки входящих данных. Это означает, что Вы можете реагировать на события, такие как открытие соединения, получение сообщения или закрытие соединения.

Пример использования WebSocket:

1. Установка соединения:

   • Клиент отправляет HTTP-запрос на сервер с заголовком "Upgrade: websocket".

   • Если сервер поддерживает WebSocket, он возвращает HTTP-ответ с заголовком Upgrade: websocket, и соединение переключается на WebSocket.

2. Обмен данными:

   • Клиент и сервер могут отправлять друг другу текстовые или бинарные кадры через установленное соединение.

3. Закрытие соединения:

   • Клиент или сервер могут закрыть соединение по желанию, отправив специальный кадр.

Для лучшего понимания, представьте настольный теннис. Сервер периодически присылает ответ по WS с просьбой о действии - послать запрос на сервер. Если клиент отвечает до истечения тайм-аута — он подключен, если нет, то происходит разрыв соединения до следующего рукопожатия.

Я думал, что не так уж и много приложений используют WS... Как же я ошибался.

Давайте углубляться

Для детального понимания протокола WebSocket крайне важно знать его "строительный блок". Наиболее важные моменты упомянуты ниже.

• Fin Bit - это фундаментальный бит WebSocket. Он автоматически генерируется при начале соединения.

• RSV1, RSV2, RSV3 Bits - биты, зарезервированные для дальнейших возможностей.

• Opcode является частью каждого кадра и объясняет процесс интерпретации данных полезной нагрузки конкретного кадра. Некоторые из распространенных значений Opcode - 0x00, 0x0, 0x02, 0x0a, 0x08 и многие другие.

• Mask bit активизируется, когда один из битов установлен в 1.

WebSocket требует использования подобранного клиентом случайного ключа для всех данных полезной нагрузки. Маскирующий ключ, совмещенный с данными полезной нагрузки, помогает разделить данные полезной нагрузки в операции XOR. Это имеет большое значение с точки зрения безопасности прикладного API, поскольку маскирование позволяет предотвратить неправильную интерпретацию или отравление кэша.

Компоненты WS

Давайте подробнее разберемся в его важнейших компонентах:

Длина полезной нагрузки (Payload len)
Используется для кодирования общей длины данных полезной нагрузки в WebSocket. Payload len отображается, когда длина кодируемых данных меньше 126 байт. Если длина данных полезной нагрузки превышает 126 байт, то для описания длины полезной нагрузки используются дополнительные поля.

Masking-key
Каждый кадр, отправляемый клиентом на сервер, маскируется 32-битным значением. Маскирующий ключ отображается, когда бит маски равен 1. В случае если бит маски равен 0, маскирующий ключ будет равен нулю.

Данные полезной нагрузки (Payload data)
Всевозможные произвольные данные приложения и данные расширения называются данными полезной нагрузки. Эти данные используются клиентом и сервером для переговоров и применяются в ранних рукопожатиях WebSocket. Тут же, возникает вопрос - "А какие данные можно передавать?". WebSockets могут передавать любые типы данных, которые могут быть сериализованы в строковый или двоичный формат, включая текст, изображения и мультимедиа. Это делает их пригодными для широкого круга приложений, требующих обмена данными в реальном времени.

Как работает это рукопожатие ?

Рукопожатие — это первый шаг в общении между клиентом и сервером. Клиент и сервер для рукопожатия используют протокол HTTP, однако формат доставляемых сообщений немного различается. Не все критерии HTTP-сообщения соблюдены. Например, отсутствует заголовок Content-Length.
Сначала клиент устанавливает соединение с сервером и отправляет следующий запрос:

GET /echo HTTP/1.1  
Host: localhost:8081  
Sec-WebSocket-Version: 13  
Origin: http://localhost:8081  
Sec-WebSocket-Key: SWxvdmVjYXRzdmVyeW11Y2g=  
Connection: keep-alive, Upgrade  
Upgrade: websocket

Мы также можем спросить какая версия используется, указав любую цифру

Sec-WebSocket-Version: 16

Если сервер не может обмениваться данными с использованием указанной версии протокола WebSocket, он ответит ошибкой (например, 426 Требуется обновление), которая включает в свои заголовки заголовок Sec-WebSocket-Version со списком поддерживаемых версий, разделенных запятыми. версии протокола. Если сервер поддерживает запрошенную версию протокола, в ответ не включается заголовок Sec-WebSocket-Version.

Версия протокола WebSocket, которую клиент желает использовать при обмене данными с сервером. Этот номер должен быть самой последней версией, указанной в реестре номеров версий IANA WebSocket. Самая последняя версия протокола WebSocket — версия 13.

Соединение: Sec-WebSocket-Version, Sec-WebSocket-Key Upgrade и Upgrade: необходимы заголовки WebSocket; в противном случае сервер ответит HTTP/1.1 400 Bad Request. Вот как сервер отвечает на запрос клиента:

HTTP/1.1 101 Switching Protocols  
Upgrade: websocket  
Connection: Upgrade  
Sec-WebSocket-Accept: s3pPLMBiTxaQ3oYGazhZRuK+xOo=

Клиент генерирует заголовок Sec-WebSocket-Key как случайное 16-байтовое значение, закодированное в Base64.

Заголовки Sec-WebSocket-Key и Sec-WebSocket-Accept не используются для авторизации или поддержки сеансов; вместо этого они проверяют, что и запрос, и ответ используют протокол WebSocket. Это гарантирует, что сервер не будет принимать запросы от клиентов, не использующих WebSockets.

Если вы хотите углубиться ещё, то можете почитать Base Framing Protocol

Все сообщения клиента должны быть замаскированы. Пример сообщения «Привет, мир!» текстовое сообщение, отправленное клиенту (данные из tcpdump):

Fin: True  
Reserved: 0x0  
Opcode: Text (1)  
Mask: True  
Payload length: 14  
Masking-Key: a9292b01  
Payload: eaf7f76dcdb2ac6ed0fefx2021

Маскирование осуществляется обычным XOR с mask key. Клиент должен менять ключ для каждого передаваемого кадра. Сервер не должен маскировать свои сообщения. Пример передачи текстового сообщения "Hello world!" серверу:

Fin: True  
Reserved: 0x0  
Opcode: Text (1)  
Mask: False  
Payload length: 14  
Payload: 98658c6c7f20776f726c642021

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

Основы есть, теперь к теме "а как с ним работать?"

Я мог бы начать говорить что вот у postman есть возможность работать с WebSocket (как неожиданно