Nel gennaio 2003 Jeremiah Grossman ha divulgato un metodo per raggirare le restrizione dei cookie HttpOnly e lo chiamò Cross-Site Tracing (XST) iniziando inconsapevolmente una tendenza ad associare “cross-site” a quante più vulnerabilità possibili relative al web.
Purtroppo le lettere X ed S in XST evocano somiglianza con XSS (Cross-Site Scripting) e questo ha portato le persone a scambiare XST come metodo per iniettare JavaScript nel browser. Sebbene gli attacchi XST si basino sullo scripting del browser per sfruttare la vulnerabilità, nello specifico del metodo XST la vulnerabilità non è l’iniezione di JavaScript.
Il Cross-Site Scripting non muore mai: il perché di un evergreen
Indice degli argomenti
Un po’ di chiarezza: XST e XSS a confronto
Un tracciamento Cross-Site Tracing (XST) è una vulnerabilità di sicurezza della rete che sfrutta il metodo HTTP TRACE. Gli script XST sfruttano ActiveX, Flash, Java o qualsiasi altro metodo che consenta l’esecuzione di una richiesta HTTP TRACE.
La risposta HTTP TRACE tiene conto di tutte le intestazioni HTTP inclusi i dati di autenticazione e i cookie HTTP contenuti, che verranno sfruttati da questi script. Combinando i problemi di sicurezza nell’accesso nei browser Web, l’exploit è in grado di raccogliere i dati memorizzati nella cache sulle credenziali di qualsiasi sito Web, inclusi quelli che utilizzano SSL.
Un attacco Cross-Site Tracing (XST) prevede l’utilizzo di metodi XSS (Cross-Site Scripting, che verrà spiegato nel prossimo paragrafo) e la funzione HTTP TRACE.
HTTP TRACE è una funzione predefinita in molti server Web, utilizzata principalmente per il debug. Il client invia una TRACE HTTP con tutte le informazioni di intestazione inclusi i cookie, e il server risponde semplicemente con gli stessi dati.
Se si utilizza Javascript o altri metodi per rubare un cookie, o altre informazioni sono disabilitati attraverso l’uso di un cookie “httpOnly” o altro, un utente malintenzionato può forzare il browser per inviare una richiesta HTTP TRACE e restituire la risposta del server verso un’altra destinazione. “httpOnly” è un parametro extra aggiunto ai cookie che nasconde il cookie dallo script (supportato nella maggior parte dei browser, ma non in tutti). Ad esempio “javascript:alert(document.cookie)” non mostrerebbe un cookie httpOnly.
Questo tipo di attacco può verificarsi quando è presente una vulnerabilità XSS e il server supporta HTTP TRACE. Normalmente il cookie viene rinviato al destinatario cui appartiene. Ma con questa TRACE o TRACK HTTP, è possibile richiedere il ritorno e il server web restituirà tutti i dati, compreso il cookie. Questo impatta particolarmente i frontend o siti web che fanno affidamento dei cookie per l’autenticazione dei propri utenti.
Cross-Site Scripting (XSS) invece è una vulnerabilità di sicurezza che consente a un utente di alterare il codice che una determinata applicazione fornisce a un utente che viene eseguito nel browser Web dell’utente stesso. Si trova più comunemente nelle applicazioni Web che si affidano per intero ai browser dell’utente, ma è possibile trovarlo anche in altre applicazioni con contenuto Web incorporato, come un visualizzatore di contenuti interattivi, ad esempio.
Quando una vulnerabilità XSS viene utilizzata come vettore di attacco, l’input inviato dall’aggressore viene elaborato in modo non sicuro all’interno dell’applicazione in modo da consentire all’aggressore di alterare il codice inviato alla vittima ed eseguirlo nel browser web.
Cross-Site Tracking o Cross-Site Tracing? Che confusione
Il metodo Cross-Site Tracking (CST) non è una vulnerabilità di cybersecurity di configurazione o bug, ma una vulnerabilità alla propria privacy, e viene utilizzato da varie società per raccogliere dati da diverse pagine Web attraverso annunci e collegamenti su siti Web.
Per proteggere le proprie informazioni personali dal monitoraggio, gli utenti possono cercare attraverso le impostazioni, un modo per impedire il tracciamento tra siti.
Ora, cosa significa impedire il monitoraggio cross-site? Riassumendo, impedire il tracciamento tra siti è un atto per impedire il tracciamento dei siti che si visitano. In tal modo, i propri dati personali non potrebbero essere monitorati da società terze.
Google Chrome è uno dei browser più popolari che le persone utilizzano regolarmente in tutto il mondo. Molti siti web che si visitano utilizzando Google Chrome, raccolgono e utilizzano le proprie informazioni di navigazione per migliorare la sicurezza, offrire contenuti, annunci pubblicitari, consigli e servizi sui siti e generare statistiche sui rapporti.
Qualsiasi browser si utilizzi, si può evitare il Cross-Site Tracking configurando correttamente i parametri della privacy e tracciamento all’interno delle sue impostazioni.
Detto ciò, è evidente che il Cross-Site Tracking (CST) nulla ha a che fare con il Cross-Site Tracing (XST) che come spiegato prima, è una vulnerabilità di sicurezza della rete che sfrutta il Metodo HTTP TRACE su siti web.
Prevenire attacchi Cross-Site Scripting e contrastare il Cross-Site Tracing
Ecco, di seguito, alcune best practice per prevenire attacchi di tipo Cross-Site Scripting e contrastare il Cross-Site Tracing.
Prevenire attacchi Cross-Site Scripting (XSS)
Le vulnerabilità XSS possono consentire diversi tipi di attacchi contro una vittima, tra cui:
- rubare il token della sessione di accesso consentendo all’aggressore di interagire con l’applicazione come vittima senza conoscere la sua password;
- forzare l’utente a inviare richieste controllate da un aggressore a un server come per esempio un’applicazione Web di un sito finanziario vulnerabile che costringa a trasferire denaro;
- modificare il contenuto della pagina come per esempio un sito di notizie alterato per dichiarare che si è verificato un falso crollo del mercato azionario che ha incitato al panico;
- indurre la vittima a divulgare la sua password verso l’applicazione o ad altre applicazioni;
- infettare la vittima con altro codice dannoso utilizzando una vulnerabilità nel browser Web stesso ed eventualmente impossessarsi del computer della vittima.
Alcuni attacchi possono essere inviati al server delle applicazioni ed eseguiti contro molti altri utenti di quell’applicazione, per esempio:
- un sito forum vulnerabile o un sistema di commenti consente a un utente pubblicando post di essere visualizzato da molti altri utenti che diventano vittime dell’attacco;
- un modulo di contatto vulnerabile invia un messaggio dannoso agli amministratori del sito che consente all’aggressore di accedere al “pannello di amministrazione” quando viene visualizzato da un utente amministrativo.
Altri metodi di attacco propiziano che l’autore dell’attacco convinca o induca l’utente a caricare prima un collegamento dannoso, possibilmente utilizzando e-mail, messaggistica istantanea o un post o un commento sul forum.
La forma più standard e probabilmente più semplice di eliminazione della vulnerabilità di Cross-Site Scripting è quella di passare tutti i dati esterni attraverso un filtro. Un tale filtro rimuoverebbe le parole chiave pericolose, ad esempio il famigerato <script>tag, comandi JavaScript, stili CSS e altri markup HTML pericolosi (come quelli che contengono gestori di eventi).
Molti sviluppatori web scelgono di implementare i propri meccanismi di filtro XSS. Di solito scrivono codice lato server (in PHP, ASP o qualche altro linguaggio di sviluppo utilizzato per il Web) per cercare parole chiave e sostituirle con stringhe vuote.
Questa tecnica di per sé non è male, tuttavia e purtroppo, i malintenzionati di solito hanno più esperienza degli sviluppatori web e spesso riescono a eludere semplici filtri utilizzando tecniche come la codifica esadecimale, le variazioni di caratteri Unicode, le interruzioni di riga e i “caratteri null” nelle stringhe. Queste tecniche devono essere tutte soddisfatte ed è per questo che si consiglia di utilizzare librerie provate e testate dalla comunità in generale.
Un altro metodo è un “escape” HTML ed è un metodo abbastanza facile. Tuttavia, per garantire la sicurezza delle applicazioni Web, è necessario anche eseguire “escape” del codice JavaScript, dei fogli di stile a cascata e talvolta dei dati XML. Per architettare questo tipo di fuga (escape) è necessario anche qui servirsi di librerie di “escape” opportunamente testate.
Le due librerie di escape più popolari disponibili sono ESAPI fornite da OWASP e AntiXSS fornite per Microsoft. ESAPI può essere collegata a varie tecnologie come Java, .NET, PHP, ASP classico, Cold Fusion, Python e Haskell. D’altro canto AntiXSS invece protegge esclusivamente le tecnologie Microsoft ed è quindi più adatto in un ambiente interamente Microsoft. Entrambe le librerie sono costantemente aggiornate per stare al passo con le ultime tecniche utilizzate dai malintenzionati e sono gestite da esperti del settore che comprendono le tattiche in evoluzione e le tecnologie emergenti.
Contrastare il Cross-Site-Tracing (XST)
Per proteggersi dal XST, si dovrebbe disattivare il metodo TRACE HTTP se si utilizza Apache e il metodo TRACK HTTP se si utilizza Microsoft IIS.
Per iniziare (ma non che sia l’unica precauzione da prendere), in Apache per esempio, si dovrebbe inserire quanto segue nel file .htaccess del documento root (o per ragioni prestazionali, direttamente nel file di configurazione di Apache):
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* – [F]
La letteratura che illustra i metodi di tutela verso il XST è molto estesa e questo articolo non si propone l’obbiettivo di coprire esaustivamente tale tematica, bensì quello di far chiarezza mettendo a confronto XST e XSS. L’invito è sempre quello di riflettere, cercare, investigare e proteggervi implementando al meglio la cybersecurity delle vostre piattaforme.
Usare browser aggiornati anche per la applicazioni aziendali
Gli aggiornamenti del browser possono disabilitare estensioni e plug-in con vulnerabilità note o modificare il codice di background in modo da rendere inefficaci molti exploit.
Anche gli exploit della privacy nei browser sono comuni. Nel maggio del 2021, FingerprintJS ha scoperto una vulnerabilità in Safari, Google Chrome, Firefox e Tor Browser che potrebbe collegare l’identità di un utente tra diversi browser desktop, aggirando efficacemente le protezioni della privacy messe in atto da quegli stessi browser. Quando FingerprintJS ha scoperto il problema, gli sviluppatori di Google Chrome avevano già aggiunto una correzione alla loro roadmap di aggiornamento. Ovviamente, il metodo migliore è quello di mantenere sempre aggiornati i vostri browser. I malintenzionati utilizzeranno le vulnerabilità nei browser Web per colpire gli utenti con malware come ransomware, exploit per la privacy e altri attacchi.
Gli attacchi basati su browser possono anche fare cose piuttosto sorprendenti se portati agli estremi. Esistono molti esempi di dispositivi jailbroken che utilizzano exploit del browser, come il jailbreak di iPhone OS 3 che sfruttava un difetto nel modo in cui Safari trattava i file PDF. Ciò ha fornito ai malintenzionati l’accesso a livello di sistema di cui avevano bisogno per installare firmware personalizzato sugli smartphone di Apple.
I cosiddetti “drive-by download attack” tenteranno di scaricare contenuti dannosi sul proprio computer indipendentemente dal consenso dato. Tutto quello che bisognerebbe fare è visitare un sito Web compromesso o ricevere un annuncio dannoso e senza la necessità di visitare angoli sgradevoli del Web, poiché molti di questi attacchi vengono diffusi tramite i “social media”.
Anche le estensioni e i plug-in installati insieme a un browser potrebbero rappresentare un rischio. Adobe ha finalmente messo a riposo Flash nel gennaio del 2021, con le vulnerabilità della sicurezza che hanno giocato un ruolo importante in quella decisione. Tutte le versioni di Flash da maggio 2020 avevano un killswitch che disabilitava il plugin in modo permanente dopo il 31 dicembre 2020.
Mitigare con scansioni continue delle nuove web app in azienda
Oggi possiamo contare con una vasta serie di scanner sia online che applicazioni locali offline per l’accertamento di vulnerabilità.
Di questi possiamo trovare una lunga serie a pagamento e altri gratuiti. Possiamo dividerli in due macro insiemi quelli più affidabili e minuziosi e quelli che approfondiscono meno le proprie ricerche, per dar passo a velocità di scansione o saltare i “falsi positivi” automaticamente. In uno scenario come quello appena descritto forse il metodo migliore quanto meno all’inizio per poter mitigare falle alle proprie piattaforme è quello di affidarsi a professionisti della cybersecurity, che potranno accertare le problematiche molto più velocemente, per poi a seguire farsi consigliare quale sistema è più appropriato alla vostra realtà.
L’approccio metodologico è quello di istituire sistemi di scansioni periodici in modo di rilevare problematiche soprattutto su quelle applicazioni con nuovi sviluppi messi in produzione che non mancano mai di vulnerabilità in agguato.
Le applicazioni Web ad uso e consumo interno alle aziende di solito sono anelli deboli, esse vengono messe in produzione “affidandosi al buon senso” dei dipendenti, illudendosi che all’interno dell’azienda non esistono pericoli in quanto già protetti da antivirus e firewall.
La consapevolezza della sicurezza tra gli sviluppatori web
Come scritto sopra, gli sviluppatori web scelgono di implementare i propri meccanismi di filtro XSS, utilizzano librerie open source, adottano metodi di “escape” personalizzati, ed altro. Ad oggi il vero problema è l’esternalizzazione dei processi di sviluppo che con l’obbiettivo di arginare costi e rilasciare versioni di applicazioni nel minor tempo possibile, incitano agli sviluppatori a correre dietro le lancette dell’orologio a costo di consegnare talvolta lavori imprecisi a livello di cybersecurity.
Lo sviluppo per conto terzi si focalizza sul testing delle applicazioni a livello di gestione degli errori ma penalizzano i test a livello sicurezza per ovvie mancanze di tempo e “bilancio di previsione” ovvero poco budget.
Paradossalmente in questo aspetto l’ultima parola aspetterebbe al cliente, che dovrebbe esigere, dando più tempo per lo sviluppo, una certificazione di sicurezza sulle applicazioni sviluppate. Talvolta rilasciare una nuova versione di applicazione un paio di giorni dopo non compromette interi bilanci aziendali.
Prendere coscienza della necessità di avere applicazioni sicure significa viaggiare un passo avanti nella qualità del servizio della propria azienda.
