SS возвращается

Zadoxlik (antichat.ru)

Хакер, номер #092, стр. 092-062-4

КОД

<?

header("Location: http://soft.mail.ru/search_result_header.php?qs=1&words=%22+style%3Dbackground%3Aurl%28javascript%3Aalert%28document.cookie%29%29+%22")

?>

Очень распространены такие XSS в поисковых системах. Перейдем к следующему пункту.

Полуактивные

Данные уязвимости - нечто среднее между пассивными и активными. Фишка вот в чем. Мы заносим в базу данных такие значения, что при подстановке в страницу мы получим уязвимость, при этом адрес будет выглядеть не так, как с GET-пассивными XSS, а как нормальный. С другой стороны, это не активная XSS, поскольку она предполагает внедрение в страницу, которую пользователь посещает редко, а возможно, и не посещает вообще. Так или иначе, но нам придется давать ему ссылку на страницу с уязвимостью, однако здесь извращения с редиректом уже не нужны. Частным случаем полуактивных XSS является XSS через SQL-инъекцию. Давай посмотрим на примере. Допустим, что мы с тобой два злых хакера, которым не хватает денег на покупку банки пива. Итак, мы нашли SQL-injection в интернет-магазине и сбрутили имя таблицы с товарами. Теперь мы можем добавить/отредактировать информацию в этой таблице. Скажем, заменить имя товара в каталоге на JavaScript. Но адрес страницы с товаром получится, например, http://site/catalog.php?id=12753. Вероятность того, что пользователь сам забредет на эту страницу, ничтожно мала. Поэтому надо немного извращаться: допустим, послать письмо особо богатому пользователю магазина — мол, на странице есть форма для получения скидки... Я думаю, ничего сложного тут нет. Любишь экзотику и извращения? Тогда читай дальше. Слабонервных прошу закрыть журнал.

Экзотика

Аксиома: XSS есть везде - даже там, где ее нет. Действительно, это так. Для того чтобы найти XSS, надо лишь немного поработать головой — и найдешь ее в самом неожиданном месте. Если ты мне не веришь - почитай, например, на античате статью про использование UTF-7 в атаках класса XSS: http://antichat.ru/txt/utf7/ (Автор Algol). Можешь себе представить такую ситуацию: админ читает логи сайта, чтобы посмотреть, не проходили ли по нему хацкеры вроде тебя, и тут у него улетают куки к нам на снифер. Конечно, ведь он не подумал, что перед тем, как выводить логи себе на экран, надо бы отфильтровать запросы пользователей. Разве он мог подумать, что в этих самых запросах они могли послать что угодно, в том числе и яваскрипт, который в среде HTML документа, куда выводятся логи, успешно живет и работает, прям как Ленин в шалаше.

Или, например, ты никогда не встречал ссылки вроде http://site1/link.php?u=http://site2 ? Скорее всего, это обычный редиректер. Такие обычно делаются, например, для статистики - сколько кликов было сделано с site1 на сайт site2. Однако даже такая схема может оказаться уязвимой. Фишка в том, что в PHP HTTP-заголовок формируется с помощью функции header(). Для того чтобы браузер перекинул пользователя на другую страницу, заголовок ответа сервера должен содержать строку: Location: <ASDRESS>

Где <ASDRESS> - адрес редиректа. Очевидно, что в нашем примере в коде скрипта есть вот такая строчка: header("Loaction: ".$_GET['u']);