Riepilogo Tecnico: Broken Object Level Authorization nel Mondo Reale

Enunciato del Problema

Broken Object Level Authorization (BOLA) è costantemente classificata come la vulnerabilità più critica nell'elenco OWASP API Security Top 10. Nonostante la sua rilevanza, la letteratura esistente relativa alla BOLA rimane quasi interamente concettuale. Le attuali linee guida si basano su esempi illustrativi, narrazioni di singoli casi o modelli di controllo degli accessi astratti, mancando di un resoconto empirico di come la BOLA si manifesti negli ambienti di produzione. Esiste un significativo divario nella comprensione della distribuzione reale dei pattern BOLA, dei tipi specifici di identificatori coinvolti, delle azioni compiute dagli attaccanti e dei settori più esposti. Inoltre, la relazione tra il meccanismo (Insecure Direct Object Reference, o IDOR) e la causa radice (BOLA) è frequentemente confusa nella letteratura per la pratica professionale e nell'etichettatura dei bug bounty, portando a potenziali errori di misurazione nelle valutazioni di sicurezza.

Metodologia

Questo documento presenta un'analisi empirica su larga scala della BOLA utilizzando i report di bug bounty resi pubblici come fonte primaria di dati.

• Fonte dei Dati: Lo studio ha utilizzato il dataset di divulgazione pubblica Hacktivity di HackerOne, interrogando i report etichettati con "IDOR" o "Improper Access Control" tra gennaio 2021 e gennaio 2026.
• Campionamento: È stato costruito un quadro di campionamento riproducibile di 200 report.
• Filtraggio: È stato applicato un filtro di inclusione a tre criteri per garantire che i report facessero riferimento a un oggetto concreto specifico, dimostrassero un accesso trans-confinale all'oggetto di un altro utente/tenant e contenessero dettagli tecnici. Ciò ha ridotto il campione a 122 report eleggibili.
• Classificazione: È stata impiegata una procedura di completamento dello schema assistita da LLM utilizzando una tassonomia BOLA raffinata a sei famiglie. L'LLM ha agito come assistente di estrazione vincolato secondo criteri giudicati da umani. Output a bassa confidenza e casi limite specifici sono stati revisionati da valutatori umani per garantire l'accuratezza.
• Dataset Finale: Dei 200 candidati iniziali, 107 report sono stati completamente classificati. Di questi, 84 (78,5%) sono stati confermati come BOLA in scope, mentre 23 (21,5%) sono stati considerati fuori scope o non classificabili secondo criteri rigorosi.

Contributi Chiave

1. Tassonomia Raffinata: Il documento introduce una tassonomia BOLA a sei famiglie basata su divulgazioni reali, progettata per ridurre l'ambiguità tra valutatori. Le famiglie sono:
   • Direct Object Reference BOLA: Accesso non autorizzato tramite sostituzione diretta o prevedibile dell'identificatore.
   • Action-Level Object BOLA: Azioni di modifica dello stato non autorizzate (cancellazione, modifica, attivazione) sull'oggetto di un altro utente.
   • Tenant Isolation BOLA: Violazioni dell'accesso trans-organizzativo.
   • Workflow-Context BOLA: Bypass dell'autorizzazione dipendenti dallo stato dell'oggetto (ad es. bozza, archiviato, eliminato).
   • Chained Disclosure BOLA: Sfruttamento che richiede un passaggio preliminare per raccogliere un identificatore da un endpoint separato.
   • Object Rebinding BOLA: Manipolazione dei campi che identificano la proprietà nella richiesta per modificare l'ambito di autorizzazione.
2. Quadro Metodologico: È documentata una metodologia di classificazione riproducibile che combina l'assistenza LLM con una revisione umana strutturata per la replicazione.
3. Caratterizzazione del Rumore delle Etichette: Lo studio quantifica la divergenza tra l'etichettatura della piattaforma (IDOR/Improper Access Control) e la BOLA confermata in scope, rivelando un significativo rumore nelle etichette.
4. Baseline Empirica: Il documento fornisce distribuzioni quantitative su sei dimensioni: famiglia, tipo di azione, direzione di autorizzazione, settore industriale, formato dell'identificatore e meccanismo di sfruttamento.

Risultati Chiave

Sulla base dei 84 report confermati in scope:

• Distribuzione per Famiglia: Action-Level Object BOLA (41,7%) e Direct Object Reference BOLA (36,9%) sono le due famiglie dominanti, che insieme rappresentano il 78,6% dei casi. Ciò indica che le azioni di modifica dello stato non autorizzate sono prevalenti quanto, o più prevalenti di, le violazioni di accesso in sola lettura.
• Direzione di Autorizzazione: I fallimenti orizzontali (tra pari) dominano con l'85,7%. Tuttavia, i fallimenti verticali (da utente ad amministratore) rappresentano il 11,9%, un pattern spesso sottorappresentato nelle linee guida per gli sviluppatori ma con un impatto elevato.
• Tipi di Azione: Sebbene la Lettura non autorizzata sia l'azione singola più comune (52,4%), le azioni di modifica dello stato (Modifica, Cancellazione, Attivazione) collettivamente rappresentano il 46,4% dei casi.
• Formati degli Identificatori: Gli interi sequenziali rimangono il tipo di identificatore più frequentemente riscontrato (36,9% dei casi con formato noto). Tuttavia, i formati non sequenziali (UUID, ID codificati, nomi utente, email) rappresentano il 39,2% dei casi con formato noto, dimostrando che gli identificatori opachi non eliminano il rischio BOLA.
• Meccanismi di Sfruttamento: La enumerazione di interi sequenziali è il meccanismo più prevalente (22,6%). I GraphQL Global IDs (GID) sono sistematicamente sfruttati tramite un pattern di decodifica/incremento/ricodifica, poiché gli interi sottostanti rimangono sequenziali nonostante la codifica base64.
• Rumore delle Etichette: Solo il 42,0% dei 200 report campionati etichettati come IDOR/Improper Access Control è stato confermato come BOLA in scope. Circa il 21,5% dei report classificati è risultato fuori scope secondo criteri rigorosi, indicando che il conteggio delle etichette su piattaforme come HackerOne sovrastima significativamente il segnale specifico della BOLA.
• Settore e Gravità: SaaS & Produttività domina il dataset (44,0%). Sebbene la gravità mediana sia Media, il 35,7% dei report è valutato Alto o Critico, con Action-Level Object BOLA che porta valutazioni di gravità sproporzionatamente elevate.

Significato e Affermazioni

Il documento afferma di colmare il divario tra le definizioni concettuali di BOLA e la realtà empirica. La sua rilevanza risiede nel:

• Sfidare le Linee Guida Prevalenti: I risultati suggeriscono che le attuali linee guida per la pratica professionale e gli esempi OWASP potrebbero sottovalutare Action-Level Object BOLA e Vertical BOLA, concentrandosi eccessivamente su scenari di riferimento diretto a oggetti in sola lettura e orizzontali.
• Implicazioni per i Protocolli di Test: Lo studio sostiene che i protocolli standard di test di sicurezza delle API, che spesso si concentrano sull'accesso trans-utente tramite metodi GET, sono insufficienti. I test efficaci devono includere operazioni di modifica dello stato (POST, PUT, DELETE) e scenari di privilegi verticali.
• Implicazioni per la Progettazione: La persistenza di interi sequenziali in programmi di sicurezza maturi (ad es. GitHub, DoD, HackerOne) e la sfruttabilità dei GraphQL Global IDs suggeriscono che l'offuscamento degli identificatori da solo non è un controllo sufficiente. L'autorizzazione deve essere rivalutata quando gli stati degli oggetti cambiano (Workflow-Context).
• Accuratezza della Misurazione: Il documento fornisce prove che fare affidamento sulle etichette delle piattaforme di bug bounty per le stime della prevalenza delle vulnerabilità introduce un rumore significativo, rendendo necessaria una classificazione più rigorosa per una valutazione accurata del rischio.

Gli autori concludono che il loro lavoro fornisce un vocabolario per scenari di attacco realistici, linee guida sui pattern concreti per gli sviluppatori e una baseline empirica per i ricercatori che costruiscono strumenti di rilevamento. Notano esplicitamente le limitazioni relative al bias di selezione (copertura di HackerOne), all'eterogeneità della profondità delle divulgazioni e alla concentrazione di report da programmi specifici (ad es. HackerOne e DoD), qualificando i loro risultati come robusti solo laddove questi fattori siano presi in considerazione tramite un'analisi ponderata per programma.