Ler JavaScript com IA para achar endpoints

Um single-page app entrega o front-end como JavaScript, e esse código guarda a lista de endpoints com que o app conversa. Ler esses bundles é um dos trabalhos de recon de maior valor para quem começa, e é um trabalho de leitura, que é onde um modelo ajuda. Este post segue a montagem do toolkit e alimenta testar bugs web. Para um recon mais amplo, o que é OSINT cobre a ideia sem virar um tutorial de ferramenta.

#Por que o JavaScript importa

O browser precisa conhecer cada URL que chama, então os paths, os parâmetros e às vezes feature flags e nomes de papel ficam no código entregue. Um bundle minificado esconde isso de um humano lendo rápido, mas as strings estão todas ali. Tirar endpoints do JavaScript muitas vezes encontra rotas que não estão linkadas em lugar nenhum do app visível, que é justo onde se escondem bugs de controle de acesso.

#Colete os bundles

Carregue o app com as dev tools abertas e olhe a aba de rede por arquivos terminados em .js. Salve os que o app carrega. Você também pode baixar um arquivo direto quando tiver a URL dele.

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

Guarde os arquivos no seu diretório de notas do programa. Fique nos hosts que o escopo lista; um bundle servido de um domínio de terceiro pode estar fora do escopo mesmo quando o app no escopo o carrega.

#Leia um bundle com o modelo

Um bundle minificado é grande e barulhento demais para colar inteiro na maioria dos chats. Puxe antes as strings interessantes, depois peça ao modelo para dar sentido a elas.

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

Dê ao modelo o paths.txt e as chamadas fetch ou axios perto delas, e peça para agrupar os paths em rotas de API prováveis, chutar o método HTTP e listar os parâmetros que cada uma parece receber. A CLI da NotHoly consegue ler o arquivo e fazer isso no terminal, ou você pode mandar pela API de chat completions. O modelo transforma um paredão de strings em uma lista curta e testável.

#De strings para endpoints que você confere

A lista do modelo é um conjunto de chutes. Você transforma cada chute em um request real pelo seu proxy e observa o que volta. Um path que retorna 401 sem token e 200 com um é um endpoint vivo que vale testar. Um path que dá 404 em todo lugar pode ser código morto deixado no bundle. Confirme o método e os parâmetros enviando o request você mesmo, porque o modelo os inferiu do texto e pode errar os dois.

#Source maps quando existem

Alguns apps entregam source maps, que mapeiam o bundle minificado de volta para um código legível. Um comentário //# sourceMappingURL= no fim de um bundle ou um arquivo .map correspondente aponta para um. Quando um map está presente e no escopo, ele deixa o código muito mais fácil de ler, e o modelo consegue resumir módulos inteiros para você. A MDN explica source maps. Trate qualquer coisa que você aprende deles como uma pista a conferir contra o app rodando, como antes.

#Cuidado com o modelo inventando endpoints

Um modelo a quem se pede endpoints às vezes produz uns plausíveis que não estão no arquivo, porque inventar um path de cara provável é justo o tipo de chute fluente que ele foi feito para dar. O OWASP Top 10 para Aplicações de LLM lista isso sob alucinação e excesso de confiança. Proteja-se com um hábito: todo path que você testa veio de uma string que você consegue apontar no bundle, e todo método e parâmetro é confirmado por uma response real. Se o modelo nomeia um endpoint que você não acha no arquivo, descarte.

#A seguir nesta trilha

Agora você tem uma lista conferida de endpoints e parâmetros. Testar bugs web comuns com ajuda de IA pega essa lista e passa por IDOR, XSS, SSRF e auth quebrada. O OWASP Web Security Testing Guide tem o método completo para cada classe.