Controllo accessi basato sulle Capacità (Capabilities)
La sicurezza basata sulle capacità può fornirci una soluzione alternativa per il controllo degli accessi che utilizza una struttura diversa da quella che vediamo nelle ACL.
Laddove le ACL definiscono l’autorizzazione in base a una determinata risorsa, un’identità e un insieme di autorizzazioni, tutte generalmente contenute in un file di qualche tipo, le capacità sono orientate all’uso di un token che controlla il nostro accesso.
Possiamo pensare a un token come un analogo al badge personale che potremmo usare per aprire la porta di un edificio e accedere.
Abbiamo una porta e molte persone hanno un token che la aprirà, ma possiamo avere diversi livelli di accesso.
Laddove una persona possa accedere all’edificio solo durante l’orario lavorativo nei giorni feriali, un’altra persona può avere il permesso di entrare nell’edificio a qualsiasi ora del giorno in qualsiasi giorno della settimana.
È interessante notare che, nei sistemi basati sulle capacità, il diritto di accedere a una risorsa si basa interamente sul possesso del token e non su chi lo possiede.
Come per l’esempio del badge, se dovessimo dare il nostro badge a qualcun altro, sarebbe in grado di usarlo per accedere all’edificio con qualsiasi set di autorizzazioni di cui disponiamo.
In un sistema basato sulle capacità, le applicazioni possono condividere con altre applicazioni il token che definisce il loro livello di accesso.
Nei sistemi non basati sulle capacità, che utilizzano gli ACL per gestire le autorizzazioni, potremmo riscontrare un problema di sostituzione, a causa del modo in cui viene implementato il controllo degli accessi.
Diamo un’occhiata a un attacco basato su questo principio.
Problema della sostituzione
Il problema della sostituzione (o rappresentanza errata) è un tipo di attacco comune nei sistemi che utilizzano ACL anziché capabilities.
Il punto cruciale avviene quando il software con accesso a una risorsa ha un livello di autorizzazione maggiore per accedere alla risorsa rispetto all’utente che controlla il software.
Se noi, come utenti, riusciamo a ingannare il software facendo un uso improprio del suo maggiore livello di autorità, possiamo potenzialmente effettuare un attacco.
Discuteremo alcuni esempi pratici di attacchi che sfruttano tale problema più avanti in questa sezione.
Diversi attacchi specifici, molti dei quali lato client, possono trarre vantaggio pratico dal problema di sostituzione.
Questi spesso implicano l’inganno dell’utente a compiere un’azione quando pensa davvero di fare qualcosa di completamente diverso.
Due degli usi più comuni di un tale attacco sono gli attacchi lato client come la falsificazione di richieste tra siti (CSRF) e il clickjacking.
Gli attacchi lato client sono attacchi che sfruttano i punti deboli delle applicazioni in esecuzione sul computer gestite direttamente dall’utente, spesso indicato come client.
Questi attacchi possono assumere la forma di codice inviato tramite il browser Web, che viene quindi eseguito sul computer locale, file PDF non validi, immagini o video con codice di attacco incorporato o altri moduli.
Negli ultimi anni, i fornitori di software sono diventati più consapevoli di tali attacchi e hanno iniziato a creare misure difensive nel loro software, ma nuovi attacchi compaiono regolarmente.
CSRF è un attacco che abusa dell’autorità del browser sul computer dell’utente.
Se l’autore dell’attacco è a conoscenza o può indovinare un sito Web in cui l’utente potrebbe essere già autenticato, ad esempio un sito molto comune come Amazon, può tentare di eseguire un attacco CSRF.
Possono farlo incorporando un collegamento in una pagina Web o in un’e-mail basata su HTML, generalmente un collegamento a un’immagine del sito a cui desidera indirizzare l’utente a sua insaputa.
Quando l’applicazione tenta di recuperare l’immagine nel collegamento, esegue anche i comandi aggiuntivi che l’autore dell’attacco ha incorporato in essa.
Nel nostro esempio, quando il browser dell’utente carica l’immagine da Amazon, fintanto che il cookie di autenticazione per Amazon non è scaduto, l’attaccante potrebbe indurre l’utente a effettuare un acquisto a sua insaputa, consentendo così all’attaccante di vendere più copie del libro nella foto ricevuta via email (per esempio).
Il clickjacking, noto anche come redressing dell’interfaccia utente, è un attacco lato client particolarmente subdolo ed efficace che sfrutta alcune delle funzionalità di rendering delle pagine disponibili nei browser Web più recenti.
Per effettuare un attacco clickjacking, l’attaccante deve legittimamente controllare o aver preso il controllo di una parte del sito Web (senza che i proprietari del sito siano consapevoli che il loro sito sta attualmente servendo malware) che deve essere utilizzata come veicolo di attacco.
L’autore dell’attacco costruisce o modifica il sito per posizionare uno strato invisibile su qualcosa su cui il client farebbe normalmente clic, in modo che il client esegua un comando diverso da quello che pensa di eseguire effettivamente.
Un esempio molto comune lo troviamo nei vari siti di streaming gratis online, dove prima di poter vedere un film (quando possibile), spesso al posto del pulsante “Play” si clicca su una maschera quasi invisibile ad occhi inesperti.
Il clickjacking può essere utilizzato per indurre il cliente a fare acquisti, modificare i permessi nelle proprie applicazioni, condividere informazioni sui propri sistemi operativi o eseguire altre attività nefaste.
Se dovessimo utilizzare le capabilities invece degli ACL per gestire le autorizzazioni, questi attacchi non sarebbero possibili.
Nel caso di ciascuno di questi attacchi, l’uso improprio dei permessi non sarebbe possibile, perché l’attaccante non sarebbe in grado di abusare dell’autorità dell’utente senza avere accesso al token che gli consentirebbe di farlo.
