Il pericolo corre sul browser

In un mondo ambientato sempre più nei browser web, le vulnerabilità dei siti web preoccupano per la sicurezza degli utenti e dei loro dati. Il Cross Side Scripting (XSS) è una delle più insidiose, perché colpisce direttamente l’utente piuttosto che il server web. E l’utente non può nemmeno difendersi, a meno di non voler disabilitare del tutto Javascript (cosa che, però, impedirebbe la visualizzazione di qualsiasi sito moderno). Il Cross Site Scripting avviene solitamente quando un sito che offre all’utente la possibilità di inserire dei dati, per esempio tramite un form, non verifica il testo inserito per assicurarsi che non siano presenti porzioni di codice. E quindi per un utente malintenzionato diventa possibile iniettare Javascript in una pagina web che verrà visualizzata da qualcun altro. Certo, tutto questo richiede comunque una vulnerabilità nel sito web in questione, e almeno per i siti più sensibili (banche, istituzioni pubbliche, aziende sanitarie eccetera) è probabile che il codice del sito sia stato controllato così tante volte e da così tante persone che la probabilità di un errore che porta a una XSS è piuttosto basso. Quindi finché ci possiamo fidare del sito che visitiamo va tutto bene. O no? In effetti, c’è una situazione particolare da tenere in considerazione: e se la porzione di Javascript vulnerabile non fosse nel sito? Se fosse nel browser stesso? I browser moderni offrono infatti la possibilità di aumentare le funzionalità con delle estensioni. E in qualche caso, sono persino preinstallate e attive di default. Per esempio, su Edge, il browser di Microsoft che ha sostituito Internet Explorer.

IL SERVER FA, IL BROWSER DISFA

Prima di tutto, bisogna capire come funziona il Cross Site Scripting. Pensiamo a un sito che permette di scrivere dei commenti. Se il testo di un commento non viene controllato e contiene del codice Javascript, quando il commento viene pubblicato sarà visibile per qualsiasi altro utente, e il suo codice sarà eseguito da tutti. Il che è un problema grave, perché quel codice viene eseguito come se facesse veramente parte del sito web, e quindi con accesso a cookies e local storage dell’utente. In altre parole, con accesso all’identità dell’utente: con la possibilità di eseguire azioni sul sito stesso a nome dell’utente che sta visualizzando la pagina. Questa cosa è ormai un problema molto grave perché buona parte dei siti web è realizzata con il modello frontend-backend, dove tutte le informazioni sono gestite dal backend (che è anche l’unico ad avere un accesso al database), mentre il frontend è “ignorante” e ottiene i vari componenti da visualizzare sulla pagina tramite chiamate alle API esposte dal backend. Naturalmente, ci sono delle protezioni per il backend, per cui di solito le chiamate HTTP alle API sono permesse solo se provenienti dal frontend e regolarmente autenticate. Tuttavia, questa è esattamente la situazione in cui si trova del codice Javascript iniettato nelle pagine tramite XSS, visto che il server non ha modo di sapere se le chiamate che arrivano dal frontend siano legittime o no. Il criminale può quindi eseguire azioni per conto di qualsiasi utente visualizzi il suo codice, per esempio facendogli pubblicare post, cambiando la sua password, estraendo dati personali o eseguendo pagamenti (a seconda della natura del sito web, ovviamente).

Questo vale, per l’appunto, finché la vulnerabilità è insita in un sito web, e quindi colpisce quel sito nello specifico. Ma se la vulnerabilità è presente in una estensione del browser, che ha naturalmente accesso a tutte le pagine web e al loro contenuto, può essere possibile sfruttare la XSS anche se il frontend del sito non è direttamente vulnerabile. Nello specifico, parliamo della vulnerabilità presente nel plugin di traduzione delle pagine di Microsoft Edge. Quando il traduttore prende il testo di una pagina in lingua straniera e lo traduce in italiano la nuova pagina viene visualizzata nella scheda del browser con gli stessi cookies della pagina originale, quindi ha accesso all’identità dell’utente. Ed è ovvio che, se il traduttore non pulisce correttamente il codice HTML, è possibile che si inneschi una XSS che altrimenti sarebbe stata innocua.
Il traduttore di Microsoft viene innescato dalla funzione startPageTranslation:

Microsoft.JS.startPage

Translation(originalLang, targetLang, shouldTranslate

FullPageInOneGo, “domTranslator
SessionId”, “token”, onSuccess
Callback, onTranslateApiCalled,
onErrorCallback);

E come hanno scoperto alcuni ricercatori, non pulisce correttamente il codice, per cui quando reinserisce le stringhe tradotte nella pagina web, finisce con l’includere eventuali segmenti script senza fare alcun escape e quindi portando il browser stesso a eseguirli. Un esempio di codice HTML “vulnerabile” è il seguente:

<b><u>Testo apparentemente innocuo </u></b>

<br>

<br>

“><img src=x onerror=alert(1)>

<br>

Solitamente, questo tipo di codice viene bloccato dalla maggioranza dei siti, che fanno correttamente l’escape dell’HTML e quindi fanno apparire tutto questo nella pagina come se fosse del normale testo (in altre parole, si vedono i simboli < e >). Se un utente prova a inserire questo tipo di codice in un campo di testo, il server probabilmente farà l’escape, rendendo inefficace il tentativo di XSS. Il traduttore di Microsoft, però, prende il testo e (dopo averlo tradotto) lo rimette nella pagina, ma come codice HTML senza escape dei tag HTML. Questo annulla qualsiasi controllo sull’HTML che può essere fatto dai siti web; quindi, rischia di rendere eseguibile la porzione di codice: alert(1)

In questo caso, naturalmente, si limita a far apparire una messagebox. Ma potrebbe teoricamente essere qualsiasi istruzione Javascript.

ENTITÀ DELLA VULNERABILITÀ

Per poter sfruttare questa vulnerabilità l’attaccante non deve in realtà fare molto, se non depositare il codice XSS su qualche sito web usando un campo di testo, come i commenti di un blog o un post pubblico (anche su un social network, come Facebook). Il resto è, sostanzialmente, nelle mani dell’utente: deve trattarsi di un utente che utilizza Microsoft Edge, e che ha bisogno di tradurre una qualche pagina. Cosa in realtà non troppo rara: se il malintenzionato ha pubblicato il suo codice su un sito in lingua inglese molti utenti italiani proveranno a tradurlo. E bisogna comunque considerare che Edge, pur non avendo la popolarità di Chrome, è molto diffuso. Si tratta in linea di massima di un attacco poco pilotabile, perché non si può controllare più di tanto chi sarà esattamente la vittima, né quando farà scattare la XSS. Ma la grande diffusione di Edge e del suo traduttore lo rendono, sui grandi numeri, un attacco che garantisce il successo almeno in qualche caso. Insomma, per il pirata si tratta più che altro di avere pazienza.

LA SOLUZIONE

La notevole diffusione di Edge ha fatto sì che questa vulnerabilità venisse dichiarata pubblicamente soltanto poche settimane fa, mentre era stata segnalata a Microsoft da più di un anno. L’azienda ha infatti probabilmente voluto assicurarsi di essere riuscita a patchare la maggior parte delle versioni di Edge in circolazione. Se avete Edge installato sul vostro pc, quindi, è probabile che qualche aggiornamento automatico di Windows abbia già installato la correzione. L’ultima versione vulnerabile è la 91.0.864.59, quindi tutte le successive includono già la patch al traduttore automatico. Una buona norma, se per qualche motivo non si può aggiornare il browser, consiste nel tenere disabilitata la traduzione automatica, e richiederla solo quando è necessario, così almeno si può vedere la pagina prima di tradurla e capire se c’è qualcosa di strano.

Leggi anche: “Il malware che ruba dal browser“