Привет, друзья, сегодня я покажу вам этапы обнаружения уязвимости, с которой я столкнулся в тестах безопасности веб-приложений в моем проекте Saka Reflected XSS (Referer), и эксплуатации этой уязвимости.

Что такое XSS

Вы можете найти подробную информацию об уязвимости XSS в статье ниже.

Запуск приложения

Докер

docker pull erdemstar/saka:reflected-xss-referer
docker run -d -p 80:80 erdemstar/saka:reflected-xss-referer

git clone https://github.com/ErdemStar/Saka
cd reflected-xss-referer
- mouse click on reflected-xss-input.sln
- devenv reflected-xss-input.sln (CMD)

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

Когда мы переходим на страницу атаки, доступны поля имени и сообщения. Когда эти поля заполнены и запрос отправлен, подразумевается, что на странице нет изменений.

Поскольку на стороне пользовательского интерфейса изменений нет, давайте проверим запросы GET и POST и рассмотрим их подробнее.

Понятно, что запрос GET используется для получения страницы атаки напрямую, без получения каких-либо данных от пользователя.

Хотя считается, что запрос POST используется для отправки информации об имени и сообщении, которую он получил от пользователя, при проверке части тела видно, что у него нет такой цели, он только отправляет поле с именем referer в адрес пользователя . бэкенд.

Запрос POST, отправляемый приложению, создается при нажатии кнопки формы на стороне пользовательского интерфейса. Чтобы присмотреться, следует изучить ответ с запросом GET.

При проверке тега <form> ответа, полученного с помощью запроса GET, видно, что части имени и сообщения пусты, а наличие входного именованного реферера и присвоенного ему значения обнаружено.

Было понятно, что причина, по которой элемент ввода не виден из пользовательского интерфейса, связана с настройкой type=hidden .

Посмотрите на GET-запрос, в нем можно проверить, соответствует ли «http://localhost/"значение, присвоенное рефереру в ответе, происходит из запроса следующим образом.

При более внимательном рассмотрении поля Referer в GET-запросе наличие отражения ввода обнаруживается при просмотре ответа.

Было замечено, что тот же результат не получается с запросом POST, который аналогичен запросу, сделанному в запросе GET.

Мысленные заметки

• Приложение не использует информацию об имени и сообщении, полученную от пользователя через форму.
• Когда запрос отправляется в конечную точку /Home/Attack с помощью GET, данные в поле Реферер заголовка соответствующего запроса также отражаются во входных данных реферера в ответе.

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

Когда мы проверяем содержимое входящего ответа, подразумевается, что приложение отражает полученное от нас значение Referer без каких-либо проверок безопасности.

После того, как мы получили так много информации о поведении приложения, когда мы отправляем запрос, подобный приведенному ниже, в поле Referer , мы выполняем сценарий отраженного XSS для приложения.

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

Щелкните здесь, чтобы просмотреть другие мои статьи о веб-уязвимостях. Связь