XSS: Использование уязвимостей

Источник: «Exploiting cross-site scripting vulnerabilities»
Традиционный способ доказать, что вы обнаружили XSS уязвимость, — создать всплывающее окно с помощью функции alert(). Это не потому, что XSS имеет какое-то отношение к всплывающим окнам; это просто способ доказать, что вы можете выполнять произвольный JavaScript в заданном домене. Вы могли заметить, что некоторые люди используют alert(document.domain). Это способ сделать явным демонстрацию на каком домене выполняется JavaScrip код.

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

Использование XSS для перехвата/похищения cookie файлов

Похищение cookie файлов — традиционный способ использования межсайтовых сценариев. Большинство веб-приложений используют cookie файлы для обработки сессий. Вы можете использовать XSS для отправки cookie файлов пользователя-жертвы в свой собственный домен, а затем вручную вставлять cookie файлы в браузер и выдавать себя за пользователя-жертву.

На практике это подход имеет ряд существенных ограничений:

Использование XSS для перехвата пароля

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

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

Использование XSS для выполнения CSRF

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

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

Этот тип эксплойта обычно называют CSRF, что немного сбивает с толку поскольку CSRF также может возникать как отдельная уязвимость. Когда CSRF возникает как отдельная уязвимость, её можно исправить с помощью таких стратегий, как CSRF токены. Однако эти стратегии не обеспечивают никакой защиты, если также присутствует XSS-уязвимость.

Дополнительные материалы

Предыдущая Статья

Laravel: Валидация данных приложения

Следующая Статья

CSRF: Обход защиты основанной на Referer