¿Cómo prevenir el IDOR?

La referencia de objetos directa insegura es esencialmente una combinación de dos problemas, en el caso más común: identificadores enumerables utilizados para objetos expuestos externamente, y una falta de verificación suficiente de los derechos de acceso a esos objetos. El primero de estos no es realmente requerido, pero hace que la detección del problema sea más difícil (por ejemplo, adivinar un GUID es mucho más difícil que incrementar un número entero).

Por lo tanto, las correcciones abordan idealmente ambos puntos. La aplicación debe verificar que el usuario actual tenga permiso para acceder al objeto, cada vez que se intente acceder. Si un usuario tiene acceso al registro 3 y ningún otro, cualquier intento de acceso al registro 4 debe rechazarse. Tenga en cuenta que, en algunos casos, el simple hecho de verificar el acceso de lectura es insuficiente: si pueden escribir en un registro, incluso sin poder leerlo, puede permitir un mayor compromiso. Por ejemplo, si una solicitud PUT hecha a /user/1 contiene un valor de contraseña, es importante verificar que no se pueda realizar la misma solicitud PUT en /user/2 , incluso si se sabe que se rechazó GET /user/2 .

En segundo lugar, las referencias de objetos se pueden modificar para que sean específicas del usuario. Esto puede evitar la exposición de información que puede ser comercialmente sensible: si el campo de identificación de su cliente es 1045 , y se registró en un sitio ayer, puede hacer una estimación bastante razonable de que es poco probable que haya más de 1050 clientes. Esto podría ser expuesto a través de pantallas de perfil en rutas como /profile/1045/edit , o mediante un parámetro que se pasa en una solicitud POST, entre otras formas. Sin embargo, si la ruta era /profile/edit y el servidor determinó la identificación del cliente según la sesión de usuario actualmente activa, esta información no está expuesta.

Obviamente, en algunos casos, este no es un método apropiado: en un sistema de CRM, varios usuarios necesitan poder acceder a los mismos registros, por ejemplo, así como poder compartirlos. En este caso, debe haber alguna forma de referenciarlas en las cuentas de usuario. Un hash de la identificación del objeto sería una opción, aunque esto debe usarse junto con los controles de acceso.

Para cosas como los permisos, sin embargo, no hay una necesidad particular para que los usuarios puedan compartir un identificador. Es más importante que solo puedan establecer valores que sean apropiados para su nivel de usuario. En este caso, la asignación de un identificador específico de usuario a aquellos valores a los que deberían poder acceder puede evitar que conozcan otros valores. Al realizar una asignación del lado del servidor: 1:read only, 2:read-write para usuarios estándar, pero 1:full control, 2:read only, 3:read-write, 4:delete para usuarios administrativos, por ejemplo, y luego procesar que cuando se almacenan los datos, los usuarios estándar nunca ven que hay niveles más altos, e incluso si lo hicieron , no tendría forma de establecerlos: al intentar copiar la solicitud POST de un usuario administrador configurando el nivel de acceso a 1, se configurará como de solo lectura, en lugar de un control total.

Es importante tener en cuenta que sin controles de acceso insuficientes, la cantidad de información expuesta a través de la referencia directa a objetos es limitada: puede que no importe que las personas puedan saber cuántos objetos de un tipo dado existen (por ejemplo, Twitter usa (grandes) enteros). para los tweets), y solo evitar que usuarios no autorizados accedan a otros objetos es la parte importante. Las referencias directas de objetos pueden ser apropiadas en algunos casos, por lo general cuando hay un requisito para compartir un identificador común entre usuarios.