Magical 2FA Bypass : deux facteurs dans l'interface, un seul dans l'API

Le navigateur s'est comporté correctement : il a respecté l'indicateur et bloqué la navigation. Mais comme le serveur émettait le jeton en même temps, toute l'efficacité de la protection reposait sur la coopération volontaire de chaque client.

1. 01

   Connexion en deux étapes avec un jeton de challenge à courte durée de vie

   Lorsque le second facteur est activé, le point de terminaison de connexion n'émet qu'un jeton de challenge : à courte durée de vie (environ cinq minutes), à usage unique, lié au compte et à la tentative de connexion, et valable uniquement pour la vérification du code. Le jeton de session n'est créé qu'à la deuxième étape.

   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

   Application du contrôle dans la passerelle et le middleware

   La passerelle d'API ou le middleware vérifie les claims du jeton à chaque point d'entrée. Les routes protégées n'acceptent que les jetons dotés du scope user:authenticated ; un jeton de challenge (auth:mfa_challenge) y reçoit un 401 ou un 403. Si le jeton de session consigne en outre les facteurs vérifiés, par exemple dans le claim amr, chaque service peut le contrôler lui-même.

   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

   Tests de régression automatisés

   Des tests de bout en bout connectent, avec un client HTTP brut et sur chaque chemin de connexion, un compte dont le second facteur est activé, et s'assurent qu'aucun point de terminaison protégé n'est accessible sans le code. Une régression est ainsi repérée dès la prochaine version, et non par le prochain attaquant.

   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)

Durcissement complémentaire

• Traiter tous les chemins de connexion de la même manièreLes anciennes versions d'API, les applications mobiles, le SSO, le rafraîchissement de jeton et la réinitialisation du mot de passe nécessitent le même contrôle. Les recommandations de l'OWASP sur la MFA citent explicitement les API distinctes par lesquelles les utilisateurs peuvent se connecter.
• Limiter les saisies de codeDes limites strictes au nombre de tentatives échouées lors de la vérification du code empêchent de trouver un code à six chiffres en essayant toutes les combinaisons.
• Encadrer strictement le jeton de challengeL'invalider après une vérification réussie ou quelques tentatives échouées, et ne jamais l'accepter en remplacement d'un jeton de session.
• Journaliser les flux inhabituelsDes vérifications de mot de passe réussies sans vérification de code consécutive, suivies d'accès à des points de terminaison sensibles, constituent un signal fort pour la supervision et le SOC.
• Tester les points de terminaison isolémentLes tests d'intrusion et les tests de sécurité des API devraient examiner les points de terminaison d'authentification sans passer par l'interface et inspecter chaque réponse à la recherche de jetons émis prématurément.

Références : Multifactor Authentication Cheat Sheet (ouvre un site externe) · SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management (juillet 2025) (ouvre un site externe) · RFC 6238: TOTP: Time-Based One-Time Password Algorithm (mai 2011) (ouvre un site externe) · RFC 8176: Authentication Method Reference Values (juin 2017) (ouvre un site externe)

Cette mise en perspective ne constitue pas un conseil juridique.