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

Zadoxlik (antichat.ru)

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

Ну или что-то вроде этого. А что если в качестве этой самой $_GET['u'] послать 2 символа перевода строки?

http://site1/link.php?u=%0A%0A

Никакого редиректа не произойдет. Снифером (не тем, что ловит куки, а тем, что ловит IP-пакеты) можно посмотреть, что функция схавала наш запрос. Это значит, что все, написанное нами после двух переводов строки %0A, будет телом документа, а значит, мы можем писать там все что угодно. Например: http://site1/link.php?u=%0A%0A%3Cscript%3Ealert(document.cookie)%3C/script%3E

Выведет нам наши куки. Выходит, что это почти такая же обычная пассивная XSS. Ну, примеров еще можно приводить массу. XSS - это вообще тема, которую невозможно полностью исчерпать, так как постоянно придумывается что-то новое. Основную теорию мы прошли. Теперь рассмотрим примеры этих самых XSS, сферы их применения.

Сферы применения

Итак, в один прекрасный день ты зашел в логи своего снифера и обнаружил среди всей этой лабуды куку админа форума, который ты хочешь поиметь. Что же делать дальше? А варианта два. Вариант первый - в куках лежит только номер сессии. Это означает, что, скорее всего, сделать ничего не удастся. Слишком невелик шанс, что сессия не была привязана к IP и что к этому времени файл сессии еще сохранился на сервере. Вариант второй - в куках приплыла исчерпывающая авторизационная информация, которая может быть использована когда угодно. Что с этим добром делать? Сейчас в подавляющем большинстве случаев ключ, на котором завязана вся авторизация, представляет собой md5 слепок от пароля - 32-байтная последовательность шестнадцатеричных цифр вроде 4cac446c545799a99915ee0647af9623. Однако до сих пор встречаются системы, где этот самый ключ - пароль в чистом виде (возмутительно это и потому, что в БД пароль лежит тоже в чистом виде). Что удивляет, одной из таких систем является форум журнала - forum.xakep.ru :). Ну ладно, мы рассматриваем стандартный случай: в куках — хэш. Самое простое - подменить куки. Сделать это можно с помощью встроенной в браузер функции (как например в Opera) или с помощью специальной программы (IECookiesView для Internet Explorer), можно все и руками сделать, но мы отклонились от темы. Итак, после подмены кук мы закрываем браузер (чтобы убить номер сессии на стороне клиента, который браузер передает в куках, ничего нам об этом не сообщая) и заходим в браузер снова. Идем на сайт и видим, что мы авторизированны в аккаунте жертвы. Что можно еще желать? Оказывается, не все так просто... В большинстве современных веб-приложений для выполнения жизненно важных для пользователя или (если жертва - админ) сайта операций с акаунтом скрипт запрашивает у нас пароль. Но мы его не знаем, либо знаем, но молчим. В таких случаях нам могут помочь только другие уязвимости сервиса (например, в организации проверки пароля) или брутофорс хэша. Однако это делать последнее время проблематично — сейчас модно делать этот ключ каким-то кривым способом. Например, так: key=md5(md5(concat(pass,'dw(mO'))). Тем не менее, попытка не пытка. Если вы знаете, что ключ считается подобным образом и знаете сам алгоритм (в случае, например, с бесплатной CMS или форумным движком), то можно написать брутфорс самому. Для других случаев вам поможет MD5 Inside (говорят, в последней версии реализована система задания алгоритма, так что самому писать ничего не придется). Также сейчас стали в ходу онлайн-сервисы поиска хэша.