WebSocket Security: Угон сокета (CSWSH)
Сервер открывает WebSocket-соединение для отправки приватных уведомлений, но забывает проверять Origin. Воспользуйтесь ботом администратора, чтобы заставить его открыть вашу вредоносную страницу и угнать флаг через сокет.
hardgolangPro
Задача
# Cross-Site WebSocket Hijacking (CSWSH)
## Сценарий
Вы аудируете внутренний сервис **SecureShop**. У приложения есть WebSocket-эндпоинт, который выдаёт пользователю в реальном времени служебную информацию: при подключении сервер аутентифицирует клиента по HTTP-сессионной cookie и отправляет приветственное сообщение с персональными данными. По данным внутреннего аудита, для администратора это сообщение содержит конфиденциальную метку. Команда уверена, что эндпоинт защищён — без admin-сессии данные не отдаются. Платформа предоставляет «Exploit Server» с встроенным ботом-администратором, готовым посетить любую переданную ему ссылку (это эмулирует client-side компонент атаки в реальной CTF-среде).
## Цель
1. Изучите, как WebSocket-эндпоинт сервера реагирует на handshake с разных origin-источников: проверяется ли заголовок Origin при upgrade-запросе, или соединение принимается от любого домена.
2. Используя клиентский canvas (страницу под вашим контролем на Exploit Server), заставьте бота-администратора установить WebSocket-соединение с целевым приложением — браузер автоматически приложит admin-сессию.
3. Перехватите содержимое первого сообщения (которое сервер отправит для admin-сессии) и доставьте его на Exploit Server для прочтения. Извлеките флаг.
## Теория
WebSocket — особенный протокол с точки зрения safe-by-default браузерной защиты: рукопожатие выполняется через HTTP с заголовком `Upgrade`, и **браузер автоматически прикладывает cookies** к этому handshake-запросу. Однако, в отличие от классических XHR/fetch-запросов, к WebSocket-соединениям **не применяется** Same-Origin Policy / CORS: после успешного upgrade страница может читать ответы и отправлять данные без preflight-проверок. Это значит, что вся ответственность за защиту от cross-site WebSocket-атак лежит на серверной стороне — конкретно, на проверке заголовка `Origin` в handshake.
**Уязвимый паттерн:**
```go
// CheckOrigin принимает любой origin — соединение разрешается с любого домена
var upgrader = websocket.Upgrader{
CheckOrigin: func(r *http.Request) bool {
return true // <-- источник запроса не валидируется
},
}
```
Атака CSWSH (Cross-Site WebSocket Hijacking) работает так: атакующий размещает на своём сайте JavaScript, открывающий WebSocket к целевому приложению; жертва (с активной сессией) посещает страницу атакующего; браузер устанавливает соединение с куками жертвы; JavaScript атакующего читает ответы и эксфильтрирует их на собственный сервер. Без CORS-защиты для WebSocket это работает «из коробки» — единственный сигнал, который сервер мог бы использовать для отказа, это заголовок `Origin`.
## Точка входа атаки
| Параметр | Значение |
|----------|----------|
| WebSocket-эндпоинт | `GET /ws` (Upgrade: websocket) |
| Канал доставки атаки | Exploit Server в панели лаборатории + бот-администратор |
| Цель | заставить бота-администратора установить WebSocket с приложением через подконтрольную страницу и получить admin-сообщение с флагом на Exploit Server |