Come descritto nei post precedenti, i web workers consentono di eseguire task in background all’interno del browser.
Una dei possibili utilizzi è quello di utilizzarli per memorizzare in maniera sicura i token di accesso ad api.
Access token, refresh token e id token sono utilizzati per autorizzare gli utenti nell’accesso di api: in particolare il refresh token consente di ottenere un nuovo access token, al momento della scadenza di quest’ultimo.
In tutti gli scenari web, dove memorizzare i token rappresenta un punto fondamentale per la sicurezza dell’intera applicazione.
Archiviazione dell’access token
Solitamente i token vengono conservati all’interno della session storage o nel local storage del browser. Entrambe queste tecniche sono però interessate da attacchi di tipo Cross-Site Scripting.
Nella lettura sulla sicurezza informatica vengono sconsigliate la memorizzazione all’interno della sessione o nel local storage, preferendo la memorizzazione all’interno di un cookie di sessione.
Lo svantaggio di questa tecnica è rappresentato dal fatto che un cookie di sessione può essere utilizzato solo con il dominio che ha impostato il cookie.: nel caso in cui il dominio che si autentica è differente dal domino in cui risiedono le risorse, l’utilizzo del cookie di sessione non funzionerà.
L’archiviazione dei token all’interno della memoria del browser è la scelta maggiormente consigliata: considerando gli script javascript in esecuzione all’interno del browser viene garantito che eventuali librerie di terze parti non abbiamo la possibilità di compromettere i token stessi.
In particolare, possono essere implementate tecniche di javascript closures, ovvero la possibilità di implementare proprietà private, un pò come avviene nei linguaggi di programmazione ad oggetti.
In questo modo viene garatantito che una variabile privata non possa essere letta all’esterno della funzione stessa. Questo approccio garantisce che una variabile privata possa essere interecettata da librerie di terze parti.
Ma tutto questo non impedisce ad eventuali script di riuscire ad intercettare e leggere le richieste http, e quindi intercettare i vari token, scambiati negli header. Nel post precedente abbiamo analizzato come sia possibile utilizzare gli interceptor all’interno di richieste axios.
In questo scenario entrano in gioco i web workers.
Web Worker e access token
Considerando che sono dei thread separati che girano in background, consentono di estere le funzionalità di sviluppo all’interno dei browser. Javascript non è un linguaggio di programmazione multithread: l’utilizzo dei web worker consente di avere a disposizione i thread anche in ambiente web.
I web worker vengono eseguiti in un contesto differente rispetto a quello del thread principale. Questo implica che non ci sia comunicazione tra il contesto del thread principale e quello del web workers.
L’unico modo per poter realizzzare un meccanismo di comunicazione è tramite lo scambio di messaggi, la cui implementazione viene lasciata allo sviluppatore. Il modello di comunicazione può anche essere un semplice modello di tipo richiesta/risposta.
Questo meccanismo impedisce a librerie di terze parti di impossessari dell’access token gestito dal web worker: non essendoci richieste verso il web worker, non ci saranno neppure risposte quindi la possibilità di impossessarsi dell’access token.
Gli attacchi di tipo Cross-Site Scripting non sono quindi possibili.
Archiettura e possibile scenario
Il meccanismo che permette di ottenere l’access token e di memorizzarlo all’interno del web worker si basa sul modello in cui è il web worker stesso che invia un messaggio di richiesta autenticazione al server ed una volta ottenuta la risposta, memorizza al suo interno il token.
Per gli accessi successivi alle risorse, il thread principale dovrà effettuare una richiesta al web worker che a sua volta la inoltrerà verso il server delle risorse. Durante la fase di inoltro verrà aggiunto l’access token.
Questo tipo di approccio è molto simile a quello di un proxy: possiamo considerare il web worker come un proxy posizionato tra il thread principale dell’applicazione web ed il server delle risorse.
Uno scenario simile può essere paragonato all’utilizzo di interceptors all’interno di axios.
In entrambi i casi tutto si svolge in maniera trasparente per l’utente finale.
Un utente malintenzionato potrebbe comunque sfruttare un problema di vulnerabilità legato al fatto che il web worker indirizza le sue richiesta aggiungendo a tutte l’access token.
Utilizzando un URL destinazione malevolo diventa piuttosto semplice ottenere l’access token.
Per evitare questo tipo di poblemi si possono limitare gli URL destinazione a cui il web worker potrà inviare le richieste.