Продолжим исследования уязвимости Reflected XSS. Cмысл предыдущих инъекций заключалась в том, что мы вставляли их в код HTML. Вспомните запись вида: «<script>alert(«Reflected XSS»)</script>». Ее можно видоизменить различными способами, к примеру используя cheet sheet.

На самом деле подходы к обнаружению уязвимости XSS довольно обширны, и нет какого-либо общего вектора для исследования. Вам просто нужно пытаться найти уязвимости, исходя из особенностей веб-страницы. Для рассмотрения следующего примера, мне понадобится веб-приложение Metasploitable 2, которое называется «Mutillidae» нам в меню выбрать следующие опции: «OWASP Top 10» — «A1 — Injection» — «JavaScript Injection» — «Password Generator»:

Эта страница представляет собой генератор паролей. Мы можем нажать на кнопку «Generate»:

В итоге мы получили сгенерированный пароль. Можно шаги по генерации проделывать снова и снова. Если мы детально рассмотрим вывод на странице, то обнаружим, что данный пароль был сгенерирован для пользователя «Anonymous»:

Теперь перейдем в URL веб-страницы, и заметим, что в параметре указано имя «Anonymous»:

Мы можем изменить этот параметр, на любое другое имя. Возьму, к примеру «Timcore»:

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

Давайте попытаемся сделать инъекцию в код данной веб-страницы, посредством уже известного нами скрипта: «<script>alert(«Reflected XSS»)</script>», в URL:

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

Давайте исследуем элемент кода, который вывелся на странице, с помощью инспектора кода. Наводим курсор мыши на код, и жмем правую кнопку мыши, и выбираем «Inspected Element»:

Мы перемещаемся на открывающий и закрывающий теги «blockqoute».

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

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

Обратите внимание на код, в скрипте нет закрывающего тега <script>:

Еще можно обнаружить в записи одну кавычку:

Нам просто необходимо закрыть кавычку еще одним символом. Запись примет вид: «“ alert(„Reflected XSS“)». Это нужно для того, чтобы была запись функции в чистом виде, без лишних символов.

Давайте окинем взглядом наш код на JavaScript. Вначале у нас идет первая строка кода: «document.getElementById». Для того, чтобы эксплуатировать эту уязвимость, на обязательно быть программистом JavaScript. Вам нужно понимать, как все работает.

Нас интересует InnerHTML, с дальнейшей записью, которую мы пытаемся закрыть дополнительной кавычкой, убрав тег script. В языке программирования JavaScript, для того, чтобы завершить строку, необходимо вставить символ точка с запятой «;». Смотрите, что мы делаем. Логика заключается в том, чтобы закрыть первую строку, которая завершается вставленной нами кавычкой. Запись примет вид „ ;alert(„Reflected XSS“). Как Вы уже догадались, нам нужно добавить дополнительный символ «;», в конец второй строки. Это будет выглядеть как: „ ;alert(„Reflected XSS“);.

Давайте попробуем ввести наш преобразованный код в строку URL:

Как видим, ничего не произошло. Нам нужно просмотреть исходный код страницы вновь. Жмем кнопку «Generate», и далее переходим в инспектор элементов. Получаем вывод следующего кода:

Обратите внимание на запись после innerHTML. Наша закрывающая кавычка на месте, и в целом запись идет по нашему сценарию, вплоть до закрытия кода, с помощью символов «“;». Это все жестко прописано в коде, но мы можем воспользоваться методом, который применяется при SQL-инъекциях, а именно методом комментирования. Комментарии имеют вид двух прямых слэшей: «//». Вставляем их в наш код: «„ ;alert(„Reflected XSS“);//», и копируем в адресную строку браузера:

Наш код запустился, и мы смогли проэксплуатировать эту уязвимость.

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

#1 Что такое уязвимость XSS (Cross Site Scripting)? Типы XSS.

#2 Исследование Reflected XSS (уровень Low).

#3 Исследование Reflected XSS — Средний уровень.