Vulnerabilidad crítica cvss (9.3) de control de acceso que permitía tomar el control de cualquier cuenta

Durante una prueba de seguridad web se identificaron dos vulnerabilidades de tipo Insecure Direct Object Reference (IDOR), ambas originadas por el mismo problema de fondo: la aplicación autentica correctamente a los usuarios, pero no comprueba si tienen autorización sobre el recurso concreto que están pidiendo.

Con una cuenta creada por el proceso normal de registro —sin permisos especiales, sin contraseñas de nadie más— fue posible modificar el correo y la contraseña de otra cuenta, y leer PQRS que no pertenecían al usuario autenticado.

Ninguno de los dos hallazgos depende de errores exóticos: basta con cambiar un identificador dentro de una solicitud legítima.

La funcionalidad de edición de cuenta recibe un identificador de usuario en la solicitud y no valida que corresponda al usuario autenticado. Usando dos cuentas de prueba —attacker y victim—, ambas creadas sin privilegios especiales, bastó con reemplazar la referencia al recurso propio por la del otro usuario para que el servidor procesara el cambio sin objetar nada.

Con eso quedó abierta la puerta a cambiar tanto el correo electrónico como la contraseña de la cuenta víctima, sin conocer su contraseña actual ni tener sesión activa como ella.

Al afectar directamente los mecanismos de acceso a la cuenta —correo y contraseña—, el impacto potencial va desde la pérdida de acceso del propietario legítimo hasta un account takeover completo, incluyendo cuentas con privilegios más altos si comparten el mismo flujo vulnerable.

Al radicar una PQRS, la aplicación entrega un identificador secuencial y predecible (1001, 1002, 1003…). El problema no es únicamente que el identificador sea adivinable, sino que consultar cualquiera de ellos devuelve la información sin comprobar si pertenece al usuario que hace la solicitud.

Esto habilita la lectura de datos personales, de contacto o de negocio contenidos en PQRS de otros usuarios, además de facilitar la enumeración masiva de todos los registros existentes en el sistema.

La corrección de fondo es la misma para ambos hallazgos: verificar, en cada operación sensible, que el usuario autenticado sea realmente el propietario del recurso que intenta leer o modificar —autenticación y autorización no son lo mismo—.

• Validar autorización a nivel de objeto en cada endpoint sensible, no solo la sesión activa.
• No confiar en identificadores enviados por el cliente para localizar recursos.
• Exigir reautenticación para cambios de contraseña o correo.
• Invalidar sesiones activas tras un cambio de credenciales.
• Usar identificadores no predecibles (UUID) como defensa complementaria, no como control principal.
• Registrar y monitorear accesos e intentos de acceso a objetos ajenos.