Продолжим исследования уязвимости 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-инъекции, вообще любых уязвимостей, будут отличаться от сайта к сайту. Поэтому нужно тщательно исследовать веб-страницы, смотреть их исходный код, смотреть как данные передаются между сайтами.
