IDOR

IDOR sta per Insecure Direct Object Reference ed è una vulnerabilità che riguarda il controllo d'accesso.
Si ottiene quando un server riceve una richiesta di recuperare oggetti (file, dati, documenti...) senza controllare se quell'utente abbia effettivamente accesso a quella risorsa.
Ad esempio, pensiamo di registrare un account su un sito chiamato www.unsecure-site.com.
Una volta registrati, logghiamo e andiamo sul nostro profilo e guardando la barra degli indirizzi notiamo che è diventata "www.unsecure-site.com/profile?id=255", il nostro profilo è quindi il numero 255, e se il sito usa un ordina sequenziale allora esistono almeno altri 254 profili.
Per testare se il sito sia vulnerabile ad un attacco IDOR possiamo lanciare Burp (oppure OWASP ZAP), intercettare e modificare la richiesta da "www.unsecure-site.com/profile?id=255" a "www.unsecure-site.com/profile?id=240".
Nel caso in cui il sito risponda facendoci vedere il profilo 240, allora si ha una vulnerabilità IDOR, in quanto possiamo vedere le informazioni legate ad un profilo diverso dal nostro.

Encoded e Hashed ID

Per cercare di ovviare a questo problema, alcuni sviluppatori potrebbero pensare di codificare un ID oppure generare un hash.
Nel caso di un "Encoded ID" questo potrebbe avere un valore pari a MjU1. Ora potremmo cercare di capire l'encoding utilizzato usando un sito che prova a decodificare la nostra stringa con tutti i possibili decoder.
Il metodo più comune di encoding sul web è base64, e usando un sito come www.base64decode.org otteniamo che la nostra stringa è in realtà il numero 255. Usiamo lo stesso sito per fare l'encoding di 254 e otteniamo MjU1. Ora ci basta intercettare la richiesta e modificare l'ID in "www.unsecure-site.com/profile?id=MjU1 et voilà.
Nel caso, invece, che sia un hashed ID le cose si fanno un po' più complicate: gli algoritmi di hash funzionano solo in un senso, ossia producono un output da un input, ma non si può risalire all'input avendo solo l'output.
In questa situazione si potrebbero creare più account e vedere se l'ID sia indovinabile, in quanto alcune applicazioni usano algoritmi di hash con un bassa entropia (l'entropia, in questo caso, è il grado di casualità dell'ID).

Cambiare il metodo della richiesta

Esistono tanti tipi di metodi HTTP: GET, POST, PUT, DELETE e se con uno non riusciamo ad avere una vulnerabilità IDOR, possiamo provare a cambiare semplicemente il metodo: potrebbe essere, infatti, che gli sviluppatori abbiano sanificato solo alcuni metodi HTTP, tralasciandone altri.

Prevenzione

Per prevenire un attacco IDOR è consigliato implementare le seguenti soluzioni:

• Assegnare agli oggetti un numero casuale con molte cifre, invece di uno sequenziale

• Usare software per Fuzz testing, che tenta di scoprire bug e vulnerabilità in applicazioni inserendo input casuali o inaspettati

• Verificare i parametri, come ad esempio assicurarsi che una stringa sia della lunghezza richiesta, controllare che queste stringhe non abbiano caratteri particolari (come il Null Byte, "%00") e che gli input siano del tipo richiesto (stringhe, numeri, date...)

• Eseguire il controllo dell'accesso lato server invece che lato client.