A01:2021 – Broken Access Control

Fattori

CWEs corrispondenti	Tasso di incidenza Max	Tasso di incidenza Medio	Sfruttabilità pesata	Impatto Medio	Copertura Max	Copertura media	Occorrenze Totali	CVE Totali
34	55.97%	3.81%	6.92	5.93	94.55%	47.72%	318,487	19,013

Panoramica

Salendo dalla quinta posizione, il 94% delle applicazioni è stato testato per una qualche forma di broken access control con un tasso medio di incidenza del 3,81%, e ha il maggior numero di occorrenze nel dataset con oltre 318k. Le Common Weakness Enumerations (CWE) incluse sono CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-201: Exposure of Sensitive Information Through Sent Data, e CWE-352: Cross-Site Request Forgery.

Descrizione

Il controllo degli accessi fa rispettare la policy in modo che gli utenti non possano agire al di fuori dei permessi previsti. Problematiche su questo tipo di controllo tipicamente portano alla divulgazione non autorizzata di informazioni, alla modifica o alla distruzione di tutti i dati o l'esecuzione di una funzione di business al di fuori dei limiti dell'utente. Le vulnerabilità più comuni che affliggono i meccanismi di controllo degli accessi includono:

Violazione del principio del minimo privilegio o deny by default, dove l'accesso dovrebbe essere concesso solo per particolari capabilities, ruoli o utenti, ma è disponibile a chiunque.
Bypassare i controlli di accesso modificando l'URL (modifica dei parametri o navigazione forzata), lo stato interno dell'applicazione o la pagina HTML, o utilizzando uno strumento di attacco che modifica le richieste API.
Permettere la visualizzazione o la modifica dell'account di qualcun altro, fornendo il suo identificatore unico (insecure direct object references)
Accesso all'API con controlli di accesso mancanti per POST, PUT e DELETE.
Elevazione dei privilegi. Agire come un utente senza essere loggato o agire come amministratore quando si è svolto il login come utente base.
Manipolazione dei metadati, come la riproduzione o la modifica di un JSON Web Token (JWT), o un cookie o un campo nascosto manipolati per elevare i privilegi o abusare dell'invalidazione del JWT.
La configurazione errata di CORS permette l'accesso all'API da origini non autorizzate/non fidate.
Forzare la navigazione verso pagine autenticate come utente non autenticato o a pagine privilegiate come utente base.

Come prevenirla

Il controllo degli accessi è efficace solo nel codice lato server o API server-less, dove l'attaccante non può modificare i meccanismi di controllo dell'accesso o i metadati.

Tranne che per le risorse pubbliche, applicare il principio di deny by default.
Implementare i meccanismi di controllo dell'accesso una volta sola e riutilizzarli in tutta l'applicazione, incluso limitare l'utilizzo di Cross-Origin Resource Sharing (CORS).
I controlli di accesso del Model dovrebbero imporre la proprietà dei record piuttosto che accettare che l'utente possa creare, leggere, aggiornare o cancellare qualsiasi record.
I requisiti unici dei vincoli di business di un'applicazione dovrebbero essere applicati nei modelli di dominio.
Disabilitare il directory listing del server web e garantire che i metadati dei file (ad es, .git) e i file di backup non siano presenti all'interno delle web roots.
Registrare i fallimenti dei meccanismi di controllo dell'accesso, avvisare gli amministratori quando appropriato (ad es, fallimenti ripetuti).
Implementare meccanismi di rate limiting per accesso all'API e al controller per minimizzare il danno da strumenti di attacco automatizzati.
Gli identificatori di sessione stateful dovrebbero essere invalidati sul server dopo il logout. I token JWT stateless dovrebbero piuttosto essere di breve durata in modo che la finestra di opportunità per un attaccante sia ridotta al minimo. Per i JWT di lunga durata è altamente raccomandato di seguire gli standard OAuth per revocare l'accesso.

Gli sviluppatori e lo staff di QA dovrebbero includere test funzionali di controllo dell'accesso e test di integrazione.

Esempi di scenari d'attacco

Scenario #1: L'applicazione usa dati non verificati in una chiamata SQL che sta accedendo alle informazioni dell'account:

 pstmt.setString(1, request.getParameter("acct"));
 ResultSet results = pstmt.executeQuery( );

Un attaccante modifica semplicemente il parametro 'acct' del browser per inviare numero di conto a piacere. Se il parametro non è verificato correttamente, l'attaccante può accedere all'account di qualsiasi utente.

 https://example.com/app/accountInfo?acct=notmyacct

Scenario #2: Un attaccante forza semplicemente la navigazione verso gli URL di destinazione. Sono richiesti i diritti di amministratore per accedere alla pagina di amministrazione.

 https://example.com/app/getappInfo
 https://example.com/app/admin_getappInfo

Se un utente non autenticato può accedere a una delle due pagine, è una falla. Se un non amministratore può accedere alla pagina dell'amministratore, questa è una falla.