Diventa Autore per CoreTech | Scopri di più
30/06/20 CoreTech Blog
I riferimenti a oggetti diretti non sicuri (IDOR) sono un problema di sicurezza informatica che si verifica quando uno sviluppatore di applicazioni Web utilizza un identificatore per l'accesso diretto a un oggetto di implementazione interno ma non fornisce alcun controllo di accesso aggiuntivo e / o controlli di autorizzazione. Ad esempio, una vulnerabilità IDOR potrebbe verificarsi se l'URL di una transazione potesse essere modificato tramite l'input dell'utente sul lato client per mostrare dati non autorizzati di un'altra transazione.
Nell'elenco Top 10 di OWASP (Open Web Application Security Project) nel 2013, i riferimenti a oggetti diretti non sicuri sono stati trattati come un problema separato classificato al numero 4 (vedere OWASP Top 10 2013 A4 ). Tuttavia, nell'ultima Top 10 di OWASP nel 2017, questa categoria è stata fusa nella categoria A5: controllo accessi non funzionante .
La maggior parte delle applicazioni Web utilizza ID semplici per fare riferimento a oggetti. Ad esempio, un utente in un database verrà generalmente indicato tramite l'ID utente. Lo stesso ID utente è la chiave primaria della colonna del database che contiene informazioni sull'utente e viene generato automaticamente. L'algoritmo di generazione delle chiavi del database è molto semplice: di solito utilizza il prossimo intero disponibile. Gli stessi meccanismi di generazione dell'ID del database vengono utilizzati per tutti gli altri tipi di record del database.
L'approccio sopra descritto è legittimo ma non raccomandato perché potrebbe consentire all'autore dell'attacco di elencare tutti gli utenti. Se è necessario mantenere questo approccio, lo sviluppatore deve almeno assicurarsi assolutamente che per accedere alle risorse sia necessario più di un semplice riferimento. Ad esempio, supponiamo che l'applicazione Web visualizzi i dettagli della transazione utilizzando il seguente URL:
https://www.example.com/transaction.php?id=74656
Un hacker malintenzionato potrebbe tentare di sostituire il valore del parametro id 74656 con altri valori simili, ad esempio:
https://www.example.com/transaction.php?id=74657
La transazione 74657 potrebbe essere una transazione valida appartenente a un altro utente. L'hacker malintenzionato non dovrebbe essere autorizzato a vederlo. Tuttavia, se lo sviluppatore commettesse un errore, l'utente malintenzionato visualizzerebbe questa transazione e quindi avremmo una vulnerabilità di riferimento diretto non sicura degli oggetti.
Le vulnerabilità di IDOR possono verificarsi in caso di moduli di modifica della password. L'URL di un modulo di modifica password mal progettato potrebbe essere:
https://www.example.com/change_password.php?userid=1701
Questo URL verrà inviato via e-mail dopo aver fornito un indirizzo e-mail utilizzando un modulo diverso. Se non ci sono controlli aggiuntivi, un hacker malintenzionato può provare l'URL sopra con userid=1, probabilmente ottenendo l'accesso all'account amministratore.
Le vulnerabilità di IDOR potrebbero anche riguardare nomi di file, non ID oggetto. Ad esempio, una delle vulnerabilità IDOR più tipiche è l' attraversamento delle directory ( attraversamento del percorso ). In questo caso speciale, l'utente è in grado di visualizzare file non autorizzati. Per esempio:
https://www.example.com/display_file.php?file.txt
Se esiste una vulnerabilità IDOR associata allo script display_file.php , un hacker malintenzionato potrebbe ottenere l'accesso a risorse di file system sensibili come il file / etc / passwd :
https://www.example.com/display_file.php?../../../etc/passwd
Prevenzione di riferimento diretto non sicura
La Guida ai test OWASP contiene un paragrafo su come testare vulnerabilità di riferimento diretto non sicure di oggetti: OTG-AUTHZ-004. Le soluzioni automatizzate non sono ancora in grado di rilevare le vulnerabilità di IDOR.
L'unico modo per proteggersi da IDOR è implementare severi controlli di controllo degli accessi. Fortunatamente, i moderni framework web come Ruby on Rails o Django non hanno problemi con IDOR (a meno che lo sviluppatore non decida di utilizzare i propri meccanismi anziché quelli forniti). Il controllo dell'accesso è implementato in tali framework in base alla progettazione. Pertanto, ti consigliamo di utilizzare framework rinomati per sviluppare le tue applicazioni web e seguire le migliori pratiche.
Si noti che alcune fonti consigliano di prevenire le vulnerabilità di IDOR utilizzando identificatori di oggetti lunghi e difficili da indovinare, come quelli utilizzati per gli ID di sessione. Un'altra soluzione simile proposta è quella di utilizzare mappe di riferimento a oggetti indiretti con ID esterni difficili da indovinare. Tuttavia, raccomandiamo caldamente contro tali approcci perché danno un falso senso di sicurezza e rendono l'attacco più duro ma non impossibile.
