Как стать автором
Обновить

XSS атакует! Краткий обзор XSS уязвимостей

Уровень сложностиСредний
Время на прочтение11 мин
Количество просмотров28K
Всего голосов 23: ↑23 и ↓0+23
Комментарии8

Комментарии 8

Оставлю полезную ссылку по теме (можно по репе походить — там много интересного лежит).

Стоит указывать названия XSS на английском языке, так как именно эти названия считаются общепринятыми:

Reflected XSS (Отраженная XSS)

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

Например, помещаем параметр target_host=<script>alert(1)</script>, но нужно еще привести пользователя на эту страницу.

Stored XSS (Хранимая XSS)

Именно хранимая, а не сохраненная.

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

Простой пример, кто-то разместил в комментарии вот такой код:

<img src=1 onerror=alert(1)>

DOM-Based XSS

Отличительной особенностью данного вида XSS является то, что payload не отображается в коде страницы, которая возвращается пользователю, то есть не передается серверу. Поэтому обнаружить данный вид XSS, основываясь только на основе анализа возвращаемого кода, затруднительно.

Возможные источники (sources в иностранной терминологии), которые могут быть использованы злоумышленником:

●      document.URL

●      document.documentURI

●      document.URLUnencoded (IE 5.5 or later Only)

●      document.baseURI

●      location

●      location.href

●      location.search

●      location.hash

●      location.pathname

●      window.name

●      document.referrer

Blind XSS (слепая xss)

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

Например, обратная связь или премодерация комментариев через админку.

Self XSS

Данная атака реализуется только в том случае, если ее выполнит сам пользователь. Уязвимость при этом присутствует в функциях, которые доступны только владельцу (пользователю) аккаунта.

Например, так называемый "взлом" facebook, примерно в 2014 году, когда пользователям рассылали сообщения, мол для вашей безопасности нужно открыть в браузере консоль и ввести туда определенный код.

Спасибо, хороший поинт с нэймингом, поправлю обязательно. И добавлю про Self XSS, совсем про него забыл, хоть это и сложно считать настоящей XSS уязвимостью, но знать полезно.

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

Можно долго спорить к чему её отнести, так как с таким же успехом можно и AnyDesk попросить поставить.

На самом деле почему нет, всё зависит от ситуации.

Представим self-xss которая находится где нибудь в био профиля пользователя, при этом другие пользователи не могут открыть любой другой профиль, кроме своего. Связав такую self-xss и csrf login/logout, можем получить следующий вектор:

Атакующий делает self-xss в профиле -> жертва переходит на сайт с эксплоитом -> csrf logout -> csrf login в аккаунт атакующего -> перенаправляем жертву по URL с профилем -> т.к. жертва в аккаунте атакующего, срабатывает XSS. Дальше можно допустим слать запросы на другой домен данной компании, на какой нибудь путь с sensetive информацией, и т.к. домен доверенный и если он добавлен в CORS, прилетят интересующие нас данные, а дальше уже шлем их атакующему. Ну на крайний случай да хоть фейк логин форму сделать.

В целом, это считается self-xss

Атакующий делает self-xss в профиле -> жертва переходит на сайт с эксплоитом -> csrf logout -> csrf login в аккаунт атакующего -> перенаправляем жертву по URL с профилем -> т.к. жертва в аккаунте атакующего, срабатывает XSS.

Это уже Content spoofing, а не Self XSS.

Content spoofing (также именуемая content injection и virtual defacement) – атака, при которой у злоумышленника есть возможность внести изменения в страницу и доставить такую страницу пользователю. Типичный сценарий: злоумышленник посылает жертве ссылку, параметры которой модифицируют страницу, которую жертва откроет, перейдя по ссылке. Жертва при этом видит как бы доверенный домен.

НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий