Leer JavaScript con IA para hallar endpoints

Una single-page app entrega su front end como JavaScript, y ese código guarda la lista de endpoints con los que habla la app. Leer esos bundles es uno de los trabajos de recon de más valor para un principiante, y es un trabajo de lectura, que es donde ayuda un modelo. Este post sigue a el armado del toolkit y alimenta probar bugs web. Para un recon más amplio, qué es OSINT cubre la idea sin volverse un tutorial de herramientas.

#Por qué importa el JavaScript

El navegador tiene que conocer cada URL que llama, así que las rutas, los parámetros y a veces los feature flags y los nombres de rol viven en el código entregado. Un bundle minificado esconde esto de un humano que lee rápido, pero los strings están todos ahí. Sacar endpoints del JavaScript suele encontrar rutas que no están enlazadas en ninguna parte de la app visible, que es justo donde se esconden los bugs de control de acceso.

#Reúne los bundles

Carga la app con las dev tools abiertas y mira la pestaña de red por archivos que terminan en .js. Guarda los que la app carga. También puedes traer un archivo directo una vez que tienes su URL.

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

Guarda los archivos en tu directorio de notas para el programa. Quédate en los hosts que el scope lista; un bundle servido desde un dominio de terceros puede estar fuera del scope aunque la app dentro del scope lo cargue.

#Lee un bundle con el modelo

Un bundle minificado es demasiado grande y ruidoso para pegarlo entero en la mayoría de los chats. Saca primero los strings interesantes, y luego pide al modelo que les dé sentido.

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

Dale al modelo paths.txt y las llamadas fetch o axios cercanas, y pídele que agrupe las rutas en API routes probables, adivine el método HTTP y liste los parámetros que cada una parece tomar. La CLI de NotHoly puede leer el archivo y hacer esto en el terminal, o puedes mandarlo por la chat completions API. El modelo vuelve un muro de strings en una lista corta y testeable.

#De strings a endpoints que confirmas

La lista del modelo es un conjunto de conjeturas. Vuelves cada conjetura en un request real por tu proxy y observas qué regresa. Una ruta que devuelve 401 sin token y 200 con uno es un endpoint vivo que vale probar. Una ruta que da 404 en todas partes puede ser código muerto dejado en el bundle. Confirma el método y los parámetros enviando el request tú mismo, porque el modelo los infirió de texto y puede estar equivocado en ambos.

#Source maps cuando existen

Algunas apps entregan source maps, que mapean el bundle minificado de vuelta a código legible. Un comentario //# sourceMappingURL= al final de un bundle o un archivo .map que empareja apunta a uno. Cuando hay un map presente y dentro del scope, hace el código mucho más fácil de leer, y el modelo puede resumir módulos enteros por ti. MDN explica los source maps. Trata todo lo que aprendas de ellos como una pista para confirmar contra la app en ejecución, igual que antes.

#Cuidado con el modelo inventando endpoints

Un modelo al que le pides endpoints a veces produce unos plausibles que no están en el archivo, porque inventar una ruta de aspecto probable es justo el tipo de conjetura fluida para la que está hecho. El OWASP Top 10 para Aplicaciones de LLM lista esto bajo alucinación y exceso de confianza. Protégete con un hábito: cada ruta que pruebas vino de un string que puedes señalar en el bundle, y cada método y parámetro está confirmado por una response real. Si el modelo nombra un endpoint que no encuentras en el archivo, descártalo.

#Lo siguiente en esta serie

Ahora tienes una lista confirmada de endpoints y parámetros. Probar bugs web comunes con ayuda de IA toma esa lista y recorre IDOR, XSS, SSRF y auth rota. La OWASP Web Security Testing Guide tiene el método completo para cada clase.