Magical 2FA Bypass: dos factores en la interfaz, uno en la API

El navegador se comportó correctamente: respetó el indicador y bloqueó la navegación. Pero como el servidor emitía el token al mismo tiempo, toda la protección dependía de que cada cliente colaborara de forma voluntaria.

1. 01

   Inicio de sesión en dos pasos con un token de desafío de corta duración

   Si el segundo factor está activo, el endpoint de inicio de sesión solo emite un token de desafío: de corta duración (unos cinco minutos), de un solo uso, vinculado a la cuenta y al proceso de inicio de sesión, y válido únicamente para la verificación del código. El token de sesión no se genera hasta el segundo paso.

   POST /api/v5/login{ "username": "…", "password": "…" }→ 200 { "data": { "challenge_token": "ct_…", "scope": "auth:mfa_challenge", "expires_in": 300 } }POST /api/v5/login/verify-2fa{ "challenge_token": "ct_…", "totp_code": "123456" }→ 200 { "data": { "auth_token": "eyJ…", "scope": "user:authenticated" } }

2. 02

   Aplicación del control en la pasarela y el middleware

   La pasarela de API o el middleware comprueba los claims del token en cada punto de entrada. Las rutas protegidas solo aceptan tokens con el alcance user:authenticated; un token de desafío (auth:mfa_challenge) recibe allí un 401 o un 403. Si, además, el token de sesión registra qué factores se han verificado, por ejemplo en el claim amr, cada servicio puede comprobarlo por sí mismo.

   if (!String(token.scope ?? '').split(' ').includes('user:authenticated')) {  return res.status(401).end()}const user = await users.findById(token.sub)if (user.mfaEnabled && !token.amr?.includes('otp')) {  return res.status(403).end()}

3. 03

   Pruebas de regresión automatizadas

   Las pruebas de extremo a extremo inician sesión con una cuenta que tiene activo el segundo factor mediante un cliente HTTP en bruto, en cada vía de inicio de sesión, y verifican que, sin el código, no se puede acceder a ningún endpoint protegido. Así, una regresión se detecta en el próximo release y no con el próximo atacante.

   LOGIN_PATHS = ["/api/v5/login", "/api/v4/login"]  # every login route, incl. legacy versions@pytest.mark.parametrize("path", LOGIN_PATHS)def test_login_without_second_factor_yields_no_session(client, mfa_user, path):    r = client.post(path, json=mfa_user.credentials)    assert r.status_code == 200    data = r.json()["data"]    assert set(data) <= {"challenge_token", "scope", "expires_in"}    assert data["scope"] == "auth:mfa_challenge"    p = client.get("/api/v5/users/me/profile", headers={"Authorization": "Token " + data["challenge_token"]})    assert p.status_code in (401, 403)

Endurecimiento complementario

• Tratar igual todas las vías de inicio de sesiónLas versiones anteriores de la API, las apps móviles, el SSO, la renovación de tokens y el restablecimiento de contraseñas necesitan la misma comprobación. Las recomendaciones de OWASP sobre MFA mencionan expresamente las API independientes a través de las cuales los usuarios pueden iniciar sesión.
• Limitar los intentos de introducir el códigoUnos límites estrictos de intentos fallidos en la verificación del código impiden que un código de seis dígitos pueda averiguarse por fuerza bruta.
• Acotar el token de desafíoDescartarlo tras una verificación correcta o tras unos pocos intentos fallidos, y no aceptarlo nunca como sustituto de un token de sesión.
• Registrar los flujos anómalosLas verificaciones de contraseña correctas sin una verificación posterior del código, seguidas de accesos a endpoints sensibles, son una señal de peso para la monitorización y el SOC.
• Probar los endpoints de forma aisladaLos pentests y las pruebas de seguridad de API deberían examinar los endpoints de autenticación sin la interfaz y analizar cada respuesta en busca de tokens emitidos prematuramente.

Fundamentos: Multifactor Authentication Cheat Sheet (abre un sitio web externo) · SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management (julio de 2025) (abre un sitio web externo) · RFC 6238: TOTP: Time-Based One-Time Password Algorithm (mayo de 2011) (abre un sitio web externo) · RFC 8176: Authentication Method Reference Values (junio de 2017) (abre un sitio web externo)

Este encuadre no constituye asesoramiento jurídico.