IDOR e BOLA

Perche e Importante

IDOR e BOLA rappresentano la classe di vulnerabilita API piu impattante in assoluto. Broken Object Level Authorization ha occupato la prima posizione nella OWASP API Security Top 10 fin dalla sua prima pubblicazione nel 2019 e ha mantenuto quella posizione nell'aggiornamento del 2023.

La ragione e semplice: le API espongono identificatori di oggetti negli URL, nei body delle richieste e nei parametri di query. Se il server non verifica che l'utente richiedente sia proprietario o abbia il permesso di accedere all'oggetto referenziato, qualsiasi utente autenticato puo accedere ai dati di qualsiasi altro utente manipolando quegli identificatori.

Le vulnerabilita BOLA nel mondo reale hanno esposto milioni di record utente attraverso piattaforme che spaziano dai servizi finanziari ai social media. La vulnerabilita e particolarmente pericolosa perche:

• Non richiede strumenti o competenze speciali per essere sfruttata
• Una singola vulnerabilita puo esporre i dati di ogni utente
• Spesso bypassa la crittografia poiche l'attaccante e autenticato
• Lo sfruttamento automatizzato puo raccogliere interi database

Per i penetration tester e i bug bounty hunter, il testing BOLA/IDOR e una delle prime competenze da padroneggiare perche produce il maggior numero di risultati validi in rapporto allo sforzo.

Come Funzionano IDOR e BOLA

Il Pattern di Base

Un'applicazione assegna identificatori agli oggetti: profili utente, ordini, fatture, file, messaggi o qualsiasi altra risorsa. Quando un utente richiede un oggetto, l'API riceve l'identificatore e restituisce i dati corrispondenti. La vulnerabilita esiste quando l'API verifica l'autenticazione (questo utente e autenticato?) ma salta l'autorizzazione (questo utente ha il permesso di accedere a questo specifico oggetto?).

Tipi Comuni di Identificatori

• ID numerici sequenziali: /api/users/1001 fino a /api/users/9999. Facili da enumerare.
• UUID: /api/orders/a3f8e2c1-.... Piu difficili da indovinare ma non impossibili se trapelano in altre risposte.
• Valori codificati: Identificatori in Base64 o hashati che a volte possono essere decodificati o predetti.
• Chiavi composite: /api/org/5/user/12. Identificatori multipli che necessitano ciascuno di controlli di autorizzazione.

Metodologia di Testing

1. Creare due account con ruoli o proprieta diversi
2. Catturare tutte le richieste API che contengono identificatori di oggetti
3. Scambiare gli identificatori tra gli account
4. Testare tutti i metodi HTTP (GET per la lettura, PUT/PATCH per l'aggiornamento, DELETE per la rimozione)
5. Controllare sia il codice di stato della risposta che il body della risposta

Prevenzione

La soluzione richiede controlli di autorizzazione lato server su ogni richiesta che accede a una risorsa specifica dell'utente. Il server deve verificare che l'utente autenticato abbia il permesso di accedere allo specifico oggetto referenziato nella richiesta, non solo che sia presente un token di autenticazione valido.

• Implementare controlli di permesso a livello di oggetto nel middleware API o nel livello di accesso ai dati
• Non affidarsi mai all'oscurita (UUID) come sostituto dell'autorizzazione
• Utilizzare riferimenti indiretti dove possibile (mappare token specifici della sessione agli ID reali del database lato server)
• Registrare tutti i pattern di accesso e generare alert sugli accessi orizzontali tra i confini degli utenti