Один шаг от пассивной XSS уязвимости до внедрения AJAX червя
Множество раз встречаюсь с мнением что пассивная XSS уязвимость не представляет большой опасности и беспокоиться по этому поводу особо не стоит. И несмотря на то, что отчасти это действительно так(если сравнивать с другими, более катастрофическими ошибками), возможность внедрения своего кода на уязвимый сайт, даже требующая существенных дополнительных действий по обману пользователя может привести к серьёзным последствиям, в частности к возможности полностью перехватить дальнейшие действия пользователя.
Маленькое отступление — если бы существовала возможность получить из браузера код произвольной страницы в сети, проблема безопасности была бы гораздо серьёзнее, к счастью все современные браузеры не позволяют совершать cross-site запросы. Но и это можно обойти, передавая запросы промежуточному приложению находящемуся на том же домене что и страница с червём и выполняющем функцию качалки контента.
В простейшем случае это приложение реализуется в одну строчку на php. Боевой же вариант как минимум должен уметь кешировать скачиваемые данные, чтобы минимизировать возросшее в 2 раза время получения клиентом данных, ну а в совсем идеальном случае — поддерживать приём/передачу cookies, и совершать запросы через набор прокси, чтобы не выдавать себя чересчур часто светя ip в логах.
Даже в таком простейшем варианте мы получаем зараженную страницу позволяющую нам «перемещаться» по сети, фактически оставаясь на одной странице и при желании логируя перемещения пользователя и вводимые им данные. Конечно, если пользователь заметит, что адрес страницы магическим образом остаётся одинаковым или что в строке состоянии постоянно висят запросы к незнакомому домену, он может сразу же забить тревогу, но это мы с вами такие умные, а среднестатистический пользователь вполне может и проигнорировать данный факт.
Хотя такой метод и позволяет сделать много пакостей, он требует слишком много действий для первоначального завлечения человека на страниц ловушку. Не говоря уже о том, что такая страница очень быстро окажется во всевозможных чёрных списках браузеров, А что если страницей-ловушкой окажется чужая, совершенно безопасная на первый взгляд страница со знакомого пользователю домена. Вот тут и вступает в бой возможность внедрить свой код посредством XSS уязвимости на чужом сайте.
Представим себе умного злоумышленника, проводящего фишинг атаку на пользователей банка. Ему не нужно создавать никаких подложных сайтов, достаточно указать в письме ссылку на уязвимую страницу сайта и пользователь уверенный в том, что переходит на доверенный домен, окажется в заражённой зоне. Причём совершенно не обязательно что он увидит перед собой, к примеру, поиск по сайту, яваскрипт позволяет произвольно модифицировать содержимое и значит, перед пользователем может представь индексная или любая другая страница.
Мало того, злоумышленник может полностью избежать использования прослойки для получения данных, ведь запрашиваемые данные в рамках одного домена, а значит могут быть получены прямым AJAX запросом. Или же, злоумышленник может использовать ту же уязвимую страницу, чтобы минимизировать заметность заражения, т.к. при этом будут происходить реальные переходы между страницами, а целевая ссылка может быть закодирована, например как якорь в урле.
И что со всем этим делать.
Не допускать наличие XSS уязвимостей —
С того момента как злоумышленник внедрил свой код в страницу сайта мы уже полностью потеряли контроль, и любые защитные скрипты могут быть вырезаны из кода, а данные вводимые пользователем переданы на сторонний сервер. Единственной полумерой может быть фиксированная страница формы логина и проверяющий рефер и ip адрес отправляющего скрипт логина, таким образом можно не позволить злоумышленнику автоматически пробраться в систему. Что, впрочем, не помешает ему воспользоваться украденными данными самому.
Пожалуйста,
Вход
или
Регистрация
для просмотра содержимого URL-адресов!
*Множество раз встречаюсь с мнением что пассивная XSS уязвимость не представляет большой опасности и беспокоиться по этому поводу особо не стоит. И несмотря на то, что отчасти это действительно так(если сравнивать с другими, более катастрофическими ошибками), возможность внедрения своего кода на уязвимый сайт, даже требующая существенных дополнительных действий по обману пользователя может привести к серьёзным последствиям, в частности к возможности полностью перехватить дальнейшие действия пользователя.
Пожалуйста,
Вход
или
Регистрация
для просмотра содержимого URL-адресов!
Маленькое отступление — если бы существовала возможность получить из браузера код произвольной страницы в сети, проблема безопасности была бы гораздо серьёзнее, к счастью все современные браузеры не позволяют совершать cross-site запросы. Но и это можно обойти, передавая запросы промежуточному приложению находящемуся на том же домене что и страница с червём и выполняющем функцию качалки контента.
В простейшем случае это приложение реализуется в одну строчку на php. Боевой же вариант как минимум должен уметь кешировать скачиваемые данные, чтобы минимизировать возросшее в 2 раза время получения клиентом данных, ну а в совсем идеальном случае — поддерживать приём/передачу cookies, и совершать запросы через набор прокси, чтобы не выдавать себя чересчур часто светя ip в логах.
Даже в таком простейшем варианте мы получаем зараженную страницу позволяющую нам «перемещаться» по сети, фактически оставаясь на одной странице и при желании логируя перемещения пользователя и вводимые им данные. Конечно, если пользователь заметит, что адрес страницы магическим образом остаётся одинаковым или что в строке состоянии постоянно висят запросы к незнакомому домену, он может сразу же забить тревогу, но это мы с вами такие умные, а среднестатистический пользователь вполне может и проигнорировать данный факт.
Хотя такой метод и позволяет сделать много пакостей, он требует слишком много действий для первоначального завлечения человека на страниц ловушку. Не говоря уже о том, что такая страница очень быстро окажется во всевозможных чёрных списках браузеров, А что если страницей-ловушкой окажется чужая, совершенно безопасная на первый взгляд страница со знакомого пользователю домена. Вот тут и вступает в бой возможность внедрить свой код посредством XSS уязвимости на чужом сайте.
Представим себе умного злоумышленника, проводящего фишинг атаку на пользователей банка. Ему не нужно создавать никаких подложных сайтов, достаточно указать в письме ссылку на уязвимую страницу сайта и пользователь уверенный в том, что переходит на доверенный домен, окажется в заражённой зоне. Причём совершенно не обязательно что он увидит перед собой, к примеру, поиск по сайту, яваскрипт позволяет произвольно модифицировать содержимое и значит, перед пользователем может представь индексная или любая другая страница.
Мало того, злоумышленник может полностью избежать использования прослойки для получения данных, ведь запрашиваемые данные в рамках одного домена, а значит могут быть получены прямым AJAX запросом. Или же, злоумышленник может использовать ту же уязвимую страницу, чтобы минимизировать заметность заражения, т.к. при этом будут происходить реальные переходы между страницами, а целевая ссылка может быть закодирована, например как якорь в урле.
И что со всем этим делать.
Не допускать наличие XSS уязвимостей —
Пожалуйста,
Вход
или
Регистрация
для просмотра содержимого URL-адресов!
и автоматическим тестированием, а также использование Пожалуйста,
Вход
или
Регистрация
для просмотра содержимого URL-адресов!
с правильной политикой экранирования данных извне. С того момента как злоумышленник внедрил свой код в страницу сайта мы уже полностью потеряли контроль, и любые защитные скрипты могут быть вырезаны из кода, а данные вводимые пользователем переданы на сторонний сервер. Единственной полумерой может быть фиксированная страница формы логина и проверяющий рефер и ip адрес отправляющего скрипт логина, таким образом можно не позволить злоумышленнику автоматически пробраться в систему. Что, впрочем, не помешает ему воспользоваться украденными данными самому.
