Каковы возможные векторы атак для отраженного межсайтового скриптинга?
Википедия предоставляет информацию об одном из наиболее распространенных сценариев для использования отраженной атаки межсайтового скриптинга - использование некоторой степени социальной инженерии, чтобы побудить ничего не подозревающих пользователей нажимать вредоносную ссылку:
- Алиса часто посещает конкретный веб-сайт, который размещен Бобом. Боб веб-сайт позволяет Алисе войти с пара логин / пароль и магазины конфиденциальные данные, такие как выставление счетов информация.
- Мэллори отмечает, что веб-сайт Боба содержит отраженный XSS
- Мэллори создает URL-адрес для использования уязвимости и отправляет Алисе электронная почта, заманивая ее, чтобы нажать на ссылку для URL под ложными предлогами. Этот URL будет указывать на сайт Боба, но будет содержать зло Мэллори код, который будет отображаться на сайте.
- Алиса посещает URL, предоставленный Мэллори, во время входа в систему Боба. веб-сайт.
- Вредоносный скрипт, встроенный в URL, выполняется в браузере Алисы, как будто это пришло прямо от Боба сервер (это фактический XSS уязвимость). Скрипт можно использовать отправить сессионный кукис Алисы Мэллори. Мэллори может затем использовать сессионный cookie для кражи информация, доступная Алисе (учетные данные аутентификации, биллинг информация и т. д.) без ведома Алисы.
Теперь, как правило, это очень хороший пример, когда веб-сайт является приложением, управляемым страницей - уязвимость используется, когда пользователь отправляет вредоносную полезную нагрузку на сервер. приложения (что более важно, путем выдачи запроса GET при входе в систему), что отражается в ответе.
Есть ли более интересные векторы атак, особенно те, которые следует учитывать, когда приложение использует много AJAX с большинством запросов делается через HTTP POST?
РЕДАКТИРОВАТЬ
В случае, если мне неясно, я хотел бы знать различные типы векторов атак, применимых к отраженным атакам XSS, особенно когда уровень приложения на стороне клиента реализован по-разному. Приложения на основе страниц будут иметь вектор атаки, включающий запросы HTTP GET, выданные пользователем, но было бы интересно узнать, как это работает для приложений толстого клиента, особенно тех, которые используют объекты XMLHttpRequest, которые выдают запросы HTTP POST. Разные механизмы, используемые при рендеринге на стороне клиента, очевидно, требуют изучения различных векторов атак. В некоторых случаях могут отсутствовать применимые векторы атаки; вопрос выражен, чтобы вызвать такой ответ.
3 ответа
Да, на самом деле существует несколько вариантов отражающей XSS-атаки. Наиболее заметной является червь Samy. Вкратце, Samy использовал XSS для отправки XHR на MySpace.com, чтобы прочитать CSRF-токен и подделать POST-запрос. На самом деле это общий шаблон атаки, который полезен для атак на сайты, использующие httponly cookies. По мере того, как использование куки httponly становится все более популярным, будет развиваться и эта схема атаки.
Другой полезной нагрузкой xss является XSS Shell. Она предоставляет атакующему интерактивный канал доступа к браузеру.
XSS используется для проведения атаки "Drive-By-Download".
Xss также может быть использован для подделки новостей. Поскольку xss против источников новостей регулярно обнаруживаются, это довольно серьезная проблема.
Edit: Вам также может быть интересно, как фонд Apache получил собственность, используя xss и tinyurl. Вот эксплойт, который я написал и который использует атаку в стиле Samy для получения CSRF.
Отраженный XSS возникает, когда страница отображает вредоносный пользовательский ввод. Поэтому вопрос "какие существуют векторы атаки?" синонимичен вопросу "какой пользовательский ввод может получить страница?"
Некоторые источники:
- строка запроса GET, которая может исходить от:
- URL в электронном письме
- перенаправление (через js, 301 ответ или метатег) со взломанного или вредоносного сайта
- Тело POST-запроса, которое может исходить от:
- AJAX POST запрос с любого домена (Same Origin Policy не останавливает запрос, только разбирает ответ)
- Любая форма с method="POST" и action="XSSed_site.com". Формы могут быть размещены через js, или нажатием на кнопку, что может быть сделано с помощью click-jacking.
- Другие формы ввода, такие как:
- внешние js файлы, такие как сортировщики таблиц или библиотеки, которые использует атакуемая страница
- межсерверная связь, которая отображается на атакуемой странице
- любые другие данные, отображаемые на атакуемой странице, которые могут быть изменены злоумышленником
Я понимаю, что раздел "Другие формы ввода" больше похож на хранимую XSS уязвимость, но каждое приложение уникально, и некоторые могут преобразовывать пользовательский ввод в то, как внешние части компонуются в страницу (следовательно, отражаются).
Строка запроса в GET-запросе из поддельного письма, конечно, не единственный вектор для отраженного XSS (хороший вопрос, однако).
Бенбруссар уже касался этого, но я хочу повторить это из-за важности. Толстый клиент, тонкий клиент, POST, GET, PUT; ни одна из этих вещей не имеет значения. Дыра XSS основана на том, что сайт неправильно отображает некоторые данные кому-то.
Если вы ищете строго отраженную атаку, полезная нагрузка не должна храниться нигде в целевом приложении. В этом случае я думаю, что вы правы в том, что толстый клиент будет более устойчивым, потому что GET — это самый простой способ инициировать отраженную атаку XSS.
Что касается других векторов атак, одна интересная вещь в архитектуре толстого клиента — это кодирование сущностей. Тонкий клиент может закодировать все, что угодно, и покончить с этим с большой выгодой. Толстый клиент должен сущностью кодировать ответ на начальный GET, но асинхронные запросы с ответами, направленными на JavaScript, не могут быть (полностью) закодированы и быть допустимыми JS. Это взад-вперед увеличивает шанс не закодировать то, что должно быть, что является большим шагом к созданию вектора XSS.
Есть смысл?
Карл