Nel cuore del browser dei sistemi di Apple batte un sistema comune a più del 50% dei browser utilizzati sul pianeta: WebKit. Questo ovviamente non per esclusivo merito di Apple (che non detiene quella fascia di mercato), ma per il fatto che questo sistema è frutto della collaborazione di differenti società di sviluppo software. Ricordiamo tra queste Samsung (con il suo Dolphin ed in generale il suo sistema Tizen), Amazon (con il suo Kindle), KDE e fino al 2013 anche Google (con il suo Chrome), che però ha creato un suo sviluppo autonomo del medesimo progetto (ora denominato Blink). 

Naturalmente il progetto comune non contempla un destino comune, in quanto le differenti tecnologie su cui è destinato necessitano di sviluppo autonomo, aprendo lo spazio a che problematiche differenti affliggano le differenti implementazioni. 

È il caso appunto del problema di confidenzialità che è stato riscontrato in questo sistema su dispositivi Apple, che date le convergenze delle tecnologie nei differenti sistemi non ha più importanza indicare se macOS, iOS o iPadOS, ma bensì la generazione: si tratta di generazione 15 per melafonini e pad e 12 per sistemi desktop. 

Tutto nasce da una questione: i programmi utente, pure sul web, necessitano di memorizzare (localmente) un gran numero di informazioni offline. La tecnologia WebStorage è sempre stata utile a questo fine, ma ha dei limiti (non è possibile recuperare ordinatamente le chiavi, non è possibile eseguire ricerche sui valori, non è possibile conservare più informazioni per una medesima chiave). In WebKit è stata dunque introdotta un’altra tecnologia per il superamento dei limiti di WebStorage, denominata IndexedDB: questo è un vero e proprio database transazionale orientato agli oggetti Javascript. 

Fin qui tutto in regola, se non fosse per il fatto che è stato scoperto che l’implementazione di questo efficace strumento vìoli uno dei principi della sicurezza lato client del Web: la SOP (Same-Origin-Policy), un meccanismo di sicurezza che limita l’interazione tra javascript e documenti appartenenti a (derivanti dal download da) origini differenti. Una origine in questo contesto viene definita dallo schema (protocollo), nome di host (dominio) e porta espresse nell’URL utilizzato per accedere alla risorsa (documento o script). 

Come viene violato dunque questo principio? L’implementazione che mostra questa debolezza genera un database su ciascun frame, tab o finestra del medesimo browser quando un sito web interagisce con l’API IndexedDB, ossia ne crea una copia (seppur vuota) con medesimo nome: questo anche quando i frame, tab o finestre non sono derivanti dalla medesima origine. Questo consentirebbe ad un agente di minaccia che sia su un’altra origine, ossia su uno di questo frame, tab o finestra, di ottenere il nome di questo database, che, visto il modo in cui viene utilizzato da molti siti, crea un grosso problema di confidenzialità. 

Infatti siti come youtube.com, keep.google.com e calendar.google.com (tanto per restare nella galassia Google) pongono lo Google User ID dell’utente autenticato come parte del nome del database, che evidentemente (come nome) sarebbe comunque disponibile in tutti gli altri frame, tab e finestre (di altre origini). Nel caso Google, ad esempio, questo identificatore è quello che consente di utilizzare le API di Google, e dunque recuperare informazioni pubbliche dell’account dell’utente, come per esempio l’immagine del profilo.  

Il caso non è unico, in quanto molti altri siti utilizzano identificatori univoci specifici dell'utente nei nomi dei database, consentendo così, non tanto l’identificazione dell’utente, ma quanto la correlazione dei suoi account tra differenti siti. La lista dei siti che fanno questo è consistente: alibaba.com, anchor.fmapp.slack.com, *bloomberg.com, boston.com, calendar.google.com, *cnet.com, computerworld.com, ctvnews.ca, developers.google.com, dropbox.com, globalnews.ca, huffingtonpost.com, indiegogo.com, instagram.com, keep.google.com, *netflix.com, *nymag.com, pexels.com, rollingstone.com, standard.co.uk, stitcher.com, theglobeandmail.com, timeout.com, twitter.com, vk.com, weather.com, web.whatsapp.com, xbox.com, youtube.com. 

Tutto questo è aggravato dall’assenza completa di necessità di interazione utente perché ciò accada. 

L’effetto massimo naturalmente si ha quando Safari consenta una navigazione su più schede e finestre; ad esempio le finestre private limiterebbero la navigazione su una sola scheda, ma è evidente che visitare più siti nella medesima scheda riporterebbe il problema in evidenza. 

Il bug (#233548) è ancora ristretto all’accesso sul sistema bugzilla del progetto WebKit, il che vuol dire che non è pubblicamente risolto: Apple ha dichiarato di aver trovato soluzione, ma ovviamente occorrerà attendere la patch. 

Intanto, per chi volesse provare se il proprio Safari è affetto dal problema (e sapere quando verrà risolto) può visitare il sito https://safarileaks.com , dove viene eseguito un test su questa vulnerabilità. 

Tweet