Un IDOR (Insecure Direct Object Reference) es cuando existe la posibilidad de acceder a la data de otro usuario. Es decir, un usuario final de un banco, por ejemplo, solo tiene acceso a su cuenta bancaria, pero si existe una falla lógica esta le permitirá acceder a una cuenta bancaria de otro usuario final; ahí ocurre un IDOR.
No solamente puede ocurrir desde el lado del usuario final, sino que también del lado del BackOffice –esto es lo que llamamos la parte administrativa del banco-, usuarios administrativos con diferentes perfiles. La razón por la cual ocurre este tipo de vulnerabilidad es por el simple hecho de que no hubo un análisis del flujo de trabajo o una falta de auditorías, para identificar las fallas lógicas del negocio.
La falta de un correcto control en el acceso a los perfiles permite este tipo de ataques. Es muy peligroso este tipo de vulnerabilidad porque hace que sea difícil identificar una actividad sospechosa. La razón de ello es que este tipo de ataque radica en el simple hecho de que desde el Backend -servidores que manejan la aplicación web- se observa una actividad normal.
El ciberdelincuente que explote esta vulnerabilidad no realiza una actividad anómala desde el punto de vista de la funcionalidad de la aplicación web como tal; de lo contrario, si fuera un actividad anómala acerca de la funcionalidad del programa, sí fuera fácil identificar este tipo de ataque.
Un monitoreo normal de este tipo de ataque nunca se identificará a menos que se agregue una capa de seguridad -un robusto algoritmo- que sí pueda monitorear la actividad del usuario. Este tipo de tecnología ya existe, pero aún no se torna del todo popular en el mercado.
Este tipo de solución debe de ser implementado si o si para el sector financiero con el fin de poner un alto a los fraudes bancarios.
También, las auditorías de tipo caja blanca permiten identificar estos tipos de falla lógicas, por lo que es de suma importancia realizarlas.