XSS в веб-аппликациях. от 26 Января 2008

Я, конечно, понимаю, что сейчас основным фактором разработки приложений является скорость. Rapid-development, все дела.

Проблема в том, что вместо того, чтобы использовать какое-то средство быстрой разработки, делающее всю защитно-секурную мишуру за разработчика, используются свои наработки многолетней давности. Что приводит к уязвимостям.

Что это и зачем?

XSS – инъекция JavaScript-кода на атакуемый сайт.

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

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

Открытие фреймов

Что значит открытие фреймов? Прежде всего, имитация действий юзера. Открываем фрейм на страничку со списком собственных постов (или на страницу поиска постов по имени автора), для каждого из них открываем форму редактирования, заменяем везде текст каким-нибудь дефейсным контентом, сабмитим формы. Все посты юзера изгажены. Обычные проверки на CSRF тут не покатят, потому проверяльщики просто не отличат редактирование поста эксплойтом от редактирования поста юзером.

Допустим, у вас есть панель управления на сайте. Все настройки, не требующие подтверждения капчей или паролем легко уязвимы. Можно перефразировать так: Любой контент на сайте, видимый юзеру уязвим: Своровать, отредактировать, удалить. То, что позволяет система.

Распространение

Представим, что на сайте есть форум с фильтром HTML. Хакер обошел фильтр и нашел XSS. Чтобы подвергнуть атаке максимальное количество юзеров, он может начать спамить во всех разделах форума и быть быстро спаленным и забаненным. К тому же, чистить посты одного юзера очень просто.

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

Представим простой вариант XSS. выбрасывающий алерт:

<script>
alert('You're screwed');
</script>

Предположим, что мы хотим, чтобы юзеры распространяли этот код, создавая новые темы в форуме с id = 3:

<script id="my_special_xss">
var c = document.createElement('form');
c.method = "POST";
c.action = "/forum/post/"; 
var i = document.createElement('hidden');
i.name = "forum_id";
i.value = 3; //Let's imagine it's the third forum
c.appendChild(i); 
var j = document.createElement('hidden');
j.name = "title";
j.value = "У меня тут появилась одна хорошая мысль";
c.appendChild(j); 
var k = document.createElement('hidden');
k.name = "title";
k.value = 'Ah well nevermind<script id="my_special_xss">' +
document.getElementById('my_special_xss').text + //Обратите внимание, у <script> не innerHTML, а text
'</sc' + 'ript>'; //IE fix
c.appendChild(k);
c.submit();
</script> 

Код создает форму создания нового топика, и прикрепляет к сообщению сам себя1. Можно не создавать новые топики, а редактировать уже существующие. Можно делать проверку, заражена ли уже эта страница (присутствует ли #my_special_xss).

Точно так же можно флудить по всему форуму подставляя рандомные ID топиков в форме ответа. Можно создавать шум, нажимая на кнопку “пожаловаться модератору”. Голосовать за новости (те, кто видел дефейс хабра от 22-го числа, понимают, чем это грозит). В принципе, делать любые действия, не требующие юзер-интерактива.

Использование юзера, как зомби

Как бы это странно ни звучало, но на больших и посещаемых сайтах можно добиться интересных результатов, если делать запросы с браузера юзера на атакуемый ресурс в цикле, создавая эффект DDoS.

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

Впаривание троянов, тулбаров и кодеков.

Широко известен троян, который селится на машине пользователя через дырки в браузерах и заражает все сайты, на которые юзер законнектится по ftp. Действует он точно так же – открывает фрейм на malicious страничку, которая уже и грузит юзеру начинку. Главное здесь – приобрести или самому набрать побольше браузерных багов, как именно – дело самого хакера.

Загрузка скриптов с удаленного сервера

Казалось бы, что особенного? А то, что код может выдаваться каким-нибудь серверным-скриптом, значит поведение эксплойта можно контроллировать удаленно. Допустим, сохранять в базу данных логин текущего юзера (например, выдирать из “Привет, Inviz!” или из куки, если он там лежит) и не грузить юзеру эксплойт больше одного раза.

Доподлинно известно, что с кое-какими XSS-эксплоитами идет админка, в которой можно корректировать векторы атаки.

Заключение

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

Частично, это связано с тем, что лишь немногие на JavaScript программируют, в основном копипастят. Немногие понимают, как работают XSS векторы и что нужно сделать, чтобы их фильтровать. И немногие понимают, чем все это грозит. Хотя бы последний пункт, я постарался осветить.

1 Данный подход называется XSS Worm Replication и на сайте ha.ckers.org совсем недавно проходил контест на самый короткий код червя

---

Комментарии

Комментирование этой статьи закрыто