Хитроватый клиентсайд

Дисклеймер, ясное дело, утверждает, что весь нижележащий пост — сплошь подлог и мистификация. Ничего этого в реальности не было и нет.

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

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

Интро

Представим себе организацию, очень большую. На периметре этой огранизации расположены десятки веб-приложений совершенно различного толка, многим из них необходимо, чтобы пользователь имел возможность логиниться. Для обеспечения сквозной аутентификации создаётся веб-сервис, назовём его Vault. Пользователь регистрируется в нём один раз, сохраняет в профиль свои личные данные и, аутентифицировавшись в Vault, может ходить по всем ресурсам организации и везде быть узнанным. Предлоложим, что наше целевое приложение располагается по адресу

vault.example.com

CORS

Основой будущей атаки станет уязвимость в конфигурации Cross-Origin Resource Sharing на сервере, где расположено наше веб-приложение Vault. Если не знаете ничего про такие уязвимости, а очень хочется — рекомендую блогпост Джеймса. В нашем случае имеет место самый простой для атакующего сценарий.

Вкратце. Запрос:

Ответ:

Мы отправляем серверу запрос и в поле Origin указываем адрес подконтрольного нам ресура, а сервер вежливо сообщает, что этому ресурсу он доверяет (Access-Control-Allow-Origin) и позволил бы прочитать ему ответ на кросдоменный запрос, в обход Same-Origin Policy. Да ещё и разрешил бы послать с ответом аутентификационные данные пользователя (Access-Control-Allow-Credentials). Мило, но что это нам даёт?

Например то, что мы можем заманить пользователя на свой ресурс, а когда он к нам зайдёт, отправить от его имени XMLHttpRequest, допустим, на vault.example.com/identity, после этого получить ответ на своём же ресурсе и спокойно его распарсить. А что если на странице /identity располагется какой-нибудь секретный токен или данные кредитки? Это в худшем случае, в Vault же ничего особенно чувствительного на страницах сайта не хранится, а значит придётся найти уязвимости другое применение.

CSRF

Да, у них есть CSRF-токен. Но он не очень. На любой странице ресурса, откуда можно отправить POST (редактирование персональных данных, смена пароля) к каждой форме пришито hidden-поле по имени csrf_token. При отправке POST-запроса токен располагается первым в списке параметров.

Ах да, генерируется он один раз за сессию и на всём её протяжении не изменяется. От атак в один клик спасает, но если уж токен попадёт в руки к атакующему, то тот сможет подписать им сколько угодно запросов клиента до самого окончания сессии.

Self-XSS

XSS проста, как палка. Данные, вводимые пользователем в поля Фамилия, Имя и Отчество на странице vault.example.com/identity нисколько не ощичаются от злобного пользовательского ввода. Это позволяет натурально положить туда даже банальный пейлод а-ля

<script>alert(0)</script>

но не сразу нашлось место, где это данные отражаются, так как везде указано только название учётной записи пользователя, но не его имя. А если на сторонних ресурсах данные и берутся из полей ФИО, то уже там проходят санитизитацию. Внезапно оказалось, что ФИО пользователя отражается на странице vault.example.com/api. Зачем демонстрировать пользователю его полное ФИО на странице с техническим описанием методов, реализованных в API? Вот и я не знаю.

Проблема в том, что пользователь должен сам себе записать вредоносный пейлод в одно из полей и отправиться на страницу API. Оно ему надо? Конечно нет.

Open Redirect

Незащищённый редирект присоединился к цепочке последним. Здесь не о чем особо говорить. При переходе на страницу с таким параметром

vault.example.com/login?return_url=http://attacker.com

пользователя сначала просят залогиниться, а уже потом перенаправляют на return_url. Сам по себе этот редирект не очень интересен, так как если пользователь уже залогинен, мгновенного редиректа не происходит — вместо этого его снова просят ввести логин и пароль.

Однако в комбинации с остальными уязвимостями это, скорее, является преимуществом, так как нам необходимо, чтобы пользователь был аутентифицирован. А здесь он мало того что переходит по ссылке на легитимный, а не фишинговый ресурс, он ещё и вынужден ввести логин и пароль, что гарантирует аутентификацию, после чего мгновенно перенаправлен на подконтрольный атакующему ресурс.

Аутро

Теперь просуммируем всё, что мы имеем к настоящему моменту и сформируем сам вектор атаки.

  • Пользователь получает ссылку вида

vault.example.com/login?return_url=http://attacker.com

При переходе по ней приложение предлагает ему ввести логин и пароль. Аутентифицировавшись, клиент мгновенно перенаправляется на attacker.com, где сразу же исполняется заготовленный атакующим скрипт;

  • Первым делом отправляется XMLHttpRequest на страницу vault.example.com/identity, так как на ней располагаются поля с персональными данным пользователя, а значит и hidden-поле csrf_token. Поскольку запрос уйдёт снабжённый заголовком Origin, где будет указан домен attacker.com, сервер начнёт ему слепо доверять, соответсвенно, в ответ придёт html-страница жертвы. Остаётся распарсить её и выковырять оттуда сам CSRF-токен;
  • Полученный токен добавляется к POST-запросу на всё ту же страницу /identity. Теперь мы отправляем запрос на изменение имени пользователя на <script>alert(0)</script>. Снова запрос снабжён заголовком Origin и снова он доходит до места назначения. Имя пользователя теперь содержит вредоносный пейлод;
  • Поскольку активация пейлода произойдёт только на странице API, а надеяться на то, что пользователь туда пойдёт, не приходится, то происходит принудительный редирект на страницу vault.example.com/api. Пользователь попадает обратно на легитимный ресурс, а в его браузере выполняется код пейлода в контексте веб-приложения Vault.

Таким образом комбинируются 4 уязвимости, вкупе представляя собой довольно универстальный вектор атаки на любого клиента веб-приложения Vault.

Пример исходника скрипта, который мог бы располагаться на странице ресурса attacker.com из вышеописанного примера. В POST-запросе для наглядности убран URL-энкодинг.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *