Qué es IDOR y cómo proteger tus datos
Autor: Redacción Domeny.ForSale Publicado
En pocas palabras: IDOR (Insecure Direct Object Reference) es una vulnerabilidad que permite acceder a un recurso ajeno indicando su identificador, sin que la aplicación compruebe debidamente los permisos. Por ejemplo, un usuario cambia el número de factura en la dirección y puede ver el documento de otro cliente. El problema no es el número en la dirección, sino que el servidor no comprueba si esa persona tiene derecho a acceder a esa factura.
Cómo funciona IDOR: un ejemplo sencillo
Imagina un área de clientes en la que descargas tu factura tras iniciar sesión. El navegador envía al servidor una solicitud para la ruta /facturas/481 y la aplicación devuelve el documento número 481.
Usar una dirección así es una solución normal. La vulnerabilidad aparece cuando cambiar la ruta a /facturas/482 permite descargar la factura de otro cliente, aunque no tengas permiso para acceder a ella.
Es como un guardarropa en el que el empleado entrega un abrigo a cualquiera que indique el número de la percha, en lugar de comprobar si tiene derecho a recogerlo. El número identifica el objeto, pero no acredita el derecho a recibirlo.
El término «objeto» en IDOR se refiere aquí a un recurso de la aplicación: un documento, un pedido, una foto, un mensaje o una cuenta. «Referencia directa» significa que se indica ese recurso mediante un identificador. No tiene por qué ser un número consecutivo: puede ser un nombre de archivo, una dirección de correo electrónico o una cadena larga de caracteres.
Por qué no basta con iniciar sesión
La autenticación responde a la pregunta «¿Quién eres?». La autorización, es decir, la comprobación de permisos, responde a otra: «¿Qué puedes hacer?». Una aplicación puede identificar correctamente al usuario que ha iniciado sesión y, aun así, darle acceso a datos ajenos.
Un servidor seguro debe comprobar no solo si la factura existe, sino también si el usuario puede consultarla. El derecho de acceso puede depender de que el documento le pertenezca, de su función en la organización o de que alguien haya decidido compartirlo con esa persona.
IDOR no se limita a la consulta de información. La falta de controles también puede permitir modificar o eliminar un recurso ajeno, como la dirección de entrega de un pedido. El permiso de lectura no implica automáticamente el de edición, por lo que cada operación requiere su propia comprobación.
Si la aplicación presta servicio a varias empresas, también importa mantener la separación entre organizaciones. El administrador de una empresa no debería acceder a los datos de otra solo por conocer el identificador de uno de sus documentos.
Dónde puede estar el identificador implicado
El identificador no tiene por qué ser visible en la barra de direcciones. Puede aparecer en los parámetros de consulta, en el cuerpo de una solicitud enviada desde un formulario o en una llamada a una API, una interfaz que permite la comunicación entre programas.
Entre las operaciones habituales que requieren controles están:
- descargar facturas, archivos adjuntos y exportaciones de datos;
- consultar mensajes, solicitudes y pedidos;
- actualizar el perfil o la configuración de la cuenta;
- eliminar archivos y otros recursos.
No siempre que se consigue acceder a algo cambiando el identificador hay un fallo. Una entrada pública de un blog debe estar disponible para todos, y un documento compartido, para los colaboradores autorizados. Lo que determina si existe una vulnerabilidad es el incumplimiento de las reglas de acceso previstas, no la mera posibilidad de indicar otro objeto.
Los fallos similares en las API se describen a veces como BOLA (Broken Object Level Authorization), es decir, una comprobación incorrecta de los permisos sobre un objeto concreto. Ambos términos están estrechamente relacionados; en la práctica, la pregunta sigue siendo la misma: ¿comprueba el servidor que el usuario tiene permiso para acceder al recurso indicado y realizar esa acción?
Qué protege realmente frente a IDOR
La protección fundamental consiste en comprobar los permisos en el servidor cada vez que se accede a un recurso. Ocultar un botón en la interfaz no basta, porque la solicitud se puede enviar sin utilizarlo.
En el ejemplo de las facturas, la aplicación debería buscar el documento entre aquellos a los que el usuario tiene acceso, o comprobar sus permisos antes de devolverlo. No debería aceptar el campo «propietario» enviado por el navegador como prueba de que el documento pertenece a ese usuario.
Los identificadores aleatorios, como los UUID, dificultan adivinar las direcciones, pero no sustituyen la autorización. Si el identificador se filtra, por ejemplo a través de un enlace compartido, el servidor debe seguir denegando el acceso a quien no tenga permiso.
Una buena regla es denegar por defecto: si la aplicación no puede confirmar que existe permiso para una operación, no la ejecuta. El control también debe abarcar las descargas de archivos y las exportaciones, no solo la pantalla principal del documento.
Cómo comprobar tu propia aplicación de forma segura
Realiza esta prueba únicamente en un sistema que te pertenezca o para el que tengas autorización para hacer pruebas. Lo mejor es utilizar un entorno de pruebas y datos ficticios, especialmente al probar operaciones de modificación y eliminación.
- Crea dos cuentas de prueba, A y B, sin recursos compartidos entre ellas.
- Crea un documento con la cuenta A y anota su identificador.
- Inicia sesión como B e intenta consultar ese documento mediante la interfaz prevista o la API.
- Comprueba por separado si es posible editarlo, descargarlo y eliminarlo, si esas acciones están disponibles.
- Verifica no solo el mensaje de denegación, sino también que no se haya revelado ni modificado ningún dato.
El servidor debe rechazar la operación no autorizada; también puede ocultar deliberadamente si el documento existe. Conviene incorporar este caso a las pruebas automatizadas para evitar que un cambio en el código reintroduzca la vulnerabilidad.
Consulta también: ¿Qué es 2FA?
Lee también
