A01:2025 Broken Access Control

Contesto.

Mantenendo la sua posizione al #1 nel Top Ten, il 100% delle applicazioni testate è risultato avere qualche forma di broken access control. Tra le CWE degne di nota vi sono CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-201: Exposure of Sensitive Information Through Sent Data, CWE-918 Server-Side Request Forgery (SSRF) e CWE-352: Cross-Site Request Forgery (CSRF). Questa categoria ha il maggior numero di occorrenze nei dati contribuiti e il secondo più alto numero di CVE correlati.

Tabella dei punteggi.

CWE Mappate	Tasso Massimo di Incidenza	Tasso Medio di Incidenza	Copertura Massima	Copertura Media	Exploit Medio Ponderato	Impatto Medio Ponderato	Totale Occorrenze	Totale CVE
40	20,15%	3,74%	100,00%	42,93%	7,04	3,84	1.839.701	32.654

Descrizione.

Il controllo degli accessi applica policy tali per cui gli utenti non possono agire al di fuori dei propri permessi previsti. I fallimenti portano tipicamente a divulgazione non autorizzata di informazioni, modifica o distruzione di tutti i dati, o all'esecuzione di una funzione di business al di fuori dei limiti dell'utente. Le vulnerabilità comuni di controllo degli accessi includono:

Violazione del principio del minimo privilegio, comunemente noto come deny by default, dove l'accesso dovrebbe essere concesso solo per determinate capacità, ruoli o utenti, ma è disponibile a chiunque.
Aggiramento dei controlli di accesso modificando l'URL (parameter tampering o force browsing), lo stato interno dell'applicazione o la pagina HTML, oppure 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 univoco (insecure direct object references).
Un'API accessibile con controlli di accesso mancanti per POST, PUT e DELETE.
Escalation di privilegi. Agire come utente senza essere autenticati o acquisire privilegi superiori a quelli previsti per l'utente autenticato (es. accesso admin).
Manipolazione dei metadati, come il replay o la manomissione di un token di controllo degli accessi JSON Web Token (JWT), un cookie o un campo nascosto manipolato per elevare i privilegi, o l'abuso dell'invalidazione JWT.
La configurazione errata di CORS consente l'accesso alle API da origini non autorizzate o non attendibili.
Force browsing (indovinare URL) verso pagine autenticate come utente non autenticato o verso pagine privilegiate come utente standard.

Come prevenire.

Il controllo degli accessi è efficace solo se implementato in codice lato server attendibile o in API serverless, dove l'attaccante non può modificare il controllo degli accessi o i metadati.

Tranne per le risorse pubbliche, negare l'accesso per default.
Implementare i meccanismi di controllo degli accessi una sola volta e riutilizzarli in tutta l'applicazione, inclusa la minimizzazione dell'utilizzo del Cross-Origin Resource Sharing (CORS).
I modelli di controllo degli accessi devono applicare la proprietà dei record piuttosto che consentire agli utenti di creare, leggere, aggiornare o eliminare qualsiasi record.
I requisiti di limite di business univoci dell'applicazione devono essere applicati dai modelli di dominio.
Disabilitare il directory listing del web server e garantire che i metadati dei file (es. .git) e i file di backup non siano presenti nelle web root.
Registrare i fallimenti del controllo degli accessi, inviare alert agli amministratori quando appropriato (es. fallimenti ripetuti).
Implementare limiti di frequenza sull'accesso ad API e controller per minimizzare i danni degli strumenti di attacco automatizzati.
Gli identificatori di sessione con stato devono essere invalidati sul server dopo il logout. I token JWT senza stato devono avere una durata breve per minimizzare la finestra di opportunità per un attaccante. Per JWT con durata più lunga, considerare l'uso di refresh token e seguire gli standard OAuth per revocare l'accesso.
Utilizzare toolkit o pattern ben consolidati che forniscono controlli degli accessi semplici e dichiarativi.

Gli sviluppatori e il personale QA devono includere test funzionali del controllo degli accessi nei test unitari e di integrazione.

Scenari di attacco di esempio.

Scenario #1: L'applicazione utilizza dati non verificati in una chiamata SQL che accede alle informazioni dell'account:

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

Un attaccante può semplicemente modificare il parametro 'acct' del browser per inviare qualsiasi numero di account desiderato. Se non verificato correttamente, l'attaccante può accedere all'account di qualsiasi utente.

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

Scenario #2: Un attaccante costringe semplicemente il browser a puntare a URL specifici. Sono necessari 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, si tratta di una falla. Se un non-amministratore può accedere alla pagina di amministrazione, si tratta di una falla.

Scenario #3: Un'applicazione gestisce tutto il controllo degli accessi nel front-end. Sebbene l'attaccante non riesca ad accedere a https://example.com/app/admin_getappInfo a causa del codice JavaScript in esecuzione nel browser, può semplicemente eseguire:

$ curl https://example.com/app/admin_getappInfo

dalla riga di comando.