Si entiendo correctamente, la principal diferencia es que el usuario debe iniciar sesión para llevar a cabo un ataque de inseguridad de referencia directa a objetos, pero no tiene que iniciar sesión para explotar un ataque de control de acceso roto.
¿Tengo este derecho? ¿Cuáles son las diferencias?
Definición de referencia de objetos directa insegura en :
Las referencias a objetos directos inseguros se producen cuando una aplicación proporciona acceso directo a objetos según la entrada proporcionada por el usuario. Como resultado de esta vulnerabilidad, los atacantes pueden omitir la autorización y acceder a los recursos en el sistema directamente, por ejemplo, registros o archivos de bases de datos.
Definición de Control de Acceso Roto de OWASP
El control de acceso, a veces llamado autorización, es cómo una web La aplicación otorga acceso a contenidos y funciones a algunos usuarios y No otros. Estas verificaciones se realizan después de la autenticación, y rigen lo que los usuarios "autorizados" pueden hacer. Control de acceso Parece un problema simple pero es insidiosamente difícil de implementar correctamente. El modelo de control de acceso de una aplicación web está estrechamente vinculado a El contenido y las funciones que proporciona el sitio. además, el Los usuarios pueden caer en una serie de grupos o roles con diferentes habilidades o privilegios.
Dependiendo de cómo desee interpretar estos términos no estándar, se podrían interpretar de la misma manera.
Sin embargo, el acceso directo a objetos generalmente significa que no existe un control de autenticación para poder acceder a información privilegiada, mientras que el control de acceso interrumpido indica que el control de acceso no funciona como se esperaba.
Por ejemplo, si crea informes para un usuario específico en alguna URL como: http://example.com/some-report/report-1231231231312.pdf y la aplicación no requiere autenticación, esto sería acceso directo a objetos. Es posible que los desarrolladores nunca hayan implementado ningún control de acceso en primer lugar, por lo tanto, el control de acceso no se rompe, solo es acceso directo a objetos, es decir, el informe se escribe en una url, pero es solo una ubicación de archivo separada del núcleo aplicación, por lo que la aplicación no tiene control sobre la entrega del recurso.
En muchos casos, ambos términos podrían usarse también para describir la misma vulnerabilidad. Por ejemplo, el informe se genera de forma dinámica solo para los usuarios que han iniciado sesión, pero se puede acceder al informe más tarde sin tener que iniciar sesión. En este caso, los desarrolladores solo ponen el control de acceso en la función para crear el informe pero no para acceder.
Referencia de objeto directo inseguro
Depende de la instancia específica de cada vulnerabilidad. La referencia directa insegura de objetos es generalmente cuando un objeto de base de datos tiene un ID expuesto al cliente. Así, por ejemplo, en una aplicación que utiliza URL de estilo REST podríamos tener
http://myapp.test/users/2
mostrando su cuenta de usuario y luego si cambia a
http://myapp.test/users/4
te muestra la cuenta de otra persona. En este caso, deberá iniciar sesión, pero AFAIK no hay nada en la especificación de vulnerabilidad que indique que accede, por ejemplo,
http://myapp.test/page/12
aunque no esté autenticado, no sería inseguro el DOR, suponiendo que la página solo esté destinada a ser accedida mientras esté conectado.
El control de acceso roto es un caso más general en el que el control sobre el acceso a la funcionalidad de la aplicación no se controla correctamente, pero sin el requisito de que se relacione con el acceso a un objeto de base de datos.
Así, por ejemplo.
http://myapp.test/super_secret_admin_panel
ser accesible sin autenticación sería un control de acceso roto. pero podría tener una situación en la que se relacione con los usuarios autenticados que tienen acceso a una funcionalidad que no deberían, por lo que un miembro del personal ordinario accede
http://myapp.test/all_staff_salary_details
cuando solo los miembros del departamento de recursos humanos deben poder acceder a esto.
Por lo tanto, el TL; DR no es ninguno de los dos problemas que pueden ocurrir, independientemente de que el usuario haya iniciado sesión.
Lea otras preguntas en las etiquetas authorization access-control owasp