XST attack (Cross-Site Tracing): cos’è e come difendersi

Cross-Site Tracing, in sigla XST, è uno di quei nomi che traggono in inganno. Per assonanza viene spesso confuso con il Cross-Site Scripting (XSS), ma si tratta di due cose diverse: l’XSS inietta codice in una pagina, l’XST sfrutta un metodo HTTP poco conosciuto per rubare informazioni che dovrebbero essere protette. È una tecnica datata, oggi in gran parte neutralizzata dai browser moderni, ma vale la pena capirla — perché continua a comparire nei report degli scanner di sicurezza e perché il meccanismo che la rende possibile racconta molto su come si difende un’applicazione web.

In questo articolo vediamo cos’è il metodo HTTP TRACE, come funziona un attacco XST, perché oggi è considerato un rischio minore e come ci si protegge.

1. Che cos’è il metodo HTTP TRACE
2. Che cos’è un attacco XST
3. Perché oggi l’XST è un rischio minore
4. Come prevenire un attacco XST
5. Conclusioni

Che cos’è il metodo HTTP TRACE

Il metodo HTTP TRACE nasce con uno scopo puramente diagnostico. Quando è abilitato, permette a un server web di rispondere a una richiesta restituendo nella risposta l’esatta richiesta che ha ricevuto: un meccanismo di “eco” utile agli sviluppatori per il debug, perché consente di vedere cosa arriva davvero al server lungo la catena di trasmissione.

Il problema è che questo comportamento è un’arma a doppio taglio. La richiesta che il server rispedisce indietro contiene tutte le intestazioni HTTP, comprese quelle che trasportano informazioni sensibili come i cookie di sessione o i dati di autenticazione. Se un attaccante riesce a far inviare al browser della vittima una richiesta TRACE, può leggere nella risposta proprio quei dati riservati. Lo stesso vale per il metodo TRACK, l’equivalente specifico dei server Microsoft IIS.

Che cos’è un attacco XST

L’XST può essere descritto come una versione avanzata di un attacco Cross-Site Scripting, pensata per aggirare una protezione specifica. Per capirlo bisogna fare un passo indietro, all’attributo HttpOnly.

Uno degli obiettivi più comuni di un attacco Cross-Site Scripting è rubare i cookie di sessione di un utente, leggendoli tramite JavaScript e inviandoli a un server controllato dall’attaccante. Per difendersi, nel 2002 Microsoft introdusse in Internet Explorer l’attributo HttpOnly: un cookie marcato in questo modo non è accessibile a JavaScript, e quindi non può essere sottratto con un classico XSS.

L’XST nasce proprio per superare questa barriera. La tecnica fu documentata nel 2003 dal ricercatore Jeremiah Grossman, che mostrò come, combinando una vulnerabilità XSS con il metodo HTTP TRACE, fosse possibile rubare i cookie anche quando erano protetti da HttpOnly. Il ragionamento è ingegnoso: se JavaScript non può leggere il cookie direttamente, può però costringere il browser a inviare una richiesta TRACE; il server la rispedisce indietro completa di tutte le intestazioni — cookie compreso — e a quel punto lo script malevolo legge il cookie dal corpo della risposta, dove non è soggetto alle restrizioni di HttpOnly.

In pratica, un attacco XST riuscito richiede due condizioni contemporanee: la presenza di una vulnerabilità XSS sull’applicazione e un server che accetta richieste HTTP TRACE.

Perché oggi l’XST è un rischio minore

C’è un aspetto che va detto con chiarezza: l’XST è oggi una minaccia in gran parte superata. Già pochi anni dopo la sua scoperta, i browser hanno iniziato a bloccare l’invio di richieste TRACE tramite JavaScript, e le versioni moderne di Chrome, Firefox e degli altri browser impediscono questo tipo di chiamata. La tecnica resta teoricamente sfruttabile solo in scenari particolari, su software datato o non aggiornato.

Questo non significa che il metodo TRACE non vada disabilitato. Quando uno scanner di sicurezza o un vulnerability assessment rileva che TRACE è ancora attivo su un server, non sta segnalando tanto un pericolo immediato, quanto un sintomo: un server configurato senza la dovuta attenzione, su cui probabilmente sono rimaste attive anche altre impostazioni superflue. È un piccolo campanello d’allarme su una gestione poco rigorosa, ed è esattamente il tipo di dettaglio che la categoria Security Misconfiguration della OWASP Top 10 invita a non trascurare.

Come prevenire un attacco XST

La difesa contro l’XST agisce su due fronti, quello del server e quello dell’utente.

Sul lato server, la misura principale è disabilitare il metodo HTTP TRACE (e il TRACK su IIS), che nella stragrande maggioranza dei casi non serve in produzione. La stessa OWASP raccomanda da tempo questa configurazione. Poiché l’XST ha comunque bisogno di una vulnerabilità XSS per funzionare, vale poi tutto il lavoro di prevenzione contro il Cross-Site Scripting: validazione rigorosa degli input, corretta codifica dell’output e adozione dell’attributo HttpOnly sui cookie di sessione.

Sul lato utente, le buone pratiche sono quelle di sempre: mantenere browser e sistema operativo aggiornati con le ultime patch di sicurezza, ed eliminare regolarmente i cookie, impostando se possibile il browser perché li rimuova alla fine di ogni sessione.

Conclusioni

L’XST è un vettore di attacco ormai anziano, neutralizzato nella pratica dalle protezioni dei browser moderni. Studiarlo, però, non è un esercizio puramente storico: aiuta a capire come tecniche apparentemente innocue — un metodo diagnostico come TRACE — possano trasformarsi in strumenti d’attacco, e ricorda che la sicurezza di un’applicazione web si gioca anche sui dettagli di configurazione che è facile dare per scontati. Verificarli con regolarità è il modo più semplice per non lasciare porte socchiuse.