Broken Access Control: individuare, correggere e prevenire la vulnerabilità

Il Broken Access Control rappresenta una delle vulnerabilità più critiche e diffuse nel panorama della sicurezza informatica web, collocandosi costantemente tra le principali minacce identificate da OWASP. Questa debolezza consente agli attaccanti di accedere, modificare o eliminare dati senza autorizzazione, con conseguenze potenzialmente disastrose per le aziende, che spaziano dalla perdita di dati alla compromissione dei sistemi.

Comprendere a fondo questa minaccia e implementare strategie di mitigazione efficaci è fondamentale per proteggere le risorse web.

1. Che cos’è il Broken Access Control?
2. Esempio di Broken Access Control
3. Come identificare una vulnerabilità di Broken Access Control
4. Come correggere una vulnerabilità di Broken Access Control
5. Si può prevenire il Broken Access Control?

Che cos’è il Broken Access Control?

Il Broken Access Control è una vulnerabilità web che si manifesta quando un’applicazione web non riesce a gestire correttamente le autorizzazioni, permettendo così a utenti non autorizzati di accedere a risorse, modificare dati o eseguire operazioni per le quali non dispongono di permessi.
Questa vulnerabilità può assumere molteplici forme e si inserisce in diversi contesti applicativi, come ambienti web, API e sistemi distribuiti.

Le cause alla base di un Broken Access Control sono spesso riconducibili a una mancata implementazione delle policy di sicurezza o a configurazioni incomplete nei meccanismi di autenticazione e autorizzazione.

Tra i principali scenari che danno origine al Broken Access Control troviamo gli Insecure Direct Object References (IDOR), nei quali un’applicazione espone identificatori di oggetti direttamente nei parametri URL o nelle API senza adeguati controlli di autorizzazione.
Questo scenario permette a un attaccante di manipolare tali parametri per accedere a risorse che non gli appartengono. Un altro esempio comune è la violazione del principio del minimo privilegio, per cui utenti standard possono ottenere accesso a risorse o funzionalità amministrative.
L’assenza di controlli di accesso rigorosi in endpoint API come POST, PUT o DELETE rappresenta un’ulteriore vulnerabilità, poiché consente a utenti non autorizzati di eseguire modifiche o eliminazioni non consentite.

Le vulnerabilità legate al Broken Access Control possono includere anche la manipolazione dei metadati, come la modifica di token JWT (JSON Web Token) o cookie, al fine di elevare i privilegi e ottenere accesso a funzionalità riservate. Questo è particolarmente pericoloso in quanto spesso un attaccante riesce a modificare i livelli di autorizzazione o simulare sessioni altrui. Una configurazione errata di Cross-Origin Resource Sharing (CORS) può inoltre permettere l’accesso ad applicazioni da fonti non fidate, esponendo i dati sensibili ad attacchi esterni.

L’impatto di questa vulnerabilità può essere estremamente serio. Se non gestito adeguatamente, il Broken Access Control, può condurre a violazioni.

Esempio di Broken Access Control

Escalation di privilegi tramite manipolazione dei parametri URL in un portale di gestione documenti

In un portale web che si occupa della gestione di documenti di un’organizzazione, gli utenti accedono ai propri file tramite URL che contengono un numero di ientificazione unico del documento (un id). Ogni utente ha un livello di accesso specifico, come “utente base” o “admin”, che limita l’accesso e le azioni possibili sui singoli documenti. Ad esempio, un utente base può visualizzare e modificare solo i documenti del proprio ufficio, mentre un utente amministratore (o admin) ha permessi di accesso e controllo su tutti i file.

Il sistema identifica i documenti tramite un parametro URL del tipo https://example.com/documents/view?id=12345. Quando un utente base desidera visualizzare un proprio documento, il sistema genera un link con l’ID specifico del file.

La vulnerabilità
L’applicazione si affida esclusivamente al valore dell’ID nell’URL per determinare quale documento caricare, senza verificare che l’utente abbia l’autorizzazione specifica per accedere a quel particolare file. Questo significa che un utente con privilegi base potrebbe semplicemente cambiare il parametro id nell’URL per tentare di accedere a documenti di altri utenti, come https://example.com/documents/view?id=67890.
Se l’applicazione non esegue un controllo di autorizzazione sul lato server per assicurarsi che l’utente abbia il diritto di visualizzare il documento con l’ID 67890, l’utente base potrebbe accedere a file riservati senza autorizzazione.

Perché questa vulnerabilità è pericolosa
Chiaramente in queto articolo abbiamo semplificato di molto il concetto, ma lo abbiamo fatto per permettervi di capire il concetto di massima a cui si riferisce questa falla di sicurezza. Gli effetti di una gestione errata di questo processo portano un attaccante o anche semplicemente un utente indesiderato ad ottenere il controllo più ampio sui documenti altrui semplicemente modificando l’ID dei file nell’URL. Questa vulnerabilità, nota come Insecure Direct Object Reference (IDOR).

Come identificare una vulnerabilità di Broken Access Control

L’identificazione del Broken Access Control richiede un approccio sistematico, che integra strumenti automatizzati con analisi manuale per una comprensione approfondita delle dinamiche applicative. I test di sicurezza, come l’analisi dinamica (DAST) e l’analisi statica (SAST), consentono di rilevare comportamenti anomali nelle applicazioni e di identificare porzioni di codice che potrebbero esporre vulnerabilità nei controlli di accesso.

I penetration test, mirati su account con privilegi diversi, permettono di individuare possibili bypass, elevazione di privilegi e accessi non autorizzati a dati sensibili. L’ispezione manuale del codice può inoltre svelare configurazioni errate o controlli mancanti, specialmente sugli endpoint esposti attraverso API.

Come correggere una vulnerabilità di Broken Access Control

Per correggere una vulnerabilità di Broken Access Control, è essenziale implementare controlli rigorosi di autorizzazione a livello server, garantendo che le risorse e le operazioni siano accessibili solo agli utenti corretti e con privilegi adeguati.
Di seguito sono illustrati i passaggi tecnici fondamentali per correggere le vulnerabilità:

1. Implementazione del principio di “Deny by Default”
   Ogni endpoint e risorsa devono adottare il principio del deny by default, dove l’accesso è negato a tutti gli utenti, a meno che non sia espressamente autorizzato. Ciò significa che i permessi devono essere assegnati in modo esplicito e selettivo, privilegiando configurazioni “opt-in” per gli accessi e assicurando che nessuna risorsa sia accessibile in modo predefinito.
2. Controllo dell’accesso a livello di modello
   I controlli di accesso dovrebbero essere integrati direttamente, associando ogni risorsa (ad esempio, record di database) a un proprietario o a un gruppo di utenti autorizzati. Ogni volta che una risorsa viene richiesta, il sistema deve verificare che l’utente richiedente sia autorizzato a interagire con quel record specifico. Questo assicura che ogni interazione con le risorse avvenga in modo controllato e conforme ai permessi di accesso.
3. Utilizzo di token di accesso sicuri e limitati temporalmente
   Gli accessi API e alle risorse contenute dovrebbero essere controllati tramite token d’accesso sicuri (ad esempio, JWT). I token dovrebbero avere una durata breve e essere soggetti a invalidazione forzata in caso di logout dell’utente o cambiamenti nei privilegi.
4. Centralizzazione dei meccanismi di autorizzazione
   I controlli di accesso devono essere centralizzati in un modulo dedicato di autorizzazione, che gestisca in modo uniforme tutte le richieste.
   Questo modulo dovrebbe essere integrato con un framework di autorizzazione robusto, come RBAC (Role-Based Access Control) o ABAC (Attribute-Based Access Control), per garantire una gestione granulare dei privilegi.
5. Validazione di tutti i parametri e delle richieste lato server
   I parametri delle richieste, inclusi URL, form fields e parametri API, devono essere validati esclusivamente lato server.
   Per le applicazioni web, è cruciale che i parametri identificativi, come ID utente o ID delle risorse, non siano utilizzabili per bypassare i controlli di accesso, e che ogni richiesta di accesso a una risorsa includa una verifica a livello server dei permessi dell’utente richiedente.
6. Monitoraggio nei meccanismi di accesso
   Integrare un sistema di log dettagliato che registri ogni tentativo fallito di accesso e l’attività degli utenti, in particolare per quanto riguarda le operazioni amministrative. I tentativi ripetuti di bypass dei controlli di accesso devono generare avvisi automatici per il team di sicurezza, facilitando un rapido intervento. Le informazioni di audit possono anche essere utili per identificare pattern di attacco o vulnerabilità specifiche, contribuendo al miglioramento continuo dei controlli di sicurezza.
7. Revisione e audit periodico del codice
   I controlli di accesso devono essere verificati regolarmente tramite audit di sicurezza. Racomandiamo sempre l’esecuzione di assessment per il Broken Access Control, testando le risorse più sensibili e verificando che tutti i controlli di accesso siano implementati correttamente.

Si può prevenire il Broken Access Control?

La prevenzione del Broken Access Control deve includere l’implementazione di framework sicuri e la gestione dei controlli di accesso esclusivamente lato server, dove gli attaccanti non possono interferire con le policy. L’adozione di framework che forzano la definizione di policy di sicurezza per ogni endpoint contribuisce a ridurre il rischio di errore umano. I test funzionali e di integrazione dovrebbero sempre includere verifiche sui controlli di accesso per garantire che ogni endpoint sia protetto secondo le specifiche di sicurezza. Infine, le revisioni periodiche del codice e gli audit regolari dei meccanismi di controllo permettono di mantenere l’applicazione conforme alle policy di sicurezza aziendali e di ridurre il rischio di esposizione ai tentativi di accesso non autorizzato.