Come prevenire IDOR?

Il Riferimento di oggetti diretti non sicuri è essenzialmente una combinazione di due problemi, nel caso più comune: identificatori enumerabili usati per oggetti esposti esternamente e mancanza di controllo sufficiente per i diritti di accesso a tali oggetti. Il primo di questi non è effettivamente richiesto, ma rende più difficile il rilevamento del problema (ad esempio, l'ipotesi di un GUID è molto più difficile di un numero intero)

Pertanto, risolve idealmente entrambi i punti. L'applicazione dovrebbe verificare che l'utente corrente abbia il permesso di accedere all'oggetto, ogni volta che si tenta di accedere. Se un utente ha accesso al record 3 e nessun altro, qualsiasi tentativo di accedere al record 4 dovrebbe essere rifiutato. Si noti che in alcuni casi, il controllo dell'accesso in lettura non è sufficiente: se possono scrivere su un record, anche senza poterlo leggere, può consentire ulteriori compromessi. Ad esempio, se una richiesta di PUT apportata a /user/1 contiene un valore di password, è importante verificare che la stessa PUT richiesta non possa essere eseguita a /user/2 , anche se è noto che GET /user/2 è rifiutato .

In secondo luogo, i riferimenti agli oggetti possono essere modificati per essere specifici dell'utente. Questo può impedire di esporre informazioni che possono essere commercialmente sensibili: se il tuo campo ID cliente è 1045 , e ti sei iscritto a un sito ieri, puoi fare un'ipotesi abbastanza ragionevole che è improbabile che ci siano più di 1050 client. Questo potrebbe essere esposto attraverso schermate di profilo su percorsi come /profile/1045/edit , o attraverso un parametro che viene passato in una richiesta POST, tra l'altro. Se, tuttavia, il percorso era /profile/edit e l'ID client è stato determinato dal server in base alla sessione utente attualmente attiva, questa informazione non è esposta.

Ovviamente, in alcuni casi, questo non è un metodo appropriato: in un sistema CRM, più utenti devono essere in grado di accedere agli stessi record, ad esempio, oltre a poterli condividere. In questo caso, deve esserci un modo per farvi riferimento attraverso gli account utente. Un hash dell'id oggetto sarebbe una opzione, anche se questo deve essere usato in combinazione con i controlli di accesso.

Per cose come le autorizzazioni, tuttavia, non è necessario che gli utenti siano in grado di condividere un identificatore. È più importante che possano impostare solo valori appropriati per il loro livello utente. In questo caso, l'assegnazione di un identificatore specifico dell'utente a quei valori a cui dovrebbero essere in grado di accedere può impedire che siano anche a conoscenza di altri valori. Eseguendo un mapping lato server - 1:read only, 2:read-write per gli utenti standard, ma 1:full control, 2:read only, 3:read-write, 4:delete per gli utenti amministrativi, ad esempio - e quindi elaborando che quando i dati sono archiviati, gli utenti standard non vedono mai che ci sono livelli più alti, e anche se lo facessero , non avrebbe modo di impostarli: il tentativo di copiare la richiesta di POST di un utente amministratore impostando il livello di accesso su 1 risulterebbe impostato sulla sola lettura, piuttosto che sul controllo completo.

È importante notare che senza controlli di accesso insufficienti, la quantità di informazioni esposte attraverso il riferimento diretto agli oggetti è limitata: potrebbe non avere importanza che le persone possano dire quanti oggetti di un dato tipo esistono (es. Twitter usa interi (grandi) per tweets), e solo impedire agli utenti non autorizzati di accedere ad altri oggetti è la parte importante. I riferimenti diretti agli oggetti possono essere appropriati in alcuni casi, in genere laddove è necessario condividere un identificatore comune tra gli utenti.