>
Июнь 2018
Пн Вт Ср Чт Пт Сб Вс
« Апр    
 123
45678910
11121314151617
18192021222324
252627282930  

Выполнение cross-site websocket hijaking

Вернемся обратно к вебу, точнее к его будущему. В НТМL5 появилось множество технологий, в том числе и такая технология, как веб-сокеты.

Веб-сокеты это такой протокол, который позволяет установить полнодуплексное соединение между браузером и сервером по протоколу ТСР. То есть вместо обычного безсесионного НТТP с его “запрос-ответ” мы имеем обычное ТСP-подключение, где любая из сторон может слать данные, и это все в рамках одной ТСР-сессии.

Несмотря на невысокую распространенность применения веб-сокетов, все современные браузеры их поддерживают (даже ИЕ).

Далее немного фактов, Веб-сокеты работают на тех же портах, что и сам веб-сервер, HTTPS поддерживает. Они обозначаются схемой “ws://” и “wss://” для защищенного подключения. Данные внутри веб-сокета (после установки подключения) не шифруются, a только маскируются.

Для того чтобы установить подключение, веб-сервер посылает GEТ-запрос на веб-сервер для инициализации соединения. Основное отличие этого запроса от обычного дополнительные заголовки (заголовки после HOST):

Последние два указывают браузеру на переход на веб-сокет. Далее версия протокола и случайное значение, для защиты от “поддельных запросов” (хотя не очень понятно, какая там атака может быть). Очень важный заголовок Origin, указывает, c какого сайта было инициализировано подключение.
Ответ от сервера будет следующим:

Последние два заголовка аналогичны. далее три заголовка в стиле CORN, которые указывают возможность отсьлки кредам дополнительных заголовков, a также с какого домена это разрешено. Ho фактически эта троица ни на что не влияет, потому как сразу после получения ответа создается веб-сокет (To есть обычное ТCР-подключение), где уже передается текст или данные. Формат пакетов вполне минимален: несколько бит для фрагментации, маски и размера данных в пакете a далее данные.

И самый важный момент веб-сокет изначально спроектирован для межсайтового взаимодействия, a потому SOP фактически на него не действует. Еще, возможно, интересен вопрос a том, как мы можем узнать (с точки зрения пентестера), поддерживаются ли веб-сокеты в данном конкретном приложении.

Ho были попробованы различные методы, и единственный выявленный вариант протыкать указанным выше запросом все пути на сайте (так как, например, на запрос к корню, сервер вернет нам 404, a на какой-нибудь web/char разрешение на коннект).

О’кей, теперь перейдем к самой атаке на сокеты c таким забавным названием, как Cross-Site Websocket Hijacking. Она на самом  деле проста. Суть ее в том, что мы c нашего сайта (origin’a) можем создать веб-сокеты с атакуемым веб-приложением от имени юзера (зашедшего на наш сайт).

Тут ведь в чем дело: во-первых, инициировать создание веб-сокета к атакуемому веб-приложению мы можем c любого сайта. A во-вторых, при инициализирующем запросе автоматически подставятся куки (или НТТР-аутентификация), так как это обычный GЕТ-запрос, только с дополнительными заголовками. Фактически получается, что это обычная CSRF-атака, только на выходе мы имеем веб-сокет, с помощью которого можем общаться с веб-приложением от имени юзера.

Теперь немного о тонкостях. Kaк ты видел в ответе от сервера, там есть различные заголовки. Например, Access-Control-Allow-Origin, который должен был бы защищать юзера: если eго браузер получает в этом поле другой сайт, чем TOT, с которого мы инициировали веб-сокет, то браузер должен веб-сокет не устанавливать.

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

Возможно, у тебя возник вопрос: a что нам СSWSН может дать? С одной стороны, ничего универсального. Это не xss, где мы c JS можем творить чудеса. Несмотря на название, лучше воспринимать это как что-то похожее на CSRF.
C другой стороны, если функционал приложения через веб-сокеты велик, то, учитывая возможность и слать запросы, и получать ответы, мы можем сделать очень многое.

И немного о практике. К сожалению, всеми любимый Burp (1.6) умеет лишь снифать передаваемые данные, a отправлять произвольные запросы в веб-сокет не умеет. Зато это умеют делать ZAP и гораздо менее известный продукт IronWASP (www.ironwаsр.org). Для тестирования самой атаки можно воспользоваться и онлайн-сервисом goo.gl/vMiOsu.
Спасибо за внимание и успешных познаний нового!

Share Button
[Всего голосов: 2    Средний: 5/5]

Вам может быть интересно также:

Last updated by at .

Leave a Reply

You can use these HTML tags

<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">