Le 10 principali API di sicurezza OWASP: autorizzazione a livello di funzione interrotta
Introduzione
Le API (Application Programming Interfaces) svolgono un ruolo cruciale nello sviluppo di applicazioni moderne, consentendo a diversi sistemi software di comunicare e scambiare dati. Tuttavia, le API possono introdurre vulnerabilità di sicurezza se non implementate e protette correttamente. Una di queste vulnerabilità è la Broken Function Level Authorization, che può portare all'accesso non autorizzato a funzionalità e dati sensibili all'interno di un'applicazione. In questo articolo, esploreremo gli agenti di minaccia, i vettori di attacco, i punti deboli della sicurezza e gli impatti associati alla Broken Function Level Authorization. Forniremo anche tre esempi con codice per dimostrare come questa vulnerabilità può essere sfruttata e discuteremo delle misure preventive.
Comprendere l'autorizzazione a livello di funzione non funzionante
Agenti di minaccia e vettori di attacco
Gli agenti di minaccia negli attacchi Broken Function Level Authorization sono in genere aggressori che mirano a ottenere l'accesso non autorizzato a funzionalità privilegiate o a dati sensibili all'interno di un'applicazione. I vettori di attacco implicano lo sfruttamento della mancanza di adeguati controlli di autorizzazione per gli endpoint API. Gli aggressori possono inviare chiamate API legittime a endpoint a cui non dovrebbero avere accesso, sia come utenti anonimi che come utenti normali non privilegiati.
debolezza della sicurezza
Il punto debole di sicurezza di Broken Function Level Authorization risiede nell'implementazione impropria dei controlli di autorizzazione per funzioni o risorse. I controlli di autorizzazione vengono generalmente gestiti tramite configurazione o a livello di codice, in cui i diritti di accesso vengono concessi in base a ruoli, gruppi o gerarchie utente. Tuttavia, l'implementazione di controlli adeguati può essere un'attività complessa, specialmente nelle applicazioni moderne con numerosi ruoli, gruppi e complesse gerarchie di utenti. Questa complessità rende più facile per gli aggressori scoprire i difetti nelle API, poiché le API sono più strutturate e l'accesso a diverse funzioni è spesso più prevedibile.
Impatti
Lo sfruttamento delle vulnerabilità di Broken Function Level Authorization può avere gravi impatti tecnici e specifici sull'azienda. Gli aggressori che ottengono l'accesso non autorizzato a funzionalità sensibili possono portare a varie conseguenze, come ad esempio:
- Divulgazione dei dati: gli aggressori possono accedere a informazioni riservate o dati sensibili che dovrebbero essere accessibili solo agli utenti autorizzati. Ciò può comportare l'esposizione di dati personali, segreti commerciali o altre informazioni critiche.
- Perdita di dati: l'accesso non autorizzato alle funzioni amministrative può potenzialmente portare alla perdita o al danneggiamento dei dati. Gli aggressori potrebbero manipolare o eliminare i dati, causando danni significativi all'applicazione e ai suoi utenti.
- Interruzione del servizio: sfruttando le funzioni amministrative, gli aggressori possono interrompere il normale funzionamento dell'applicazione. Ciò può comportare interruzioni del servizio, perdita di disponibilità e potenziali perdite finanziarie per l'azienda.
Data la gravità di questi impatti, è fondamentale identificare e risolvere le vulnerabilità di Broken Function Level Authorization nelle API.
L'API è vulnerabile?
Per determinare se un'API è vulnerabile alla Broken Function Level Authorization, è necessaria un'analisi completa del meccanismo di autorizzazione. È essenziale considerare la gerarchia degli utenti, i diversi ruoli o gruppi nell'applicazione e porre domande pertinenti. Ecco alcune domande chiave da considerare:
- Un utente normale può accedere agli endpoint amministrativi?
- Un utente può eseguire azioni sensibili a cui non dovrebbe avere accesso semplicemente cambiando il metodo HTTP?
- Un utente di un gruppo può accedere a una funzione che dovrebbe essere esposta solo agli utenti di un altro gruppo indovinando l'URL e i parametri dell'endpoint?
È importante non dare per scontato che un endpoint API sia regolare o amministrativo in base esclusivamente al percorso dell'URL. Mentre gli sviluppatori possono scegliere di esporre la maggior parte degli endpoint amministrativi in un percorso relativo specifico, ad esempio /api/amministratori
, è comune trovare endpoint amministrativi combinati con endpoint regolari in altri percorsi relativi, come /api/utenti
.
Effettuare un'analisi approfondita dei meccanismi di autorizzazione dell'API e porre queste domande può aiutare a identificare potenziali vulnerabilità.
Scenari di attacco di esempio
Esaminiamo tre scenari di attacco che dimostrano come è possibile sfruttare le vulnerabilità di Broken Function Level Authorization.
Scenario #1: Privilegi di amministratore non autorizzati
Durante il processo di registrazione di un'applicazione che consente solo agli utenti invitati di partecipare, un'applicazione mobile attiva una chiamata API a
recupera i dettagli dell'invito:
OTTIENI /api/invites/ {invite_guid}
La risposta contiene un JSON con dettagli sull'invito, inclusi il ruolo e l'email dell'utente. Un utente malintenzionato duplica la richiesta, manipola il metodo HTTP e l'endpoint e invia una richiesta dannosa per creare un nuovo invito con privilegi di amministratore:
POST /api/invites/new
{
«email»: "attacker@somehost.com «,
«ruolo» :"admin»
}
Poiché l'endpoint responsabile della creazione degli inviti non implementa i controlli di autorizzazione appropriati, l'aggressore crea con successo un account amministratore e ottiene l'accesso completo al sistema.
Scenario #2: accesso non autorizzato ai dati degli utenti
Un'API contiene un endpoint che deve essere esposto solo agli amministratori:
OTTIENI /api/admin/v1/utenti/tutti
Questo endpoint restituisce i dettagli di tutti gli utenti dell'applicazione. Tuttavia, non implementa controlli di autorizzazione adeguati a livello di funzione. Un utente malintenzionato, che ha familiarità con la struttura dell'API, effettua un'ipotesi plausibile e accede a questo endpoint, esponendo i dati sensibili degli utenti.
Scenario #3: Indovinare gli URL degli endpoint
In questo scenario, l'API ha diversi endpoint per l'esportazione dei dati degli utenti in base ai gruppi di utenti. Un utente malintenzionato tenta di accedere a un endpoint che dovrebbe essere esposto solo agli utenti del gruppo Y, ma indovina erroneamente l'URL e i parametri:
/api/v1/utenti/export_all
Sfruttando questa falla nell'autorizzazione a livello di funzione, l'aggressore ottiene l'accesso non autorizzato alla funzionalità di esportazione destinata agli utenti del gruppo Y.
Questi scenari illustrano i rischi reali associati alle vulnerabilità di Broken Function Level Authorization e sottolineano l'importanza di implementare controlli di autorizzazione adeguati.
Come prevenire l'interruzione dell'autorizzazione a livello di funzione
La prevenzione dell'interruzione dell'autorizzazione a livello di funzione richiede l'implementazione di solidi meccanismi di autorizzazione e l'esecuzione di valutazioni di sicurezza approfondite. Ecco alcune misure preventive:
- Modulo di autorizzazione coerente: l'applicazione deve disporre di un modulo di autorizzazione coerente e facile da analizzare richiamato da tutte le funzioni aziendali. Questo modulo dovrebbe imporre un adeguato controllo degli accessi negando tutti gli accessi per impostazione predefinita e richiedendo concessioni esplicite per ruoli specifici per accedere a ciascuna funzione.
- Rivedi gli endpoint API: rivedi regolarmente i tuoi endpoint API per potenziali difetti di autorizzazione a livello di funzione. Considera la logica aziendale dell'applicazione e la gerarchia dei gruppi di utenti. Assicurati che le funzioni sensibili o i controllori amministrativi implementino i controlli di autorizzazione appropriati in base al gruppo e al ruolo dell'utente.
- Controller astratto amministrativo: implementa un controller astratto amministrativo che gestisca i controlli delle autorizzazioni per tutte le funzioni amministrative. Tutti i controllori amministrativi devono ereditare da questo controller astratto per garantire un'autorizzazione coerente e corretta tra gli endpoint amministrativi.
Seguendo queste misure preventive, puoi ridurre significativamente il rischio di vulnerabilità di autorizzazione a livello di funzione non funzionante nelle tue API.
Conclusione
L'interruzione dell'autorizzazione a livello di funzione nelle API può portare ad accessi non autorizzati a funzionalità privilegiate e dati sensibili, con potenziali conseguenze gravi per aziende e utenti. Comprendere gli agenti delle minacce, i vettori di attacco, i punti deboli della sicurezza e gli impatti associati a questa vulnerabilità è fondamentale per creare API sicure. Analizzando i meccanismi di autorizzazione, ponendo domande pertinenti e implementando misure preventive, gli sviluppatori possono mitigare i rischi e garantire la corretta sicurezza delle proprie API. Ricorda che la protezione delle tue API è un processo continuo e che le valutazioni di sicurezza regolari sono essenziali per rimanere protetti dalle minacce in evoluzione.