Cariddi: trovare endpoint nascosti per il bug hunting

Cariddi: trovare endpoint nascosti per il bug hunting

Nel bug hunting, gli endpoint visibili sono solo la parte facile. La differenza la fanno quelli che non compaiono nei menu, nelle sitemap o nella documentazione pubblica: vecchie API, pannelli interni esposti per errore, route di test, versioni alternative della stessa risorsa, callback dimenticate, percorsi amministrativi mascherati da nomi innocui. Cariddi nasce proprio per questo tipo di lavoro: osservare, raccogliere, correlare e far emergere superfici che spesso restano invisibili a una scansione superficiale.

Il valore di uno strumento come Cariddi non è “trovare tutto” in automatico, ma costruire una mappa ragionata del target. In pratica, aiuta a trasformare segnali sparsi in ipotesi verificabili. Un parametro visto in un JavaScript, una rotta con risposte anomale, un sottodominio che risponde in modo incoerente, un redirect verso un path insolito: ogni indizio può portare a un endpoint utile, a un dato esposto o a una funzionalità dimenticata.

Perché gli endpoint nascosti contano davvero

Molti incidenti di sicurezza non nascono da vulnerabilità sofisticate, ma da funzioni lasciate troppo visibili. Un endpoint di debug può rivelare informazioni sensibili. Una vecchia API può accettare input senza validazione moderna. Un path amministrativo può essere protetto male o solo dal lato client. Una route di export può restituire dati che non dovevano essere accessibili a quel livello di privilegio.

Il bug hunting efficace parte da una premessa semplice: il perimetro reale di un’applicazione è più ampio di ciò che il browser mostra. Per questo conviene osservare la struttura del traffico, i riferimenti interni, i pattern ripetuti e le differenze tra risposte. Cariddi è utile quando vuoi passare da una visione “pagina per pagina” a una visione “superficie per superficie”.

Approccio operativo: prima osservare, poi forzare

Un buon workflow non comincia con richieste aggressive, ma con raccolta e normalizzazione. Prima si identificano host, sottodomini, percorsi noti, asset statici, file JavaScript, manifest, endpoint API e redirect. Poi si cercano pattern: nomi ricorrenti, versioni, prefissi come /api/, /admin/, /internal/, /beta/, /v1/, /v2/, oppure strutture che tradiscono framework e architetture.

Cariddi si inserisce bene in questa fase perché permette di analizzare segnali tecnici senza perdere il quadro generale. Non serve partire dal colpo grosso: basta una lista ordinata di osservazioni da verificare. In bug hunting, la disciplina batte quasi sempre l’intuizione casuale.

Cosa cercare nei dati raccolti

Gli endpoint nascosti non si presentano sempre con nomi evidenti. Spesso compaiono attraverso indizi indiretti:

• stringhe di URL nei file JavaScript;
• parametri usati solo in alcune condizioni;
• rotte con risposte diverse a seconda del metodo HTTP;
• redirect verso path secondari;
• nomi di funzioni o classi che rivelano API interne;
• commenti residui, metadati o messaggi di errore troppo verbosi;
• asset caricati da sottodomini non documentati.

Un endpoint utile può anche non essere “segreto” in senso stretto: magari è solo non linkato, non indicizzato o accessibile da una parte diversa dell’applicazione. Il bug hunter deve distinguere tra invisibilità reale e semplice mancanza di esposizione nella UI.

Metodologia: un ciclo breve e ripetibile

La parte più efficace del lavoro è iterativa. Un ciclo pratico può essere questo:

1. raccogli gli asset pubblici del target;
2. estrai i riferimenti a path, API e host secondari;
3. normalizza i risultati in un elenco pulito;
4. verifica quali endpoint rispondono davvero;
5. confronta metodi, codici HTTP, header e contenuti;
6. segna anomalie, differenze e accessi inattesi.

Questo approccio evita il classico rumore da scansione indiscriminata. L’obiettivo non è moltiplicare le richieste, ma aumentare il rapporto segnale/rumore. Un solo endpoint trovato bene vale più di cento percorsi generici senza contesto.

Indizi che meritano attenzione

Ci sono segnali che, da soli, non dimostrano una vulnerabilità, ma meritano sempre un approfondimento:

• risposte 200 su path che sembrano amministrativi;
• risposte 403 che cambiano contenuto in base all’header o al metodo;
• JSON con campi interni non documentati;
• API che accettano versioni diverse della stessa risorsa;
• nomi di endpoint che suggeriscono funzioni di test, staging o migrazione;
• messaggi di errore con stack trace, nomi di file o percorsi assoluti.

Quando uno di questi segnali compare, la priorità è capire se si tratta di un falso positivo o di una superficie reale. Cariddi è utile proprio nel passaggio tra “sembra interessante” e “è verificabile”.

Come evitare di perdersi

Nel bug hunting si rischia spesso di accumulare materiale senza arrivare a una conclusione. La soluzione è mantenere tre livelli separati: osservazioni, ipotesi, verifiche. Le osservazioni sono i dati grezzi. Le ipotesi sono le idee su cosa potrebbe esserci dietro. Le verifiche sono le prove che confermano o smentiscono l’ipotesi.

Per esempio, se un file JavaScript contiene riferimenti a /api/internal/report, l’osservazione è il path. L’ipotesi è che esista un endpoint interno di reportistica. La verifica non è “insistere” sul path, ma testare in modo controllato metodo, autenticazione, risposta e differenze tra ruoli o sessioni, sempre entro il perimetro autorizzato.

Cariddi e la lettura delle superfici moderne

Le applicazioni attuali raramente sono monolitiche. Spesso sono composte da frontend separato, API, servizi interni, CDN, storage object, funzioni serverless e integrazioni terze. Questo crea una frammentazione della superficie d’attacco. Un endpoint può non essere raggiungibile dal menu principale, ma esserlo da un sottodominio diverso o da una route usata solo dal frontend.

In questo contesto, Cariddi aiuta a seguire i fili tra un componente e l’altro. Un asset statico può puntare a un host API. Un errore lato client può rivelare un endpoint di fallback. Un manifest può contenere percorsi che il browser non mostra all’utente. Il punto non è inseguire ogni stringa, ma capire quali sono davvero operative.

Buone pratiche durante l’analisi

Se lavori su un programma di bug bounty o su un ambiente autorizzato, conviene rispettare alcune regole operative semplici:

• non saturare il target con richieste inutili;
• conservare evidenze pulite e riproducibili;
• annotare timestamp, URL, metodo e risposta;
• confrontare sempre più segnali prima di concludere;
• privilegiare verifiche minimamente invasive;
• se trovi un endpoint sensibile, fermati e valuta impatto e disclosure responsabile.

La qualità del report dipende molto da come hai raccolto le prove. Un finding ben documentato è più utile di una scoperta vaga. In particolare, differenze di comportamento tra utenti, ruoli o metodi HTTP sono spesso più importanti del semplice “ho trovato un path strano”.

Un esempio mentale di lavoro

Immagina un sito con un frontend pubblico e una dashboard privata. Nei file statici compare un riferimento a /api/v2/export. La rotta non è linkata nella UI, ma risponde con un errore differente rispetto ad altri path casuali. Da lì puoi verificare se esiste solo per determinati ruoli, se accetta parametri inattesi, se espone metadata o se è semplicemente un residuo di una vecchia funzione.

Questo è il tipo di situazione in cui Cariddi dà valore: non perché “trova magie”, ma perché rende più leggibile la catena degli indizi. Il bug hunter bravo non si limita a scovare un endpoint; capisce perché esiste, come viene richiamato e quali assunzioni di sicurezza lo proteggono male.

Errore comune: confondere scoperta con vulnerabilità

Scoprire un endpoint nascosto non significa automaticamente aver trovato un bug. A volte il path è intenzionalmente esposto solo a utenti autenticati. Altre volte è già protetto da controlli robusti. La vera utilità nasce quando l’endpoint mostra una debolezza: accesso improprio, validazione insufficiente, informazioni sensibili, logica di autorizzazione errata o esposizione di funzioni interne.

Per questo ogni scoperta va trattata come una pista, non come una conclusione. La differenza tra una buona analisi e una caccia confusa sta proprio qui: separare la superficie dall’impatto.

Conclusione operativa

Cariddi è interessante perché sposta il focus dal rumore alla struttura. Nel bug hunting moderno, trovare endpoint nascosti significa leggere meglio l’applicazione, non solo scandirla. Se usato con metodo, aiuta a individuare API dimenticate, percorsi interni, funzioni di test e superfici che meritano una verifica seria.

Il principio da tenere a mente è semplice: prima raccogli gli indizi, poi costruisci l’ipotesi, infine verifica con precisione. È questo ordine che trasforma una lista di URL in una vera analisi di sicurezza.

Nota pratica: lavora sempre entro autorizzazione esplicita, documenta ogni passaggio e considera un endpoint “interessante” solo quando puoi spiegarne il comportamento con dati riproducibili.