$350 XSS за 15 минут

Writeup Bug Bounty о DOM XSS через JSONP + загрязнение параметров

Photo by Pepi Stojanovski on Unsplash

Всем привет! Я делюсь с вами своей последней находкой XSS, которую я нашел 2 недели назад. Это был самый быстрый и немного необычный поток, который я обычно использую при поиске XSS.

Итак давайте

• Компания попросила меня повторно протестировать старый отчет XSS.

• Я проверил этот XSS и подтвердил, что он был исправлен правильно.

• Конкретная конечная точка имела name параметр, который был уязвим для внедрения Reflected XSS.

example.com/profile?name=<img+src=1+onerror=alert(1337)>

• Я начал искать обходной путь и использовал функцию поиска в инструментах разработчика Chrome для поиска этой конечной точки /profile во всех файлах JS, чтобы проверить другой уязвимый параметр, но нашел другую конечную точку:

example.com/services

• Первая идея, которая пришла мне в голову, заключалась в том, чтобы поместить этот URL-адрес в поисковую систему Google и посмотреть, была ли эта конечная точка кэширована где-то в веб-пространстве Google с параметрами.

• После первой попытки я нашел кешированную конечную точку с параметрами на первой странице результатов, у конечной точки был параметр ID и некоторые другие параметры.

example.com/services?id=123&page=Demo

Я добавил свою полезную нагрузку qwe'"<X</ в параметр ID и начал проверять, не отражено ли что-нибудь где-нибудь в исходном коде веб-страницы.

example.com/services?id=123qwe'"<X</

• Кроме того, я открыл вкладку Network в Chrome Developer tools, чтобы проверить все запросы, которые эта конечная точка может куда-то отправлять.
• После второго обновления страницы я обнаружил интересный AJAX-запрос, который использовал параметр обратного вызова JSONP вместе с параметром ID из самой конечной точки. URL AJAX-запроса выглядел следующим образом:

lib.com/find?id=123qwe&jsonp=cb12

• Первое, что я протестировал, был сам параметр JSONP, чтобы посмотреть, могу ли я изменить его на функцию alert с пользовательским параметром
• К моему удивлению, не было проверки на значение JSONP, поэтому я легко изменил его на alert(1337);
• Теперь пришло время еще раз проверить параметр ID и посмотреть, принимает ли он другие символы, например, знак %, чтобы создать закодированную полезную нагрузку для добавления пользовательских параметров в AJAX URL.
• Я изменил URL конечной точки на

example.com/services?id=1%26jsonp=alert(1337);%23

• Когда JS обработал его, он трансформировался %26 в & и %23 на #. Все, что находится за символом # (хэштег), игнорируется браузером. Окончательный вызов AJAX выглядит следующим образом:

lib.com/find?id=1&jsonp=alert(1337);#&jsonp=cb12

• Используя эту манипуляцию AJAX URL (атака с подменой параметров), я успешно вызвал окно оповещения с текстом 1337. Это подтвердило существование уязвимости DOM XSS, и я получил вознаграждение в размере $350, а также дополнительные $50 за повторную проверку старого отчета.