[Перевод] Как я получил $5000 за Out-of-Scope XSS27.10.2024 08:30

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

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

Учитывая структуру приложения, XSS был ограничен возможностью воздействия только на собственный поддомен, и программа исключила XSS на .target.com из области покрытия. Это подтолкнуло меня к поиску уязвимости self-XSS и попытке связать ее с другой уязвимостью, чтобы показать более серьезные последствия.

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

Найти self-XSS не заняло много времени.

f5984c64f0e8daece945b7d9b8e66ce3.png

Теперь настало время найти другую уязвимость, чтобы связать её с XSS. Я начал тестирование веб-сайта с целью выявления багов, которые можно было бы объединить с XSS. Одной из уязвимостей, которую я решил проверить, была неправильная конфигурация CORS. Для тестирования этого я предпочитаю использовать расширение Burp под названием CORS.

b80d9c62136e4667703728395bbae71c.png

Чтобы использовать это расширение, достаточно нажать на флажок «Activate CORS*» и просматривать ваш целевой ресурс, позволяя расширению выполнить свою работу. Оно будет пытаться применить различные техники обхода CORS для всех запросов, проходящих через ваш прокси Burp. Всё, что вам нужно сделать — это проверить результаты.

f42c01d6a0213c791d438d27dc48bbc7.png

После активации расширения я обнаружил возможную неправильную настройку CORS в запросе www.target.com/api/me. Этот API-запрос отвечает за получение личной информации пользователей (PII), такой как имя, фамилия, адрес электронной почты и идентификатор учетной записи.

При отправке запроса с заголовком

Origin: 7odamoo-target.com

ответ был следующим: 

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: 7odamoo-target.com

8eabc7f3f2496c25eab038e068ee0ad2.png

Отлично, похоже, я нашел уязвимость. В обычных случаях я должен зарегистрировать домен 7odamoo-target.com и загрузить на него PoC CORS, чтобы продемонстрировать уязвимость. Однако, когда я проверил флаги cookie, я обнаружил, что проблема заключается во флаге SameSite. Браузер не будет включать cookie в запрос, если источник не разрешен.

Я думаю, вы понимаете, что я собираюсь сделать дальше. Я воспользуюсь XSS, который считается вне области действия, чтобы отправить запрос, и в cookie будет включен идентификатор сеанса.

Таким образом, я внедрил следующий скрипт на свой собственный поддомен .target.com, чтобы, когда кто-либо посещал мой поддомен, был отправлен запрос к www.target.com/api/me, и его личная информация будет отображена в всплывающем окне alert как PoC: 

function cors() {
  var xhttp = new XMLHttpRequest();
  xhttp.onreadystatechange = function() {
      if (this.readyState == 4 && this.status == 200) {
            document.getElementById("demo").innerHTML = alert(this.responseText);
      }
  };
  xhttp.onload = cors;
  xhttp.open("GET", "https://www.target.com/api/me", true);
  xhttp.withCredentials = true;  xhttp.send();
}
cors();

Обход флага SameSite Cookie с использованием Self XSS

Обход флага SameSite Cookie с использованием Self XSS

Отлично, мне удалось успешно связать неправильную настройку CORS с XSS, который считается вне области действия, чтобы обойти проверку источника для cookie с флагом SameSite.

Команда оперативно отреагировала на уязвимость, устранив неправильную настройку CORS. Они больше не разрешают *.target.com читать ответ с www.target.com.

Исправление неправильной настройки CORS

Исправление неправильной настройки CORS

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

На этом всё в данном отчете!

Мой тг канал.

© Habrahabr.ru