IDOR sta per Insecure Direct Object Reference: riferimento diretto e non protetto a un oggetto. È il difetto per cui un'applicazione mostra un dato basandosi su un identificativo visibile — per esempio il numero di un ordine nell'indirizzo — senza verificare che chi lo chiede abbia il diritto di vederlo. Cambiando il numero si ottengono i dati di un altro. È fra i difetti più comuni nei portali clienti e nei gestionali, e appartiene al controllo degli accessi rotto, la voce numero uno della classifica OWASP.
Il meccanismo, senza gergo
In un portale ogni cliente apre le proprie fatture con un link che contiene un numero: la fattura 580, la 581. Se l'applicazione, quando riceve la richiesta, non controlla di chi sia quella fattura prima di consegnarla, chiunque può cambiare il numero e vedere la fattura di un altro. Non serve alcuno strumento: si cambia una cifra. Il difetto non è che il numero sia visibile — lo è per forza — ma che manchi il controllo di proprietà.
Le finte soluzioni e quella vera
- Nascondere il link nel menù: non serve, l'indirizzo digitato a mano funziona lo stesso.
- Usare un numero lungo e casuale: aiuta contro chi indovina, ma se il codice trapela la porta è ancora aperta.
- La soluzione vera: il server verifica, a ogni richiesta, che il dato appartenga a chi lo chiede, prima di restituirlo.
Domande frequenti
- È grave se lo trovo nel mio portale?
- Dipende da cosa espone: se sono dati personali dei clienti è serio, perché è una violazione di dati con i relativi obblighi. La gravità si misura con il CVSS, non a sensazione. Se ne trovate uno, è ragionevole far controllare l'applicazione per intero, perché di solito non è l'unico.
- Perché è così comune?
- Perché il controllo di proprietà va ripetuto in ogni punto in cui si accede a un dato, e in un'applicazione di media grandezza quei punti sono decine. Basta dimenticarne uno. Non è incompetenza di chi costruisce: è la natura ripetitiva del controllo a renderlo facile da saltare.