Чтение JavaScript с ИИ для поиска endpoints

Одностраничное приложение отдаёт свой фронтенд как JavaScript, и в этом коде лежит список endpoints, с которыми приложение говорит. Чтение этих бандлов это одна из самых ценных задач recon для новичка, и это задача на чтение, где помогает модель. Этот пост продолжает настройку toolkit и ведёт к тестированию веб-багов. По более широкому recon статья что такое OSINT объясняет идею, не превращаясь в тьюториал по инструментам.

#Почему JavaScript важен

Браузер обязан знать каждый URL, который он вызывает, поэтому пути, параметры, а иногда фиче-флаги и имена ролей живут в отданном коде. Минифицированный бандл прячет это от человека, читающего на скорости, но строки все на месте. Вытаскивание endpoints из JavaScript часто находит маршруты, на которые нигде в видимом приложении нет ссылок, и именно там прячутся баги контроля доступа.

#Соберите бандлы

Откройте приложение с включёнными dev tools и посмотрите во вкладке network файлы с расширением .js. Сохраните те, что приложение загружает. Файл можно также скачать напрямую, когда у вас есть его URL.

curl -s https://example.com/static/app.min.js -o app.min.js
wc -c app.min.js

Держите файлы в папке заметок по программе. Оставайтесь на хостах, которые перечислены в скоупе; бандл, отданный со стороннего домена, может быть вне скоупа, даже если его загружает приложение в скоупе.

#Прочитайте бандл с моделью

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

grep -oE '"/[a-zA-Z0-9_/-]+"' app.min.js | sort -u > paths.txt

Дайте модели paths.txt и вызовы fetch или axios рядом с ними и попросите сгруппировать пути в вероятные API-маршруты, угадать HTTP-метод и перечислить параметры, которые каждый из них, похоже, принимает. NotHoly CLI может прочитать файл и сделать это в терминале, или вы можете отправить его через API chat completions. Модель превращает стену строк в короткий, проверяемый список.

#От строк к endpoints, которые вы проверяете

Список модели это набор догадок. Каждую догадку вы превращаете в реальный request через свой proxy и смотрите, что возвращается. Путь, который отдаёт 401 без токена и 200 с ним, это живой endpoint, который стоит проверить. Путь, который везде отдаёт 404, может быть мёртвым кодом, оставшимся в бандле. Метод и параметры подтверждайте, отправив request сами, потому что модель вывела их из текста и может ошибиться в обоих.

#Source maps, когда они есть

Некоторые приложения отдают source maps, которые сопоставляют минифицированный бандл с читаемым исходником. Комментарий //# sourceMappingURL= в конце бандла или соответствующий файл .map указывает на него. Когда карта есть и она в скоупе, код становится намного легче читать, и модель может резюмировать для вас целые модули. MDN объясняет source maps. Всё, что вы узнали из них, считайте зацепкой для проверки против работающего приложения, как и раньше.

#Следите, чтобы модель не выдумывала endpoints

Модель, у которой попросили endpoints, иногда выдаёт правдоподобные пути, которых в файле нет, потому что сочинить вероятный путь это ровно та беглая догадка, на которую она заточена. OWASP Top 10 для приложений с LLM относит это к галлюцинациям и чрезмерному доверию. Защитите себя одной привычкой: каждый путь, который вы тестируете, пришёл из строки, на которую вы можете указать в бандле, а каждый метод и параметр подтверждён реальным response. Если модель называет endpoint, который вы не можете найти в файле, выбросьте его.

#Дальше в этой серии

Теперь у вас есть проверенный список endpoints и параметров. Тестирование частых веб-багов с помощью ИИ берёт этот список и проходит по IDOR, XSS, SSRF и сломанной аутентификации. В OWASP Web Security Testing Guide есть полный метод для каждого класса.