Listino Supporto Partner Contatti 800 13.40.41

Articoli

Icona delle News


Cosa sono i riferimenti a oggetti diretti non sicuri

30/06/20 CoreTech Blog

×Non sei ancora nostro cliente Acunetix? Diventa Partner CoreTech e visita il nostro configuratore prezzi

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 .

Come accadono le vulnerabilità di IDOR

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.

Scenari comuni di riferimento ad oggetti diretti non sicuri

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.


Articoli su Acunetix

Introduzione alle web shell - parte 2: 101 Uso di PHPIntroduzione alle web shell - parte 1Iniezioni di NoSQL e come evitarleDebunking 5 miti sulla postura della sicurezza informaticaConfigurazione passo passo di Acunetix con JenkinsAnche il più forte cade: un'iniezione SQL in Sophos XG FirewallCosa sono i riferimenti a oggetti diretti non sicuriAcunetix rilascia Business Logic RecorderCome recuperare da un evento del sito Web compromessoCome difendersi dagli hacker Black Hat durante la pandemia COVID-19Che cos'è l'inclusione remota dei file (RFI)?Apache Security - 10 consigli per un'installazione sicuraUn nuovo sguardo sugli attacchi correlati al proxy inversoVulnerabilità delle entità esterne XML in Internet ExplorerVulnerabilità delle password comuni e come evitarleChe cosa sono le iniezioni HTMLTutto quello che devi sapere sugli attacchi Man-in-the-MiddleTesta le tue competenze XSS utilizzando siti vulnerabiliRed Teaming – 5 consigli su come farlo in modo sicuroPratiche di codifica sicura – I tre principi chiavePerché hacker malintenzionati hanno messo gli occhi sugli ospedaliMutation XSS nella ricerca GoogleLa maledizione delle vecchie librerie JavaIgnorare SOP utilizzando la cache del browserDirottamento di sessione e altri attacchi di sessioneCome e perché evitare reindirizzamenti e inoltri non convalidati?Come abbiamo trovato un altro XSS in Google con AcunetixChe cos'è un buffer overflowChe cos'è l'overflow di IntegerChe cos'è HSTS e perché dovrei usarlo?Che cosa è OS Command InjectionCoreTech assicura protezione dei siti Web con AcunetixCoreTech distributore Acunetix a fianco dei partner per la CyberSecurityCyberSecurity applicativa, nuova opportunità per voi!

Knowledge Base su Acunetix

Il Pen Testing applicativo con Acunetix
Ripe Ncc Member
vmware
CloudLinux
Plesk
HP
Microsoft