(Reflected XSS) Отраженный межсайтовый скриптинг
В этом разделе мы объясним, что такое отражённый межсайтовый скриптинг, опишем последствия атак отражённого XSS и расскажем, как находить уязвимости отражённого XSS.
Что такое отражённый межсайтовый скриптинг?
Отражённый межсайтовый скриптинг (или XSS) возникает тогда, когда приложение получает данные в HTTP-запросе и включает эти данные в непосредственный ответ небезопасным образом.
Предположим, что на сайте есть функция поиска, которая получает поисковый запрос от пользователя через параметр URL:
https://insecure-website.com/search?term=giftПриложение выводит переданный поисковый термин в ответе на этот URL:
<p>You searched for: gift</p>Если приложение не производит дополнительной обработки данных, злоумышленник может сконструировать подобную атаку:
https://insecure-website.com/search?term=<script>/*+Bad+stuff+here...+*/</script>В результате получается такой ответ:
<p>You searched for: <script>/* Bad stuff here... */</script></p>Если другой пользователь зайдёт по атакующей ссылке, скрипт, предоставленный злоумышленником, выполнится в браузере жертвы — в контексте её сессии с приложением.
Влияние атак отражённого XSS
Если злоумышленник может контролировать скрипт, исполняемый в браузере жертвы, он обычно может полностью скомпрометировать этого пользователя. В частности, атакующий сможет:
Выполнять любые действия в приложении от лица пользователя.
Просматривать любую информацию, доступную пользователю.
Изменять любую информацию, доступную пользователю.
Запускать взаимодействия с другими пользователями приложения, включая вредоносные действия, которые будут казаться происходящими от имени исходного пользователя.
Существует множество способов заставить жертву выполнить управляемый злоумышленником запрос с целью доставки отражённой XSS-атаки. Это может быть размещение ссылок на подконтрольном сайте, либо на любом другом сайте, где разрешён пользовательский контент, отправка ссылки по электронной почте, через твит или другим сообщением. Атака может быть нацелена как на конкретного известного пользователя, так и носить массовый, безадресный характер по отношению ко всем пользователям приложения. Необходимость использовать внешний механизм доставки атаки делает последствие отражённого XSS обычно менее серьёзным, чем у сохранённого XSS, где атака может быть проведена через само уязвимое приложение.
Разновидности отражённого XSS
Существует множество вариантов реализации отражённого межсайтового скриптинга. Место появления отражаемых данных в ответе приложения определяет тип полезной нагрузки и может повлиять на последствия уязвимости.
Кроме того, если приложение выполняет какую-либо валидацию или дополнительную обработку отправленных данных перед их отражением, это также повлияет на то, какой XSS-пейлоад подойдёт.
Как находить и тестировать уязвимости отражённого XSS
Подавляющее большинство уязвимостей отражённого XSS можно быстро и надёжно обнаружить с помощью сканера уязвимостей Burp Suite.
Ручное тестирование отражённого XSS состоит из следующих шагов:
Проверьте каждый входной вектор. Для каждого возможного места передачи данных в HTTP-запросах приложения (включая параметры строки запроса URL, тело сообщений, путь файлов URL, заголовки HTTP) проведите отдельное тестирование. Следует отметить, что XSS-подобное поведение, которое можно вызвать только через определённые заголовки HTTP, на практике обычно невосприимчиво к эксплуатации.
Передавайте случайные буквенно-цифровые значения. В каждую точку ввода поместите уникальное случайное значение и проверьте, появляется ли оно в ответе. Значение должно легко пройти большинство фильтров — быть достаточно коротким и состоять только из цифр или символов латиницы, но достаточно длинным, чтобы исключить случайные совпадения. Обычно хорошо подходят случайные строки длиной 8 символов. Можно использовать числовые пейлоады в Burp Intruder с рандомно сгенерированными шестнадцатеричными значениями для генерации таких строк. И функцию автоматической проверки появления значения в ответе.
Определите контекст отражения. Для каждого места в ответе, где найдено отражение значения, анализируется контекст его появления — находится оно в обычном тексте между HTML-тегами, внутри атрибута тега (цитируемого или нет), внутри строки JavaScript и т.д.
Проверьте потенциальный полезный пейлоад. Исходя из контекста отражения, подберите первоначальный XSS-пейлоад, который вызовет выполнение JavaScript, если попадёт в ответ без изменений. Самый простой путь — отправить запрос через Burp Repeater, заменить передаваемое значение на XSS-пейлоад, выполнить запрос и просмотреть ответ. Предпочтительно сохранять исходное рандомное значение в запросе — и добавлять XSS-пейлоад перед ним или после него. Затем используйте это уникальное значение для поиска по ответу, чтобы быстро находить, где оно встретилось. Burp выделит все места появления строки в ответе.
Проверьте альтернативные пейлоады. Если выбранный XSS-пейлоад был модифицирован приложением или вовсе заблокирован, тестируйте различные альтернативы в зависимости от контекста отражения и типа валидации на стороне сервера. Подробности и списки пейлоадов для разных контекстов см. в (XSS contexts) Контексты межсайтового скриптинга.
Проверьте атаку в браузере. Если удалось подобрать пейлоад, который сработал в Burp Repeater, перенесите атаку в настоящий браузер (например, скопируйте URL в адресную строку или перехватите настоящий запрос через Burp Proxy) и убедитесь, что внедрённый JavaScript действительно выполняется. Обычно удобно использовать простой скрипт вроде
alert(document.domain)— он вызывает видимое всплывающее окно при успехе.
Частые вопросы по отражённому XSS
Чем отличается отражённый XSS от сохранённого?
Отражённый XSS возникает при небезопасном помещении входных данных из HTTP-запроса в немедленный ответ. При сохранённом XSS данные сохраняются и появляются в будущих HTTP-ответах.
В чём отличие отражённого XSS от self-XSS?
Self-XSS предполагает аналогичное поведение приложения, однако уязвимость нельзя вызвать с помощью подготовленного URL или кросс-доменного запроса — она срабатывает только при ручном вводе XSS-пейлоада жертвой в собственном браузере. Как правило, доставка такой атаки требует социальной инженерии (убедить пользователя вставить вредоносный код) и считается малозначимой, низкоуровневой проблемой.
Last updated