Request Support  | Contact Sales

Diventa Autore per CoreTech | Scopri di più





Cosa sono i riferimenti a oggetti diretti non sicuri

30/06/20 CoreTech Blog

Banner

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

Trovare le vulnerabilità dei siti web prima degli HackerL'importanza della convalida delle correzioni: lezioni da GoogleSDLC agile e sicuro - Best practiceIn che misura le aziende gestiscono la sicurezza delle applicazioni Web?Cross-Origin Resource Sharing (CORS) e intestazione Access-Control-Allow-OriginCosa sono i reindirizzamenti aperti?DevSecOps: come arrivarci da DevOpsIl bigino su SQL Injection per sviluppatoriSfruttare SSTI in ThymeleafSicurezza nginx: come proteggere la configurazione del serverRafforzamento del sistema Web in 5 semplici passaggiCos'è la sicurezza del sito Web - Come proteggere il tuo sito Web dall'hackingRapporto sulle vulnerabilità delle applicazioni Web Acunetix 2020Perché l'elenco delle directory è pericoloso?Cosa sono gli hack di Google?Cosa è l'attacco BEASTWeb Shells in Action - Rilevazione e prevenzione - parte 5Web Shells in Action - parte 4Mantenere le Web Shells sotto copertura - parte 3Introduzione alle web shell - parte 2: 101 Uso di PHPIntroduzione alle web shell - parte 1Debunking 5 miti sulla postura della sicurezza informaticaIniezioni di NoSQL e come evitarleConfigurazione passo passo di Acunetix con JenkinsCosa sono i riferimenti a oggetti diretti non sicuriAnche il più forte cade: un'iniezione SQL in Sophos XG FirewallAcunetix rilascia Business Logic RecorderCome recuperare un 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 password comuni e come evitarleTutto quello che devi sapere sugli attacchi Man-in-the-MiddleChe cosa sono le iniezioni HTMLRed Teaming – 5 consigli su come farlo in modo sicuroTesta le tue competenze XSS utilizzando siti vulnerabiliPerché hacker malintenzionati hanno messo gli occhi sugli ospedaliPratiche di codifica sicura – I tre principi chiaveLa maledizione delle vecchie librerie JavaMutation XSS nella ricerca GoogleIgnorare SOP utilizzando la cache del browserCome e perché evitare reindirizzamenti e inoltri non convalidati?Dirottamento di sessione e altri attacchi di sessioneCome 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 InjectionVulnerabilità delle entità esterne XML in Internet ExplorerCoreTech assicura protezione dei siti Web con AcunetixCoreTech distributore Acunetix a fianco dei partner per la CyberSecurityCyberSecurity applicativa, nuova opportunità per voi!