Autore: Davide Cavallini

Visitando la classifica “Owasp Top Ten” noteremo subito che il “Broken Access Control” è il primo problema della lista. Ciò significa che è la vulnerabilità attualmente più diffusa nel mondo.

E talmente diffuso che è presente nel 94% delle applicazioni testate.

Ma che cos’è?

Facciamo un esempio semplice

Facciamo finta che in comune per prendere la carta d’identità bastasse dire il proprio nome e cognome. Io mi chiamo Davide Cavallini. Arrivando dall’impiegato comunale dovrei dire che mi chiamo “Davide Cavallini” per ottenere la mia carta d’identità.

Facciamo finta che dicessi ci chiamarmi “Giuseppe Ciambelli”. L’impiegato non avendo l’obbligo di controllare la mia identità mi consegnerebbe la carta di Giuseppe Ciambelli. Questo sarebbe un grave errore, perchè consentirebbe ad una persona che non ne avrebbe il diritto di accedere a dati altrui.

Se poi tornassimo al comune ogni giorno dando un nome diverso, otterremmo i dati di tutti i cittadini del comune. Questa sarebbe un’orrenda violazione della privacy!

Comprendiamo meglio le Broken Access Control

Il broken access control in realtà non è SEMPRE una vera e propria vulnerabilità.  Si tratta in realtà di una “disclosure”, cioè una “fuoriuscita” di dati causata dalla mancanza di policy adeguate.

Esempio pratico: Nel sito web abbiamo la route

profile/{id} 

Significa che andando su http://dominio.com/profile/1 dovremmo vedere i dati dell’utente con id del profilo 1. Normalmente solo l’utente stesso che possiede l’id 1 dovrebbe poter vedere i suoi stessi dati. Se però mancasse la policy, ad esempio:

if($profile->id===route()->get(id)) { 
return view; 
} else { 
return redirect(‘404’); 
}

Qualsiasi altro utente potrebbe vedere i dati sensibili di tutti i profili registrati. In questo caso sarebbe un problema per la privacy degli utenti. I rischi di costose cause e di dover dare risarcimenti cospicui sarebbero molto elevati.

I problemi di Broken Access Control possono essere presenti in molte forme:

può capitare che la pagina del profilo sopra menzionata permetta anche di modificare la password dell’utente. In questo caso la “debolezza” del B.A.C. si trasformerebbe in una vera e propria vulnerabilità.

Altro problema può essere l’elevazione di privilegi. Agire come amministratore quando invece si è solo utenti normali sarebbe un grave problema.

Potrebbero esserci anche problemi nelle API. Un problema comune è il fatto di poter fare richieste da parte di client non autorizzati. Questo problema è denominato Cross Origin Request Sharing Failture (CORS). Oppure può essere consentito fare POST, PUT o DELETE, quindi modificare i propri modelli, a chiunque.

Può accadere che modificando i cookie possa essere modificato il proprio livello di privilegi. 

Esempio: 

privilegeLevel=registered

cambiato con:

privilegeLevel=administrator

che permette di diventare amministratori nel sito.

Può essere consentita la modifica di token JWT per accedere come un altro utente. A volte è possibile cambiare l’algoritmo di firma del JWT che viene restituito come risposta. Poi con una firma non valida e i dati di un altro utente è possibile accedere al sito in modo malevolo.

Consigliamo sempre di utilizzare dei frameworks con strutture che obblighino a definire le policy per ogni azione e route. 

Altro passo importante è avvalersi sempre delle consulenze di pentester esperti. L’analisi di sicurezza di server e applicativi web è fondamentale al giorno d’oggi.

Ricordate: LA CYBERSECURITY PRIMA DI TUTTO!