Дневник белой шляпы [Часть 6]: Сообщение [Websockets + Tool]

D2 · 7 Апр 2025

GET /xss HTTP 1.1 (Вступление)
Эта статья посвящена websocket, его отличию от обычных HTTP-запросов и атакам, которые могут здесь произойти. Очевидно, что все будет происходить в лабораторной среде. В этой статье будет описан простой инструмент фаззинга, такой как "dirbuster", для поиска веб-сокетов.

Предварительные требования: Базовые знания о web и уязвимостях.
Уровень: Легкий, но не распространенный

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

Спойлер: Ссылки на предыдущие части дневника

Содержание

История
Что такое HTTP?
Что такое Websocket?
Уязвимости веб-сокета
Инструмент для фаззинга

История
Все началось с системы аутентификации, давным-давно, когда я занимался поиском ошибок, я отправлял запросы и не мог их увидеть (какой нуб, да?). Итак, затем я проверил "websocket" в burp suite и увидел websockets, мне было лень, и я решил посмотреть аниме, а не изучать websockets. Прошло некоторое время, и мы встретились с одним из моих друзей, у него, как и у меня, вообще нет социальных сетей (нам просто не с кем поговорить в социальных сетях), поэтому я сказал ему, что если он увидит мой пост о websockets, это значит, что я уволился с работы, это был способ отправить ему "сообщение". Итак, я изучил websockets и опубликовал скриншот прохождения лаборатории. Да, мы живем в каменную эру, и у нас странные способы общения.

Чтобы понять Websocket, мы должны сначала понять HTTP, это поможет нам лучше понять, зачем нам вообще нужен Websocket.

Что такое HTTP?

Ладно, прежде чем понять это, для новичков, вы, ребята, должны понять, что на самом деле представляет собой Интернет. Интернет - это большая сеть, которую мы используем для работы (передачи, хранения и т.д.) с данными. Представьте себе Интернет как "сладкое". Cеть это похоже нa "Сан-Себастьян", который один из "сладких". Тогда веб-протоколы, такие как HTTP, стали бы ингредиентами для создания "Сан-Себастьяна". HTTP - это протокол, используемый в сети (часть Интернета), который используется для передачи данных, например, это может быть открытие веб-страницы. Таким образом, структура была бы такой

Internet
1. WEB
  - HTTP
  - WebSocket
2. File Transfer
  - FTP
  - SMB
  - NFS
3. eMAIL
  - SMTP
  - POP
  - IMAP

Я, конечно, понимаю, что это не самая лучшая картина Интернета, но достаточно хорошая, чтобы объяснить новичкам, что Интернет - это не только Google. Раньше я проверял людей, и мои первые вопросы в основном касались либо модели OSI, либо "В чем разница между Интернетом и WWW?". Очевидно, когда вы это понимаете, это глупый вопрос, но все же большинство людей не могут ответить. Думайте о WWW как о чем-то, что является составной частью Интернета.

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

Прежде чем ответить на этот вопрос, просто напомню, что DNS подобен словарю-переводчику, он переводит наш домен в IP-адрес, чтобы мы могли получить нужную страницу.При попытке открыть веб-сайт. Во-первых, мы, на стороне клиента или на стороне браузера, проверяем, существует ли домен в нашем dns-кэше или нет. Если он существует, то веб-сайт открывается, в противном случае запрос отправляется нашему интернет-провайдеру (DNS-распознавателю) с доменом, к которому мы пытаемся получить доступ. Теперь наш интернет-провайдер также проверяет свой кэш, и если IP-адрес не найден, он отправляет запрос на DNS-сервер. DNS-сервер находит соответствующий сервер имен TLD, идентифицируя домен верхнего уровня домена (это '.is' из xss.is). Затем сервер имен TLD сообщит, у какого авторитетного сервера имен есть IP-адрес веб-сайта. Затем наш DNS-распознаватель получит IP-адрес домена, и мы сможем получить доступ к веб-сайту. Очевидно, что DNS-распознаватель будет кэшировать полученный IP-адрес для будущих обращений. Вторая часть - после того, как мы отправим запрос на открытие веб-сайта. Запрос содержит веб-страницу, которую мы хотим открыть, заголовки, протокол (очевидно, HTTP), его метод и используемую версию. Затем мы получим ответ от веб-сервера, содержащий код состояния, заголовки, версию HTTP и исходный код.

Когда мы настраиваем VPN, мы всегда должны проверять наличие утечки DNS, если мы этого не сделаем, наш интернет-провайдер может увидеть домены, к которым мы пытаемся получить доступ.

Давайте возьмем пример HTTP-запроса и ответа и проанализируем его.

Изображение [1]: Запрос и ответ

Давайте проанализируем часть за частью. Сначала мы видим "GET" в "верхней левой" части запроса, это метод запроса. Методы запроса объясняют веб-серверу, что мы хотим сделать. Хотим ли мы (GET) данные, хотим ли мы добавить (POST) данные, хотим ли мы обновить (PUT) уже добавленные данные, хотим ли мы удалить (DELETE) данные или что мы вообще можем сделать с данными (OPTIONS)? Я уверен, что вы поняли суть методов из риторического вопроса, который я задал. Вы можете сказать мне, что когда мы обновляем данные, вместо "PUT" отправляется запрос "POST". Ну, я написал, как это должно быть, а не как оно есть, очевидно, это зависит от разработчиков, некоторые все еще создают логины, которые работают с запросом "GET". Согласно тому, что должно быть, я должен быть баристой, но я пишу статью об информационной безопасности для одного из старейших российских доступных форумов с наибольшим влиянием (я не выдумываю:

https://socradar.io/top-5-underground-hacker-forums-that-are-accessible-via-your-web-browsers-such-as-google-chrome-firefox-and-internet-explorer

)

Итак, после методов запроса есть путь, который мы пытаемся открыть, в нашем случае это "/", который на самом деле указывает "/index.html ", которая должна быть "индексной" (главной) страницей веб-сайта. Итак, когда мы открываем "/" на самом деле "/index.html "открывается. Затем мы видим протокол и версию. В нашем случае наш протокол - "HTTP", а версия - "1.1". Первый вопрос, который приходит мне в голову, - "Почему это HTTP, если я открыл веб-сайт, который использует HTTPs?", думайте о HTTP как о "Фраппучино", а HTTPs - это "Фраппучино" с дополнительным сиропом. Тот факт, что мы добавили сироп во фраппучино, ничего не меняет. То же самое и здесь, HTTPs - это HTTP + TLS /SSL (криптографический протокол, используемый в качестве уровня (layer) безопасности).

HTTP-версии похожи на модели iPhone. Единственное отличие заключается в том, что большинство людей не видят необходимости в обновлении с версии 1.1 до более новых версий. Версия 1.1 была создана в 1997 году и используется практически повсеместно. Очевидно, что интернет-"Ванги" говорят, что он будет заменен на 2.0 в самом ближайшем будущем, хотя есть версия 3, разница между 2 и 3 в том, что 2 использует TCP, в то время как 3 использует UDP (QUIC), ну, раньше они говорили, что PHP будет заменен, и кажется, это не происходит, лол. Очевидно, я понимаю, что PHP имеет более новые версии, как и HTTP, но для того, чтобы версия 2 стала распространенной, я думаю, что сначала брандмауэры типа "Cloudflare" должны использовать ее по умолчанию.

Шутка:
Мой друг - разработчик, и у него есть знания в языке программирования go (если вы читали мои статьи, вы уже должны понимать, что я стараюсь избегать использования "Я / он / она знает", я использую "Я / Он / она обладает знаниями"). Он более опытный, чем я, и я спрашиваю его, хорошая ли это идея - проверить "Cloud Secutiy". Он такой: начни "Облачную безопасность", как только увидишь вакансию "Требуется разработчик Go". Я все еще не видел ни одного на своей местной доске объявлений о вакансиях, лол. Я думаю, прошло уже 2 года. Если вы не понимаете моих шуток, это нормально, большинство людей не понимают.

Если вы не понимаете моих шуток, ничего страшного, они, вероятно, передаются по HTTP v3.

Ниже мы видим "Заголовки", они подобны данным, которые отправляются нашим браузером на сервер для выдачи соответствующего ответа. Каждый заголовок важен, в нашем случае наиболее важным является "Host", потому что он показывает "Host", к которому мы хотим получить доступ. Как это понять? Представьте себе сервер с 1 IP-адресом и 3 веб-сайтами. И подумайте, что все 3 сайта имеют один и тот же 1 IP-адрес. И этот IP-адрес имеет только 443 и 22 открытый порт. Что произойдет, если мы откроем этот IP-адрес в браузере? Что ж, будет показана страница по умолчанию. Он может содержать все, что угодно, введенное системным администратором. Но как мы можем открыть веб-сайт с этого? Тогда заголовок "Host" начинает работать. Мы можем открыть этот IP-адрес в браузере и поставить заголовок "Host" доменом веб-сайта, который мы пытаемся открыть (в нашем случае на нашем сервере было размещено 3 веб-сайта).

Хорошо, я знаю, что объяснил это сложным образом. Давайте предположим, что у нас есть реальный IP-адрес xss.is, вот пример запроса:

curl -i -s -k -X $'GET' \ -H $'Host: xss.is' -H $'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7' -H $'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.5790.171 Safari/537.36' -H $'Connection: close' \ $'https://[IP-АДРЕС ЗДЕСЬ]/'

Изображение [2]: Пример

Я не собираюсь говорить о заголовках HTTP-запросов и ответов и их использовании.

Теперь часть ответа (правая сторона), "403" и "Запрещено", которые вы видите, - это код состояния (status code) и его значение. Это означает, что у нас нет разрешения на доступ к веб-сайту (поскольку мы не вошли в систему). На обычных веб-сайтах мы получили бы перенаправление (302, потому что оно временное) на страницу входа в систему. После кода состояния мы видим заголовки и исходный код, ничего особенного или неизвестного.

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

Код состояния	Описание
100-199	Информационный: Предоставляет информацию.
200-299	Успешно: дает нам информацию о том, что все "в порядке".
300-399	Перенаправление: Сообщает нам, что есть перенаправление.
400-499	Ошибка клиента: указывает на то, что клиент сделал что-то неправильно.
500-599	Ошибка сервера: означает, что возникла проблема с сервером.

Примеры для каждого из них по порядку. Если мы переключим протоколы, мы получим заголовок 101, который дает нам информацию о протоколе, на который он переключается. Код состояния 200 указывает на то, что страница открыта и все "ОК". Код состояния 301 указывает на постоянное перенаправление, если мы запрашиваем страницу '/abc.html ' он будет перенаправлен на '/xyz.html. Cтарый мем 404, когда учительница спрашивает домашнее задание, а вы показываете ей "404 не найдено". На самом деле это указывает на то, что пользователь (учитель) запросил неправильную страницу, страницу, которая на самом деле не существует, с сервера (учащегося). Код состояния 505 указывает на то, что версия HTTP не поддерживается. Это когда я использую HTTP v3 для доставки шуток, но вы можете принять только версию 1.1 (шутка)

Также стоит отметить, что HTTP - это протокол без сохранения состояния (stateless). Это означает, что 2 HTTP-запроса вообще не имеют никакого отношения друг к другу. Теперь возникает вопрос, если нет никакой связи между двумя HTTP-запросами, то как веб-сайты понимают, что мы вошли в систему? Это из-за "Cookies", которые изначально были изобретены для хранения товаров в корзине покупок. В нашем случае они запоминают нас с помощью "сессий/сеансов". Обычно у каждого пользователя есть своя сессия.

Теперь представьте, что у нас есть веб-сайт, подобный facebook. Пользователи постоянно добавляют реакции (лайки и т.д.). Поэтому каждый раз, чтобы увидеть реакцию на публикацию, мы должны открывать страницу публикации и обновлять ее, чтобы увидеть, были ли обновлены реакции или нет. Это может сработать при небольшом использовании, но при большом использовании это создаст очень большой ненужный трафик. Каждый раз, чтобы увидеть, сколько лайков мы получили, нам придется обновлять страницу, и если миллионы пользователей будут делать это очень часто, это будет похоже на DDoS атаку.Для таких случаев у нас есть websocket.

Что такое WebSocket?

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

Одним из примеров использования websockets может быть живой чат. Вместо того чтобы каждый раз обновлять веб-сайт, чтобы проверить, получили вы сообщение или нет, можно использовать websocket.

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

Первый HTTP-запрос отправляется на сервер. Запрос должен содержать заголовок "Connection: Upgrade \n Upgrade: websocket", который означает, что будет выполнено обновление соединения, "Sec-WebSocket-Key", который указывает случайное значение в кодировке base64, и Sec-WebSocket-Version, который указывает версию websocket. После этого сервер выдает ответ, содержащий заголовки "Upgrade: websocket", "Connection: Upgrade" и "Sec-WebSocket-Accept". Заголовок "Sec-WebSocket-Accept" - это заголовок "Sec-WebSocket-Key" + "волшебную" строку 258EAFA5-E914-47DA-95CA-C5AB0DC85B11, хэширует ее в SHA1, кодирует в base64 и отправляет в качестве ответа. Это используется для проверки "Sec-WebSocket-Accept" на стороне клиента

После этого процесса туннель был установлен, и существует связь до тех пор, пока одна из сторон не прекратит его.

Так что да, для подключения к websocket нам также нужен HTTP. Также протокол websocket использует ws:// или wss:// для безопасного подключения. Это похоже на HTTP, когда мы используем http:// или https://

Уязвимости веб-сокета

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

Лаборатория № 1

Цель этой лабораторной работы - манипулировать сообщениями WebSocket для использования xss. Я открыл лабораторию и зашел в живой чат. В BurpSuite мы увидим историю HTTP и историю WebSocket. В одном из HTTP-запросов мы увидим ответ, содержащий код состояния 101, который означает, что в протоколе происходит переключение. Если мы нажмем на этот запрос, мы увидим запрос и ответ, которые запрашиваются для установления соединения websocket.

Изображение [3]: Живой чат

Изображение [4]: История HTTP

Изображение [5]: Запрос Websocket

Изображение [6]: Ответ Websocket

Мы видим 2 запроса Websocket, первый из которых отправляется нами на сервер с сообщением "READY", другой - с сервера к нам, содержащий историю нашего чата.

Первое, что приходит на ум, - это отправить полезную нагрузку (payload) xss. Но прежде чем сделать это, давайте напишем кое-что в наш живой чат.

Изображение [7]: Живой чат

Изображение [8]: Запрос "Yo"

Давайте отправим наш запрос в repeater и заменим "Yo" полезной нагрузкой xss. Тот, который работает во многих лабораториях:
HTML: Скопировать в буфер обмена
<img src=x onerror=alert(1)//>

Изображение [9]: Отправка полезной нагрузки xss

Изображение [10]: Решение лабораторной задачи

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

Продолжение в комментах