Path Traversal: cos’è l’attacco e come prevenirlo

Il path traversal — noto anche come directory traversal — è una vulnerabilità delle applicazioni web che permette a un attaccante di accedere a file e cartelle fuori dalla directory prevista, manipolando i percorsi che l’applicazione costruisce a partire dagli input dell’utente. Il nome descrive il gesto: “attraversare” l’albero delle directory risalendo verso la radice, fino a raggiungere file che non avrebbero mai dovuto essere esposti — configurazioni, credenziali, file di sistema.

È una delle vulnerabilità più antiche del web, documentata fin dagli anni Novanta, e paradossalmente ancora attualissima: la diffusione di microservizi, API e funzioni cloud ha moltiplicato i punti in cui un percorso file viene costruito da un input, e con essi le occasioni di sbagliare. In questo articolo vediamo come funziona il path traversal, il suo legame con gli attacchi di File Inclusion, un caso reale e come prevenirlo e verificarlo.

1. Cos’è il path traversal e come funziona
2. Absolute e Relative Path Traversal
3. Dal path traversal al File Inclusion (LFI e RFI)
4. Un caso reale: CVE-2021-41773
5. Come prevenire il path traversal
6. Come verificare se le vostre applicazioni sono esposte

Cos’è il path traversal e come funziona

Le applicazioni web vivono su server organizzati, come qualunque computer, in un albero di cartelle che parte da una radice — la root — e si dirama in sottocartelle e file. Molte applicazioni usano i parametri dell’URL per decidere quale file caricare: un’icona cliccata, una pagina richiesta, un documento da scaricare si traducono in un percorso file che l’applicazione legge e restituisce.

Il problema nasce quando quel percorso viene costruito con un input dell’utente senza validarlo.
Poiché i parametri dell’URL sono liberamente modificabili, un attaccante può sostituire il valore atteso con una sequenza che risale l’albero delle directory — la notoria stringa “../”, che nei filesystem significa “torna alla cartella superiore”. Ripetendola, si esce dalla directory dell’applicazione e si raggiungono aree del server che dovrebbero restare inaccessibili: su un sistema Unix, l’esempio didattico classico è il file che elenca gli account di sistema. Appartiene alla stessa logica delle altre falle di iniezione, come la code injection: input non fidato trattato dall’applicazione come istruzione legittima — qui, come percorso legittimo.

Absolute e Relative Path Traversal

Si distinguono due modalità dello stesso attacco, a seconda di come viene espresso il percorso:

La difficoltà, per chi difende, è che queste sequenze possono essere mascherate per aggirare i filtri ingenui: la stessa “../” può presentarsi in codifica URL, in doppia codifica o in varianti che un controllo scritto male non riconosce. È il motivo per cui, come vedremo, il filtraggio basato su liste di stringhe vietate è una difesa fragile: c’è sempre una codifica in più che il filtro non aveva previsto.

Dal path traversal al File Inclusion (LFI e RFI)

Il path traversal diventa molto più pericoloso quando non serve solo a leggere file, ma a eseguirli. È il territorio degli attacchi di File Inclusion, che sfruttano la stessa radice — input non validato che costruisce un percorso — con un obiettivo più ambizioso:

Il vero pericolo, come sanno gli analisti, sta nel concatenamento: un path traversal che rivela un file di configurazione con delle credenziali, un caricamento file mal protetto che permette di piazzare un file malevolo, una LFI che lo esegue. Ogni anello preso da solo è un problema circoscritto; messi in fila, portano alla compromissione dell’intero server — l’esito che chiamiamo remote code execution. È bene sapere, per equilibrio, che le configurazioni moderne dei linguaggi server rendono la RFI molto più rara che in passato, disabilitando per impostazione predefinita l’inclusione di file remoti; ma resta viva nelle applicazioni che implementano in proprio, e male, la logica di caricamento.

Un caso reale: CVE-2021-41773

Che il path traversal non sia un residuo del passato lo dimostra uno dei casi più clamorosi degli ultimi anni. Nel settembre 2021, un aggiornamento di Apache HTTP Server — uno dei web server più diffusi al mondo — introdusse la vulnerabilità CVE-2021-41773: un errore nel trattamento dei percorsi che permetteva di aggirare i controlli e leggere file fuori dalle directory consentite, con possibilità di arrivare, in certe configurazioni, all’esecuzione di codice.

Il caso è istruttivo per due motivi. Primo: la falla fu introdotta da un aggiornamento, a riprova che aggiornare è necessario ma non infallibile. Secondo: la prima correzione si rivelò incompleta, e servì una seconda patch per chiudere davvero il problema — mentre nel frattempo i sistemi non aggiornati venivano attivamente sfruttati. La lezione è quella di sempre: tra la pubblicazione di una vulnerabilità e lo sfruttamento di massa passano ore, e il ritardo nell’applicare le correzioni è il vero fattore di rischio.

Come prevenire il path traversal

La difesa dal path traversal ruota attorno a un principio che le fonti più autorevoli ripetono all’unisono: la soluzione migliore è impedire del tutto che l’utente influenzi i percorsi dei file. Eliminare il problema alla radice è più robusto di qualsiasi filtro applicato a valle. Dove questo non è possibile, le misure efficaci sono:

• Validazione tramite whitelist: non tentare di elencare tutto ciò che è vietato (approccio fragile, sempre aggirabile con una codifica nuova), ma definire l’insieme chiuso dei file legittimamente richiamabili e rifiutare tutto il resto;
• Normalizzazione dei percorsi: risolvere il percorso nella sua forma canonica prima di validarlo, così che le varianti mascherate e le codifiche multiple vengano ricondotte alla loro forma reale e riconosciute;
• Isolamento dell’ambiente: confinare l’applicazione in modo che, anche in caso di traversal riuscito, i file raggiungibili siano un insieme ristretto e innocuo — le tecniche di segregazione a livello di sistema operativo servono esattamente a questo;
• Principio del minimo privilegio: il processo che serve i file deve poter leggere solo ciò che gli serve, mai l’intero filesystem;
• Aggiornamento costante di server, framework e componenti — come insegna il caso Apache, molte falle di traversal vivono nell’infrastruttura, non nel vostro codice.

Molte di queste debolezze sono individuabili nel codice con l’analisi statica durante lo sviluppo; ma la prova del nove si ha solo verificando l’applicazione reale, con i suoi componenti e le sue configurazioni.

Come verificare se le vostre applicazioni sono esposte

Il path traversal è una delle vulnerabilità che una verifica strutturata individua con buona affidabilità, perché lascia tracce riconoscibili nel modo in cui l’applicazione gestisce i percorsi. Il primo livello è la scansione: un web vulnerability assessment sollecita i punti di input dell’applicazione con le varianti note dell’attacco e segnala dove i controlli cedono, restituendo le criticità con la loro gravità.

Il livello successivo serve dove il rischio vero è il concatenamento: una singola lettura di file può sembrare innocua finché un analista non dimostra che, combinata con altre debolezze, porta all’esecuzione di codice sul server. Misurare questa catena — non la singola falla, ma fin dove arriverebbe un attaccante reale — è il compito del web application penetration testing, la verifica manuale che completa la scansione automatica sulle applicazioni che gestiscono dati o funzioni critiche.