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

XSS? Зачем матом ругаться?

Хотя я и сказал, что статья подытоживает все, что было сказано об XSS, но давай вернемся на землю. Кто знает, вдруг решишь высосать уязвимость там, где ее нет? Всякое бывает. Вот тогда надо будет уже подробно читать (или находить самому) о реализации JS, VBS (и внедрения их в HTML) для каждого отдельного браузера. Однако не расстраивайся заранее — огорчений не будет. Итак, сказал сначала, значит, сначала. Сядь за парту, лекция началась. Первый вопрос: XSS - что это за зверь и с чем его едят? Зверюга эта расшифровывается как Cross Site Scripting (межсайтовый скриптинг). Напрашивается вопрос - почему не CSS? Об этом можно только гадать, но есть устоявшееся мнение о том, что, дескать, если бы его называли CSS, то люди бы путали его с Cascade Style Sheets (каскадные таблицы стилей), что к XSS имеет непосредственное отношение. А заменить первую «C» решили буквой «X», поскольку Cross переводится с английского как «крест», а «Х», согласись, очень даже этот самый крест и напоминает (если пофантазировать).

Функционально межсайтовый скриптинг - это взаимодействие взломщика с пользователем средствами веб-приложения, которым пользуется жертва. То есть взломщик находит в системе возможность внедрения своего HTML'ного кода в страницу, которая будет показана пользователю. А что можно с этим сделать? Если интересно, то отложи мяч в сторону — футбол будет потом — и читай дальше.

Вкусное печенье и тяжелая сессия

Итак, давай действовать и думать вместе. Представим, что мы получили каким-то образом доступ к редактированию HTML-кода страницы, которую посетил пользователь. И не просто какой-то страницы, вроде нашего хомячка, а страницы, принадлежащей сайту, на котором у вышеупомянутого заведен аккаунт. Это значит, что в базе данных сайта хранится логин, пароль и еще кое-какая информация о пользователе. И нам бы, конечно же, хотелось бы получить эту информацию. Давай поэтапно разберем авторизацию пользователя на сайте. Он заходит, вбивает в форму логин и пароль и проходит к себе в личный кабинет/форум/чат и т.д. Фактически в момент авторизации происходит следующее: браузер юзера формирует запрос к серверу, в котором отсылает свой логин и пароль. Сервер принимает этот запрос, вынимает из него вышеуказанные данные и проверяет, есть ли в базе данных такой паренек. На основе этого либо посылает его в Тибет к монахам, либо отвечает, что все хорошо. В ответе, так или иначе, содержится нечто, что будет в дальнейшем отправлять пользователя на сервер, чтобы убедить последнего в том, что он — это именно он, а не какой-нибудь дядя Вася с третьего подъезда, и что авторизироваться ему дальше не обязательно, а достаточно посылать только это что-то. Что же это за мистическое «что-то»? В современных веб-приложениях возможны только 2 варианта (левые скрипты от Васи Пупкина мы не рассматриваем): либо куки, либо номер сессии. Не пугайся сразу, сейчас все объясню. Давай не будем кричать, что все знают про Куки. 80% опрошенных, которые сказали, что знают, выдают ответ порядка «это вот такая типа вещь, где типа такие вот личные данные, гы». Мы же с тобой интеллигентные люди — должны уметь оперировать терминами. Куки (Cookie - печеньки) - это параметры, передаваемые скрипту, равносильные параметрам, передаваемым в POST- или GET-запросе. То есть все, что нас идентифицирует, хранится у нас же самих. А это дает нам возможность не только ходить под своим логином по сайту, но и выйти с него и прийти на следующий день также. Второй вариант - номер сессии. Сессия - это такая хитрая штука. Это вовсе не то, что ты завалил зимой :). Вся информация из сессии хранится на сервере в папке временных файлов. Сессии характеризуются двумя свойствами - срок жизни и привязка к IP. Это нам еще пригодится. В случае с такой авторизацией — не может сделать так, чтобы, зайдя на следующий день на сайт, ему бы не пришлось снова логиниться. Все просто - у сессии маленький срок жизни, и к этому времени на сервере уже не останется файла для нее. Чаще всего номер передается все в тех же куках, как отдельный параметр. Но ничего не мешает передать его через GET, как, например, http://site/?SID=SESSION_NUMBER.
А в чем, собственно, прелесть? А прелесть в том, что средствами JavaScript или VBScript мы можем получить куки пользователя для данного домена, на сайте которого находится документ. В JavaScript куки хранятся в document.cookie. Все что нам надо, так это сформировать запрос пользователя к нашему сниферу, в котором бы мы отправили свои куки. Снифер в терминологии XSS - это наш скрипт, который ловит все добро, которое передается ему в GET-запросе. Вот простейший пример снифера на PHP, его ты уже знаешь наизусть, но мы отважимся привести его еще раз, так сказать, для отчетности:

КОД

if(strlen($QUERY_STRING)<2)exit;

header("Content-Type: image/png");

$im=ImageCreate(1, 1);

ImagePNG($im);

imagedestroy($im);

$fp=fopen("sniff.txt", "a");

fputs($fp,$QUERY_STRING."\n\n");

fclose($fp);

?>

А вот простенький пример того, как можно отправить куки на этот снифер. Предполагается, что на странице есть картинка. Если нет - нужно будет объявить:

КОД

Теперь перейдем к плохим делам.

XSS бывают разные

XSS можно разделить на подклассы. Я бы выделил следующую структуру:

1)Активные. Активные XXS'ски - самые опасные из возможных XSS. Например, решил Василий Пупкин проверить свою почту на мэйл.ру через веб-интерфейс, и, вроде бы, все хорошо у него прошло. Увидел он письмо от своей любимой девушки, а в это время наш снифер принимает пароль негодующего Василия. И тогда, облачившись во все черное, под покровом ночи, начинаешь ты писать всякие непристойные вещи... впрочем, не будем об этом. Короче говоря, активные XSS - это XSS там, где ты их меньше всего ожидаешь, точнее в твоем пользовательском интерфейсе. Там, куда ты заходил каждый раз, ничего не опасаясь, чтобы почитать посты на форуме или почту на своем e-mail, а тут... какая подлость - чужой код. И ничего с ним не поделаешь. Нет, конечно, можно отключить выполнение скриптов на странице в своем браузере, но кто, кроме нас, с тобой так делает? Явно не Василий Васильевич.
Пассивные

Пассивные XSS - это уязвимости в динамической части сайта. Это уже проще матрицы и ненадежнее. Не надо быть избранным, чтобы повестись на нее. XSS получается только при данном конкретном запросе к скрипту. Единственное — необходимо, чтобы скрипт выводил тебе что-то, что ты задаешь в своем запросе. Пожалуй, это самые неудобные уязвимости для осуществления атаки. Пассивные XSS делятся на уязвимости в скриптах, параметры к которым передаются через GET и через POST. Через POST - это вообще самое большое извращение, которое только можно представить. Для того чтобы пользователь попался в ловушку с GET-пассивной XSS, ему достаточно дать ссылку на страницу, которая сгенерирует JS-код. А вот для того, чтобы пользователь попался на POST-пассивную XSS, мы должны будем создать отдельный сайт, на котором поместим форму динамической отправки с необходимыми нам полями. Что за страшные слова я говорю? Давай разберем пример. Вот пример GET-пассивной XSS можно встретить на http://soft.mail.ru/.

Вводим в поиск «aaaa», жмем Enter. Смотрим. На странице образовалось несколько тэгов , в которые вошел наш запрос, подставленный в параметр value этого тэга и взятый в двойные кавычки. Попробуем выйти. Для этого введем в поиск вот такой запрос: " style=background:url(javascript:alert(document.cookie)) "

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

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

А теперь представь, что бы было, если б параметр «words» передавался скрипту через POST? Чтобы сформировать POST-запрос, надо сделать страницу с формой, в поля которой будет занесен необходимый нам запрос, а затем сделать JavaScript'ом автоотправку формы. И уже на эту страницу давать ссылку своей жертве. Вот простой пример (если бы в данном случае параметр принимался бы через POST):

КОД

Чтобы пользователь ничего не заподозрил, мы можем делать подобный редирект и с GET-пассивными уязвимостями. Более того! Можно делать это на уровне HTTP, например, с помощью такого PHP-скрита:
КОД

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:

Где - адрес редиректа. Очевидно, что в нашем примере в коде скрипта есть вот такая строчка: header("Loaction: ".$_GET['u']);
Ну или что-то вроде этого. А что если в качестве этой самой $_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 (говорят, в последней версии реализована система задания алгоритма, так что самому писать ничего не придется). Также сейчас стали в ходу онлайн-сервисы поиска хэша.
Изврат продолжается

Это было классическое применение XSS. Рассмотрим что-то более изощренное.

Без всяких уязвимостей на портале мы всегда можем сделать одну интересную вещь. А именно: поменять все настройки пользователя, которые не требуют пароля. Иногда - это подпись на форуме, ася, статус, емэйл (реже), а иногда даже пароль. Делается это очень просто. В любом веб-приложении есть контрольная панель юзера с формочкой, запрос в которую меняет необходимые настройки. В зависимости от того, понимает скрипт GET-запрос или только POST, мы можем сделать ссылку на свой скрипт редактирования профайла или соответствующую страницу с формой метода пост (как было показано на POST-пассивных XSS), где укажем соответствующие параметры. Единственная проблема - проверка поля Referer (адрес, с которого пришли) HTTP-запроса. Однако давай это оставим за гранью. Таким макаром, например, можно спокойно иметь админ панель форума exBB. Примерно таким же способом осуществляется угон всей почты и установка переадресации на всю входящую на популярнейших российских и буржуйских почтовиках (да-да, это те, о которых вы подумали). Вкратце технологию можно описать так:

1. Пользователь открывает страницу с XSS.

2. XSS подгружает в браузер пользователя (например, с помощью тэга ) наш скрипт, передавая ему куки и REFERER (реферера браузер передаст сам).

3. Из реферера скрипт получает номер сессии. На основе этого номера сессии он формирует заголовок переадресации на страницу настроек почтовика (браузер сам перекидывает юзера на эту пагу, получив от нашего скрипта заголовок Location), указывая в параметре «привязать сессию к IP» FALSE.

4. После этого у нашего скрипта развязаны руки, он открывает соединения с сервером и формирует последовательность HTTP-запросов (с использованием полученного номера сессии и кук), с помощью которых сливает всю почту, лежащую на ящике жертвы, и устанавливает переадресацию с сохранением локальной копии на все входящие (делается обычно с помощью фильтров). Этот (или очень на него похожий) сценарий сейчас прокатывает практически везде (не является исключением яндекс, мэил.ру, емэйл.ру, почта.ру, рамблер и все осталеные). Такой скрипт обеспечивает результативную работу с жертвой, даже если авторизация на сервере проходит только по сессии. В терминологии XSS он называется функциональным снифером, про который в журнале писали тоже не раз. Еще одна область применения XSS, как ни странно, - дефейс. Вообще, это используется очень редко. Я не замечал, чтобы это кто-то использовал, поэтому мы рассмотрим примеры из того, что происходило с моим участием. Итак, а что же может сделать JavaScript. Оказывается, он в состоянии переписать тело документа! А это - то, что нам надо. Хотя, что я пытаюсь рассказать, ты же читал про дефейс хакер.ру? Ну вот, это было сделано как раз с помощью замещения новости на главной странице (через SQL-инъекцию) примерно вот таким кодом:
КОД

Можно организовать временный дефейс сайтов, которые выводят последние запросы в их поисковике или с поисковиков (ya.ru, rambler, google и т.д.) к ним. Я думаю, все понятно, в чем тут фишка. Если надо, чтобы дефейс не спадал, обычно делают бота, который регулярно отправляет соответствующий запрос с подделанным реферером. Минус такого дефейса состоит в том, что он не будет действовать у тех, у кого отключен жабаскрипт, или, если ты напишешь криво сам дефейс-код, он может сработать далеко не в каждом браузере.

Итоги

Ну и напоследок. Если ты хочешь впарить кому-нибудь трояна, запустить на компе жертвы биндшел или просто сделать какую-нибудь нехорошую вещь, то тебе, возможно, помогут эксплоиты против браузера жертвы. Наверняка он не каждый день обновляет «смотрелку». Вообще, XSS здесь несколько притянут за уши, но все же, если дать ему ссылку на rambler.ru, где через XSS на страницу будет внедрен эксплоит, пользователь нажмет туда с большим доверием, чем на ссылку на сайт Васи Пупкина. Итак, XSS сегодня — это класс уязвимостей, которые достаточно несложно реализовать, еще проще их использовать, а встретить можно повсеместно.

WWW

http://www.web-hack.ru/download/download.php?go=78 - IECookiesView

http://zloy.org/downloads/md5inside_1_0.rar - MD5 Inside

http://ivdb.org/search/md5/ - пример онлайн-поисковика хэшей

WARNING

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

Источник: http://www.xakep.ru