Resumen
En la sección de equipo de la aplicación de Omise, la política era clara: para invitar a un miembro nuevo, la cuenta tenía que tener activada la autenticación en dos pasos (2FA). El problema es que esa regla se aplicaba solo en la parte del cliente: el navegador recibía un indicador que decía si se cumplía el requisito y, en función de él, permitía o bloqueaba la invitación.
El investigador 0x7ashish comprobó que, si se reescribía ese indicador de false a true en las respuestas que llegaban al navegador, la aplicación dejaba enviar la invitación aunque la cuenta siguiera sin 2FA. Se trata de un fallo de control de acceso (HackerOne lo clasificó como Improper Access Control - Generic) con severidad media. El programa lo dio por resuelto y pagó una recompensa de importe no público. Se envió el 24 de septiembre de 2025 y se divulgó el 28 de febrero de 2026.
Pasos de reproducción
- Registrarse o iniciar sesión en la aplicación con una cuenta sin 2FA activado.
- Entrar en la sección de equipo (Team).
- Intentar invitar a un miembro nuevo. La aplicación lo impide y pide activar antes el 2FA.
- En Burp Suite, configurar una regla de Match and Replace que cambie en las respuestas el indicador del cliente que controla este requisito:
```diff
- false
+ true ```
El reporte no da el nombre exacto del campo; aparece en las capturas adjuntas, que no son públicas.
- Recargar la página con la regla activa.
- Volver a enviar la invitación. Esta vez se envía correctamente, aunque la cuenta sigue sin 2FA.
Impacto
- La política de seguridad que obliga a usar 2FA para invitar a miembros deja de tener efecto: basta con manipular lo que recibe el propio navegador.
- Si una cuenta queda comprometida, quien la controle puede invitar a usuarios no autorizados al equipo sin la protección del 2FA, que es justo lo que la regla pretendía evitar.
Remediación
La recomendación del investigador fue comprobar el requisito de 2FA en el servidor antes de procesar cualquier petición de invitación, en lugar de fiarse solo de la comprobación en el cliente. El reporte consta como resuelto, aunque no detalla cómo se aplicó el cambio.
Qué aprender de este caso
- Cuando una aplicación bloquea una acción con un mensaje tipo "activa el 2FA primero", busca en las respuestas del servidor un booleano que controle ese bloqueo; si cambiarlo con Match and Replace desbloquea el botón, prueba si el servidor acepta de verdad la petición.
- Revisa todas las acciones sensibles que dependen de un requisito previo (2FA, email verificado, plan de pago): suelen comprobarse en la pantalla que las muestra y olvidarse en el endpoint que las ejecuta.
- Al programar, el endpoint que crea la invitación debe consultar el estado de 2FA del usuario en cada petición; el indicador que se envía al frontend sirve solo para pintar la interfaz, nunca para decidir.