Несколько месяцев назад я получил приглашение участвовать в частной программе bug bounty на платформе HackerOne. Сначала я провел свои обычные тесты и обнаружил различные уязвимости, такие как недостаток управления доступом (BAC), утечка авторизационных токенов других пользователей и т.д.
После того как я сообщил об этих уязвимостях программе, я заметил, что XSS считается вне области покрытия согласно их политике. Бизнес программы заключался в том, чтобы предоставлять услуги по созданию систем управления контентом и конструкторов веб-сайтов. При создании аккаунта, пользователи получают уникальный поддомен вида <YOUR-SUB>.target.com, который они могут настраивать.
Учитывая структуру приложения, XSS был ограничен возможностью воздействия только на собственный поддомен, и программа исключила XSS на <YOUR-SUB>.target.com из области покрытия. Это подтолкнуло меня к поиску уязвимости self-XSS и попытке связать ее с другой уязвимостью, чтобы показать более серьезные последствия.
Мне удалось найти несколько цепочек XSS, которые увеличивали ее воздействие. Поскольку на данный момент только одна цепочка была подтверждена, я напишу отчет только о ней. Когда остальные отчеты будут решены, я планирую опубликовать отдельные материалы для каждой из них. Теперь давайте перейдем к самой истории.
Найти self-XSS не заняло много времени.
Теперь настало время найти другую уязвимость, чтобы связать её с XSS. Я начал тестирование веб-сайта с целью выявления багов, которые можно было бы объединить с XSS. Одной из уязвимостей, которую я решил проверить, была неправильная конфигурация CORS. Для тестирования этого я предпочитаю использовать расширение Burp под названием CORS.
Чтобы использовать это расширение, достаточно нажать на флажок "Activate CORS*" и просматривать ваш целевой ресурс, позволяя расширению выполнить свою работу. Оно будет пытаться применить различные техники обхода CORS для всех запросов, проходящих через ваш прокси Burp. Всё, что вам нужно сделать — это проверить результаты.
После активации расширения я обнаружил возможную неправильную настройку CORS в запросе www.target.com/api/me. Этот API-запрос отвечает за получение личной информации пользователей (PII), такой как имя, фамилия, адрес электронной почты и идентификатор учетной записи.
При отправке запроса с заголовком
Origin: 7odamoo-target.comответ был следующим:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: 7odamoo-target.com
Отлично, похоже, я нашел уязвимость. В обычных случаях я должен зарегистрировать домен 7odamoo-target.com и загрузить на него PoC CORS, чтобы продемонстрировать уязвимость. Однако, когда я проверил флаги cookie, я обнаружил, что проблема заключается во флаге SameSite. Браузер не будет включать cookie в запрос, если источник не разрешен.
Я думаю, вы понимаете, что я собираюсь сделать дальше. Я воспользуюсь XSS, который считается вне области действия, чтобы отправить запрос, и в cookie будет включен идентификатор сеанса.
Таким образом, я внедрил следующий скрипт на свой собственный поддомен <MY-SUB>.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();
Отлично, мне удалось успешно связать неправильную настройку CORS с XSS, который считается вне области действия, чтобы обойти проверку источника для cookie с флагом SameSite.
Команда оперативно отреагировала на уязвимость, устранив неправильную настройку CORS. Они больше не разрешают *.target.com читать ответ с www.target.com.
Как было отмечено ранее в статье, после того как оставшиеся цепочки XSS будут решены, я напишу отдельные отчеты по каждой из них.
На этом всё в данном отчете!