Leggere il JavaScript con l'IA per trovare endpoint

Una single-page app spedisce il suo front end come JavaScript, e quel codice contiene la lista degli endpoint con cui l'app parla. Leggere quei bundle è uno dei lavori di recon a più alto valore per chi inizia, ed è un lavoro di lettura, che è dove un modello aiuta. Questo post segue la preparazione del toolkit e alimenta il test dei bug web. Per un recon più ampio, cos'è l'OSINT spiega l'idea senza diventare un tutorial di strumenti.

#Perché il JavaScript conta

Il browser deve conoscere ogni URL che chiama, quindi i path, i parametri e a volte i feature flag e i nomi dei ruoli vivono nel codice spedito. Un bundle minificato lo nasconde a un umano che legge in fretta, ma le stringhe sono tutte lì. Estrarre gli endpoint dal JavaScript trova spesso rotte che non sono collegate da nessuna parte nell'app visibile, che è esattamente dove si nascondono i bug di controllo degli accessi.

#Raccogli i bundle

Carica l'app con i dev tools aperti e guarda la scheda network per i file che finiscono in .js. Salva quelli che l'app carica. Puoi anche scaricare un file direttamente una volta che hai il suo URL.

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

Tieni i file nella tua directory di note per il programma. Resta sugli host che lo scope elenca; un bundle servito da un dominio di terzi può essere fuori scope anche quando l'app nello scope lo carica.

#Leggi un bundle con il modello

Un bundle minificato è troppo grande e troppo rumoroso per incollarlo intero nella maggior parte delle chat. Estrai prima le stringhe interessanti, poi chiedi al modello di dar loro un senso.

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

Dai al modello paths.txt e le chiamate fetch o axios vicino a esse, e chiedigli di raggruppare i path in probabili rotte API, indovinare il metodo HTTP ed elencare i parametri che ciascuna sembra prendere. La NotHoly CLI può leggere il file e farlo nel terminale, oppure puoi mandarlo attraverso l'API chat completions. Il modello trasforma un muro di stringhe in una lista breve e testabile.

#Dalle stringhe agli endpoint che verifichi

La lista del modello è un insieme di supposizioni. Trasformi ogni supposizione in una request reale attraverso il tuo proxy e osservi cosa torna. Un path che restituisce 401 senza token e 200 con uno è un endpoint vivo che vale un test. Un path che fa 404 ovunque può essere codice morto lasciato nel bundle. Conferma il metodo e i parametri inviando la request tu stesso, perché il modello li ha dedotti dal testo e può sbagliare su entrambi.

#Le source map quando ci sono

Alcune app spediscono le source map, che rimappano il bundle minificato al sorgente leggibile. Un commento //# sourceMappingURL= alla fine di un bundle o un file .map corrispondente ne indica una. Quando una map è presente e nello scope, rende il codice molto più facile da leggere, e il modello può riassumere interi moduli per te. MDN spiega le source map. Tratta qualsiasi cosa impari da esse come una pista da verificare rispetto all'app in esecuzione, come prima.

#Attento al modello che inventa endpoint

Un modello a cui chiedi endpoint a volte produce endpoint plausibili che non sono nel file, perché inventare un path dall'aria credibile è esattamente il tipo di supposizione fluente per cui è costruito. L'OWASP Top 10 per le applicazioni LLM lo elenca sotto allucinazione e dipendenza eccessiva. Proteggiti con una sola abitudine: ogni path che testi viene da una stringa che puoi indicare nel bundle, e ogni metodo e parametro è confermato da una response reale. Se il modello nomina un endpoint che non trovi nel file, scartalo.

#A seguire in questa serie

Ora hai una lista verificata di endpoint e parametri. Testare i bug web comuni con l'aiuto dell'IA prende quella lista e lavora su IDOR, XSS, SSRF e auth rotta. L'OWASP Web Security Testing Guide ha il metodo completo per ogni classe.