Reflected XSS
В этом разделе мы объясним, что такое Reflected XSS, опишем последствия таких атак и расскажем, как находить такие уязвимости.
Что такое Reflected XSS?
Reflected 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>Если другой пользователь зайдёт по ссылке предоставленной атакующим, то скрипт, предоставленный атакующим, выполнится в браузере жертвы — в контексте её сессии с приложением.
Влияние атак Reflected XSS
Если атакующий может контролировать скрипт, исполняемый в браузере жертвы, он обычно может полностью скомпрометировать этого пользователя. В частности, атакующий сможет:
Выполнять любые действия в приложении от лица пользователя.
Просматривать любую информацию, доступную пользователю.
Изменять любую информацию, доступную пользователю.
Запускать взаимодействия с другими пользователями приложения, включая вредоносные действия, которые будут казаться происходящими от имени исходного пользователя.
Существует множество способов заставить жертву выполнить управляемый атакующим запрос с целью доставки Reflected XSS. Это может быть размещение ссылок на подконтрольном сайте, либо на любом другом сайте, где разрешён пользовательский контент, отправка ссылки по электронной почте, через твит или другим способом. Атака может быть нацелена как на конкретного известного пользователя, так и носить массовый, безадресный характер по отношению ко всем пользователям приложения. Необходимость использовать внешний механизм доставки атаки делает последствие Reflected XSS обычно менее серьёзным, чем у Stored XSS, где атака может быть проведена через само уязвимое приложение.
Разновидности Reflected XSS
Существует множество вариантов реализации Reflected XSS. Место появления отражаемых данных в ответе приложения определяет тип полезной нагрузки и может повлиять на последствия уязвимости.
Кроме того, если приложение выполняет какую-либо валидацию или дополнительную обработку отправленных данных перед их отражением, это также повлияет на то, какая XSS-нагрузка понадобится или как она будет эксплуатироваться.
Как находить и тестировать уязвимости Reflected XSS
Некоторую часть уязвимостей Reflected XSS можно обнаружить с помощью сканера уязвимостей Burp Suite, но ручное тестирование будет намного выгоднее в перспективе.
Ручное тестирование Reflected XSS состоит из следующих шагов:
Проверьте каждый входной вектор. Для каждого возможного места передачи данных в HTTP-запросах приложения (включая параметры строки запроса URL, тело сообщений, путь файлов URL, заголовки HTTP) проведите отдельное тестирование. Следует отметить, что XSS-подобное поведение, которое можно вызвать только через определённые заголовки HTTP, на практике обычно невосприимчиво к эксплуатации. Только в некоторых случаях эксплуатация будет возможна, например, можно эксплуатировать XSS в заголовке User-Agent в комбинации с HTTP-Request Smuggling или Web Cache Poisoning.
Передавайте случайные значение. В каждую точку ввода поместите уникальное случайное значение и проверьте, появляется ли оно в ответе. Значение должно легко пройти большинство фильтров — быть достаточно коротким и состоять только из цифр или символов латиницы, но достаточно длинным, чтобы исключить случайные совпадения. Обычно хорошо подходят случайные строки длиной 8 символов. Можно использовать числовые пейлоады в Burp Intruder с рандомно сгенерированными шестнадцатеричными значениями для генерации таких строк. И функцию автоматической проверки появления значения в ответе.
Определите контекст отражения. Для каждого места в ответе, где найдено отражение значения, анализируется контекст его появления — находится оно в обычном тексте между HTML-тегами, внутри атрибута тега (цитируемого или нет), внутри строки JavaScript и т.д.
Проверьте потенциальную полезную нагрузку. Исходя из контекста отражения, подберите первоначальный XSS-пейлоад, который вызовет выполнение JavaScript, если попадёт в ответ без изменений. Самый простой путь — отправить запрос через Burp Repeater, заменить передаваемое значение на XSS-нагрузку, выполнить запрос и просмотреть ответ. Предпочтительно сохранять исходное рандомное значение в запросе — и добавлять XSS-нагрузку перед ним или после него. Затем используйте это уникальное значение для поиска по ответу, чтобы быстро находить, где оно встретилось. Burp выделит все места появления строки в ответе.
Проверьте альтернативные пейлоады. Если выбранный XSS-пейлоад был модифицирован приложением или вовсе заблокирован, тестируйте различные альтернативы в зависимости от контекста отражения и типа валидации на стороне сервера. Подробности и списки пейлоадов для разных контекстов см. в Контексты Cross-Site Scripting.
Проверьте атаку в браузере. Если удалось подобрать полезную нагрузку, которая сработала в Burp Repeater, перенесите атаку в настоящий браузер (например, скопируйте URL в адресную строку или перехватите настоящий запрос через Burp Proxy) и убедитесь, что внедрённый JavaScript действительно выполняется. Обычно удобно использовать простой скрипт вроде
alert(document.domain)— он вызывает видимое всплывающее окно при успехе.
Частые вопросы по отражённому XSS
Чем отличается Reflected XSS от Stored XSS?
Reflected XSS возникает при небезопасном помещении входных данных из HTTP-запроса прямо в ответ. При Stored XSS данные сохраняются и появляются в будущих HTTP-ответах.
В чём отличие Reflected XSS от Self-XSS?
Self-XSS предполагает аналогичное поведение приложения, однако уязвимость нельзя вызвать с помощью подготовленного URL или кросс-доменного запроса — она срабатывает только при ручном вводе полезной нагрузки жертвой в собственном браузере. Как правило, доставка такой атаки требует социальной инженерии (убедить пользователя вставить вредоносный код) и считается малозначимой, низкоуровневой проблемой. В некоторых случаях эксплуатация Self-XSS всё же возможна, вторая ссылка в дополнительных материалах.
Дополнительные материалы
Last updated