Vulnerabilità nel controllo degli accessi
Controllo degli accessi
Per controllo degli accessi intendiamo l'insieme delle regole utilizzate da un'applicazione per definire chi può effettuare determinate operazioni e/o accedere a determinati dati. Tali regole sono fortemente legate al concetto di autenticazione, ovvero il meccanismo che permette all'applicazione di determinare chi stia effettuando le richieste in arrivo e, di conseguenza, i permessi che deve o non deve avere garantiti. La presenza di vulnerabilità nel meccanismo di controllo degli accessi può portare a conseguenza critiche per l'applicazione, poiché potrebbero permettere a utenti non privilegiati di effettuare operazioni di accesso o modifica di dati altrui, violandone la confidenzialità.
Si possono distinguere tre principali categorie di controllo degli accessi: verticale, orizzontale e dipendente dal contesto.
Controllo degli accessi verticale
Il controllo degli accessi verticale permette l'utilizzo di funzionalità, o l'accesso a risorse, sensibili solo a specifici tipi di utente.
L'esempio classico è quello in cui ci sono due tipi di utenti, quelli comuni e gli amministratori. I secondi avranno accesso a funzionalità di gestione dell'applicazione che non devono però essere accessibili per gli utenti comuni.
Controllo degli accessi orizzontale
Il controllo degli accessi orizzontale restringe l'accesso a determinate risorse a utenti specifici. In questo caso, utenti dello stesso tipo hanno accesso solo a una frazione delle risorse disponibili; in particolare, a quelle che li riguardano.
Si pensi al caso di una banca: ogni utente può accedere solo al proprio estratto conto, e non a quello di tutti gli altri utenti.
Controllo degli accessi dipendente dal contesto
Il controllo degli accessi dipendente dal contesto restringe l'accesso a risorse e funzionalità in base allo stato in cui l'applicazione si trova. Viene solitamente utilizzato per impedire agli utenti di compiere azioni in un ordine differente da quello preposto.
Si pensi al caso di un negozio online: un utente non può modificare il contenuto di un ordine dopo averlo cambiato.
Vulnerabilità
Dato che il controllo degli accessi rappresenta una parte fondante di una qualsiasi applicazione web, se presentano dei bug allora potrebbero portare a vulnerabilità e problemi di sicurezza.
Escalation dei privilegi
L'escalation dei privilegi, analogamente alla terminologia introdotta sopra, si può dividere in verticale e orizzontale.
L'escalation dei privilegi verticale si verifica quando un utente di un qualsiasi tipo è in grado di ottenere accesso a risorse e funzionalità che non dovrebbero essergli disponibili.
L'esempio più classico si ritrova nei contesti in cui un utente non amministratore è in grado di accedere alle informazioni che dovrebbero essere visibili solo a un amministratore.
Se, ad esempio, un'applicazione mostra dati sensibili sull'endpoint /admin, limitandosi a non inserire un link al suddetto, ma senza filtrarne gli accessi sulla base di una previa autenticazione, un utente potrebbe indovinare il nome di tale endpoint e accedervi pur non avendo ruolo amministrativo.
L'escalation di privilegi orizzontale, invece, si verifica quando un utente è in grado di accedere ai dati riservati di un altro utente. Ad esempio, un negozio online potrebbe permettere a un utente di accedere allo storico degli ordini di un altro utente.
Insecure direct object references (IDOR)
Spesso l'escalation di privilegi orizzontale si verifica a causa della presenza di IDOR, ovvero un tipo di vulnerabilità del controllo degli accessi che è presente quando un'applicazione utilizza input utente per accedere direttamente a delle risorse.
Si pensi a un sito che permette di visionare i propri dati tramite una richiesta GET su /mydata?userid=123:
un attaccante potrebbe tentare di accedere ai dati di altri utenti semplicemente cambiando il valore associato a userid; se l'applicazione non verifica che l'utente richiedente tali dati corrisponde allo userid che invia, l'attacco avrebbe successo.
Questo tipo di attacco si può verificare anche se l'id dell'utente è uno uuid (ovvero l'utente è identificato da un valore univoco non prevedibile); sicuramente risulta più difficile per l'attaccante "indovinare" id validi, ma nel caso in cui riesca a ottenere l'id di un altro utente, ne otterrebbe anche tutti i dati sensibili.
Vulnerabilità nei processi a più passaggi
Si possono verificare vulnerabilità nel controllo degli accessi di un processo a più passaggi se, ad esempio, un'applicazione assume che l'aver effettuato il controllo ad un passaggio precedente significhi aver reso sicuri anche i passaggi successivi.
Pensiamo ad esempio a un'applicazione che permette di modificare i dati di un utente tramite i seguenti passaggi (implementati tipicamente con più richieste al server):
- Caricare il form contenente i dati dell'utente
- Inviare i cambiamenti
- Visionare i cambiamenti effettuati e confermare
Nel caso in cui il controllo degli accessi sia correttamente applicato solo nei primi due passaggi, assumendo che l'utente possa raggiungere il terzo solo passando dai primi due, un attaccante potrebbe inviare la richiesta relativa al terzo passaggio ignorando i primi ottenendo così un accesso non autorizzato alla funzione di modifica utente.
Mitigazioni
Le vulnerabilità nel controllo degli accessi possono essere mitigate applicando i seguenti principi:
- Mai basare i controlli di accesso solo sull'offuscamento: "nascondere" un endpoint non basta a non renderlo accessibile.
- Vietare l'accesso a tutte le risorse che non debbano necessariamente essere accessibili pubblicamente.
- Quando possibile, utilizzare un singolo meccanismo di controllo degli accessi per tutta l'applicazione, così da non dover gestire casi di sovrapposizione tra due o più meccanismi separati.
- Nel codice, rendere obbligatoria la dichiarazione del tipo di accesso permesso per ogni risorsa, e di default negare l'accesso.
- Inoltre, è importante eseguire audit e test del sistema di controllo degli accessi al fine di verificarne l'efficacia.