Как использовать уязвимость HTTP-заголовка XSS?

Question

Предположим, что страница просто печатает значение заголовка HTTP 'referer' без экранирования. Таким образом, страница уязвима для атаки XSS, то есть злоумышленник может обработать запрос GET с заголовком референта, содержащим что-то вроде <script>alert('xss');</script>.

Но как вы можете использовать это для атаки цели? Как злоумышленник может сделать целевую проблему конкретным запросом с этим конкретным заголовком?

Answer 1

Это звучит как стандарт reflected XSS attack.

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

В случае отраженной атаки XSS с заголовком referer, злоумышленник может перенаправить пользователя с форума на страницу в домене злоумышленника.

например.

http://evil.example.com/?<script>alert(123)> 

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

http://victim.example.org/vulnerable_xss_page.php 

Потому что он показывает referer заголовок на этой странице без надлежащего экранирования, http://evil.example.com/?<script>alert(123)> получает выход в источнике HTML, выполняя предупреждение. Обратите внимание, что это работает только в Internet Explorer.

Другие браузеры будут автоматически кодировать URL рендеринга

%3cscript%3ealert%28123%29%3c/script%3e 

вместо который является безопасным.

Answer 2

Я могу придумать несколько различных атак, может быть, есть и другие, которые, как мы надеемся, добавят другие. :)

Если ваш XSS - это просто какое-то значение заголовка, отраженное в ответе unencoded, я бы сказал, что это меньше риска по сравнению с сохраненным. Однако могут быть факторы, которые следует учитывать. Например, если это заголовок, который браузер добавляет и может быть установлен в браузере (например, пользовательский агент), злоумышленник может получить доступ к клиентскому компьютеру, изменить агент пользователя, а затем позволить обычным пользователям использовать веб-сайт, теперь с помощью javascript атакующего. Еще один пример, который приходит на ум, - это веб-сайт, на котором может отображаться URL-адрес, который перенаправил вас туда (референт) - в этом случае злоумышленник должен только ссылаться на уязвимое приложение из своего тщательно продуманного URL-адреса. Однако это кросс-кейсы.

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

Cache poisoning также может помочь с использованием заголовка XSS.

Еще одна вещь, о которой я могу думать, - это плагины для браузера. Flash сейчас слабее (к счастью), но с разными версиями Flash вы можете установить разные запросы в своих запросах. What exactly you can and cannot set - беспорядок и очень запутывает версии Flash-плагина.

Таким образом, существует несколько атак, и необходимо обрабатывать все заголовки как пользовательский ввод и соответственно кодировать их.