XSS в веб-аппликациях

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<scriptt 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>

    Код создаёт форму создания нового топика и прикрепляет к сообщению сам себя (данный подход называется XSS Worm Replication и на сайте ha.ckers.org совсем недавно проходил контест на самый короткий код червя). Можно не создавать новые топики, а редактировать уже существующие. Можно делать проверку, заражена ли уже эта страница (присутствует ли #my_special_xss).

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

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

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

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

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

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

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

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

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

Заключение

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

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

Автор: Ярик Федин.