Control de acceso roto e IDOR

Un control de acceso correcto tiene dos pasos: saber quien eres (sesion) y comprobar que esto en concreto es tuyo (autorizacion). En factura.php de Clavenet hay sesion, pero falta el segundo paso: se busca la factura por $_GET['id'] y se devuelve sin comprobar que pertenezca al usuario en sesion. El auditor lo ve por lo que NO esta: no hay ninguna linea que compare el dueno de la factura con quien pregunta. El propio codigo lo deja anotado como comentario del arreglo que falta.

Leer lo que falta es mas dificil que leer lo que sobra. La pista es que entre buscar la factura y devolverla no hay ninguna comprobacion.

El control ausente deja huella en los registros. En el acceso.log de Clavenet el usuario 1001 pide varias facturas por su id —7781, 7782— y el servidor responde 200, aunque esas facturas son de otros usuarios. Para el auditor ese patron confirma el fallo: un mismo usuario accediendo a recursos que no son suyos y el servidor sirviendolos sin rechistar. Es una referencia directa a objeto insegura, lo que se llama IDOR.

El log no es un ataque: es la prueba estatica de que el control no existe, exactamente lo que el informe necesita mostrar.

La clasificacion guia el arreglo. Este fallo es una referencia directa insegura a objeto (CWE-639), de la familia de la autorizacion ausente (CWE-862). El arreglo no es ocultar el id ni hacerlo mas dificil de adivinar —eso solo lo disimula—, sino comprobar en el servidor, antes de devolver el recurso, que pertenece al usuario en sesion. Un identificador no secreto deja de importar cuando el servidor verifica la propiedad.

Cambiar los ids por numeros al azar es la trampa clasica: parece un arreglo y solo retrasa al que prueba ids.

La nota de triaje de Clavenet recoge el fallo: el archivo, el parametro, la clasificacion y el arreglo. Abrela en el laboratorio y lee el codigo del hallazgo con el que cierra.