Кейс с Json XSS
MoodyПривет, народ!
Этот пост об одной из моих недавних находок в программе баг-баунти.
Все началось с того, что я начал проверить веб-приложение на наличие распространенных уязвимостей, но потратив час, ничего не нашел, кроме одного интересного эндпоинта, выглядящего следующим образом:
Если посмотреть на тело запроса и ответ от сервера, можно заметить закономерность - значение параметра "status" отображается в ответе. Чтобы опровергнуть или подтвердить это предположение, я решил попробовать вставить свою строку в качестве этого параметра и посмотреть, отобразится ли она.
Что дальше? Давайте проверим наличия XSS при помощи простого пейлоада:
Как вы видите, угловые скобки фильтруются. Попробовав поменять несколько кодировок, я убедился в том, что проблема (для нас) по-прежнему есть. Я, было, решил сдаться, как вдруг вспомнил об одном трюке с массивами.
Как вы можете видеть, все что я написал в скобках, отобразилось в ответе следующим образом
Status - JSON Object
<haha> - ключ JSON Object
Test - значение ключа <haha> JSON Object
Давайте еще раз проверим XSS с простой полезной нагрузкой:
Теперь мы уверены в том, что угловые скобки работают на нас. Но что, если мы применим вставим здесь символ "="?
Это сломает запрос и мы получим нулевое значение. Подправим пэйлоад, закодировав предыдущий символ при помощи Url Encode:
Последний штрих - генерируем финальный пэйлоад
И POC CSRF, чтобы использовать его.
Единственная проблема в том, что параметр "userId" было невозможно угадать - я проверил еще несколько эндпоинтов, чтобы попробовать заполучить его, но не добился успеха и сообщил об этой уязвимости "как есть". Разработчики быстро исправили её. Кроме того, это не единственное место, где использовался JSON на сайте - каждый эндпоинт был уязвим.
Статья доступна в оригинале на английском языке - читать.
Cybred - канал об информационной безопасности и конкурентной разведке, вдохновленный идеями олдскульных андеграундных интернет-сообществ о свободе распространения информации в сети и всеобщей взаимопомощи.