Le 10 principali API di sicurezza OWASP: autorizzazione a livello di proprietà di oggetti non funzionanti
Introduzione
Le API sono essenziali per consentire la comunicazione e lo scambio di dati tra diversi sistemi. Tuttavia, la sicurezza delle API è fondamentale per prevenire accessi non autorizzati e violazioni dei dati. Una vulnerabilità che rappresenta un rischio significativo è la Broken Object Property Level Authorization. In questo articolo, esploreremo gli agenti di minaccia, i vettori di attacco, i punti deboli della sicurezza, gli impatti e le misure preventive relative all'API 3:2023 Broken Object Property Level Authorization.
Agenti di minaccia e vettori di attacco
Gli agenti di minaccia in questo contesto sono in genere utenti o aggressori che interagiscono con gli endpoint delle API. I vettori di attacco implicano la manipolazione delle richieste API per ottenere l'accesso non autorizzato alle proprietà sensibili degli oggetti o modificarne i valori. Protocolli diversi possono richiedere tecniche specifiche, come la creazione di richieste o l'utilizzo di strumenti automatici, per identificare e manipolare le proprietà degli oggetti.
debolezza della sicurezza
Il punto debole della sicurezza risiede nella convalida inadeguata dell'accesso degli utenti a proprietà specifiche dell'oggetto tramite endpoint API. Le API possono esporre proprietà sensibili degli oggetti che non dovrebbero essere accessibili agli utenti o consentire loro di modificare proprietà a cui non dovrebbero avere accesso. L'analisi delle risposte delle API e delle tecniche di fuzzing può rivelare informazioni sensibili e proprietà nascoste. La mancanza di una convalida adeguata può portare ad accessi non autorizzati, divulgazione dei dati, perdita di dati, danneggiamento dei dati, escalation dei privilegi o acquisizione dell'account.
Impatti
L'accesso non autorizzato a proprietà private o sensibili degli oggetti può comportare l'esposizione dei dati, danni alla reputazione e perdita di fiducia. Le modifiche non autorizzate alle proprietà critiche possono portare alla perdita o al danneggiamento dei dati. Può verificarsi un'escalation dei privilegi, garantendo agli aggressori livelli di accesso e controllo più elevati. L'acquisizione parziale o totale dell'account può inoltre comportare rischi significativi per gli utenti interessati.
Scenari di attacco di esempio
Scenario #1: Applicazione finanziaria
Un endpoint API in un'applicazione finanziaria consente agli utenti di recuperare il saldo del proprio conto. Tuttavia, l'endpoint non riesce a convalidare l'autorizzazione dell'utente ad accedere ai saldi di altri utenti. Considera la seguente chiamata API:
OTTIENI /api/account/balance? ID utente = 123456
Un utente malintenzionato può sfruttare questa vulnerabilità modificando ID utente
parametro per accedere al saldo di un altro utente:
OTTIENI /api/account/balance? ID utente = 987654
Per evitare ciò, l'API deve verificare che l'utente richiedente disponga dei privilegi necessari per accedere al saldo dell'account specificato.
Scenario #2: sito di e-commerce
Un sito di e-commerce fornisce un endpoint API per l'aggiornamento dell'indirizzo di spedizione di un utente. Tuttavia, l'endpoint consente agli utenti di aggiornare l'indirizzo di qualsiasi altro utente senza la dovuta autorizzazione. Considerate la seguente chiamata API:
INSERISCI /api/utente/indirizzo
Tipo di contenuto: application/json
{
«ID utente»: «123456",
«indirizzo»: «123 Main St»
}
Un utente malintenzionato può sfruttare questa vulnerabilità modificando ID utente
parametro per aggiornare l'indirizzo di qualcun altro:
INSERISCI /api/utente/indirizzo
Tipo di contenuto: application/json
{
«ID utente»: «987654",
«indirizzo»: «456 Elm St»
}
Per evitare ciò, l'API deve verificare che l'utente richiedente disponga dell'autorizzazione per aggiornare l'indirizzo dell'utente specificato.
Scenario #3: Piattaforma di social media
Una piattaforma di social media consente agli utenti di pubblicare commenti sui profili di altri utenti. Tuttavia, l'endpoint API non riesce a far rispettare l'autorizzazione corretta, consentendo a qualsiasi utente di pubblicare commenti per conto di un altro utente. Considera la seguente chiamata API:
POST /api/profiles/123456/commenti
Tipo di contenuto: application/json
{
«text»: «Ottimo profilo!»
}
Un utente malintenzionato può sfruttare questa vulnerabilità modificando l'endpoint per pubblicare un commento sul profilo di un altro utente:
POST /api/profiles/987654/commenti
Tipo di contenuto: application/json
{
«text»: «Profilo violato!»
}
Per evitare ciò, l'API deve convalidare che l'utente richiedente abbia l'autorità per pubblicare commenti sul profilo dell'utente specificato.
Implementando adeguati controlli di autorizzazione e convalidando l'accesso degli utenti a risorse specifiche, queste vulnerabilità possono essere mitigate, garantendo l'integrità e la sicurezza del sistema.
Misure di prevenzione
Per mitigare i rischi associati alla Broken Object Property Level Authorization, implementa le seguenti misure preventive:
1. Convalida l'accesso
Assicurati che gli utenti abbiano un accesso appropriato alle proprietà degli oggetti esposte tramite gli endpoint API. Esponi solo le proprietà a cui gli utenti dovrebbero poter accedere in base ai loro privilegi.
2. Restituzione selettiva dei dati
Scegliete le proprietà specifiche da restituire invece di esporre tutte le proprietà dell'oggetto. Evita di utilizzare metodi generici che potrebbero esporre inavvertitamente dati sensibili.
3. Evita l'assegnazione di massa
Evita di associare automaticamente gli input del client a variabili di codice, oggetti interni o proprietà degli oggetti. Consenti solo le modifiche alle proprietà che devono essere aggiornate dal client e convalida le modifiche rispetto alle regole di autorizzazione.
4. Convalida della risposta basata su schema
Implementa un meccanismo di convalida della risposta basato su schema per applicare i dati previsti restituiti dai metodi API. Definisci e applica le strutture dei dati per garantire coerenza e sicurezza.
5. Esposizione minima dei dati
Mantieni le strutture di dati restituite al minimo richiesto dai requisiti aziendali o funzionali dell'endpoint. Evita di esporre informazioni non necessarie che potrebbero comportare rischi per la sicurezza.
Conclusione
API 3:2023 Broken Object Property Level Authorization è una vulnerabilità significativa che può portare ad accessi non autorizzati, violazioni dei dati e altri impatti dannosi. Comprendendo gli agenti delle minacce, i vettori di attacco, i punti deboli della sicurezza e i potenziali impatti, le organizzazioni possono adottare misure proattive per prevenire e mitigare questi rischi. Implementando una corretta convalida degli accessi, la restituzione selettiva dei dati, evitando l'assegnazione di massa, utilizzando la convalida delle risposte basata su schemi e riducendo al minimo l'esposizione dei dati, gli sviluppatori di API possono garantire la sicurezza e l'integrità dei loro sistemi, proteggendo i dati degli utenti e mantenendo la fiducia degli utenti.