Autorizzazione non corretta

L'autenticazione dimostra chi è l'utente. L'autorizzazione stabilisce che cosa gli è consentito fare.

Un'autorizzazione non corretta significa che il sistema permette agli utenti di fare o vedere cose che non dovrebbero.

BOLA è l'acronimo di Broken Object Level Authorization.

È il principale rischio per le API: l'API verifica che l'utente abbia effettuato l'accesso, ma non che l'oggetto specifico richiesto gli appartenga davvero.

Immagini che l'account in uso sia l'utente 100.

Se modifica l'ID e il server risponde comunque, ha appena letto gli ordini di qualcun altro. Questo è BOLA.

Gli sviluppatori spesso si fidano dell'ID contenuto nella richiesta.

Dimenticano di verificare che l'utente autenticato possieda effettivamente quell'oggetto. La soluzione consiste nel verificare la proprietà a ogni richiesta.

Un altro difetto è BFLA: Broken Function Level Authorization.

Un utente normale chiama un'azione riservata agli amministratori e l'operazione riesce, perché l'endpoint non verifica mai il ruolo dell'utente.

Consideri una route amministrativa:

Se un utente normale può chiamarla con successo, l'API non ha applicato correttamente l'accesso basato sui ruoli.

Alcune API associano ciecamente i campi della richiesta a un record.

Un utente potrebbe aggiungere un campo come role=admin all'aggiornamento del profilo e aumentare silenziosamente i propri privilegi.

Non faccia mai affidamento sul client per nascondere pulsanti o campi.

Il server deve applicare ogni decisione di autorizzazione, perché gli aggressori inviano direttamente le richieste, aggirando completamente l'interfaccia utente.

Gli ID sequenziali rendono BOLA facile da sfruttare.

L'utilizzo di identificatori casuali come un UUID non sostituisce i controlli di autorizzazione, ma elimina il semplice attacco che consiste nell'indovinare il numero successivo.

Un'API sicura nega per impostazione predefinita.

L'accesso viene consentito solo quando una regola esplicita lo autorizza. In questo modo, un controllo dimenticato si risolve con un rifiuto sicuro anziché con una fuga di dati.

I bug di autorizzazione sono difficili da individuare, quindi è necessario testarli intenzionalmente.

Provi ad accedere ai dati di un altro utente utilizzando il proprio token. Se l'operazione riesce, ha individuato un difetto grave da correggere.

Un'API conferma che l'utente ha effettuato l'accesso, ma restituisce il record di un altro utente quando viene modificato l'ID. Di quale difetto si tratta?

Un'autorizzazione non corretta consente agli utenti di accedere a ciò a cui non dovrebbero avere accesso. Presti attenzione a BOLA, BFLA e all'assegnazione di massa.

Applichi i controlli di proprietà e di ruolo sul server, neghi per impostazione predefinita e testi deliberatamente l'autorizzazione.