Magical 2FA Bypass: zwei Faktoren in der Oberfläche, einer in der API

Der Browser verhielt sich korrekt: Er respektierte das Flag und sperrte die Navigation. Weil der Server das Token aber gleichzeitig ausgab, hing die gesamte Schutzwirkung davon ab, dass jeder Client freiwillig mitspielt.

1. 01

   Zweistufiger Login mit kurzlebigem Challenge-Token

   Ist der zweite Faktor aktiv, gibt der Login-Endpunkt nur ein Challenge-Token aus: kurzlebig (etwa fünf Minuten), einmalig nutzbar, an Konto und Anmeldevorgang gebunden und ausschließlich für die Code-Prüfung gültig. Das Sitzungstoken entsteht erst im zweiten Schritt.

   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

   Durchsetzung in Gateway und Middleware

   API-Gateway oder Middleware prüft an jedem Eingang die Claims des Tokens. Geschützte Routen akzeptieren nur Tokens mit dem Scope user:authenticated, ein Challenge-Token (auth:mfa_challenge) erhält dort 401 oder 403. Hält das Sitzungstoken zusätzlich fest, welche Faktoren geprüft wurden, etwa im amr-Claim, kann jeder Dienst das selbst kontrollieren.

   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

   Automatisierte Regressionstests

   End-to-End-Tests melden ein Konto mit aktivem zweitem Faktor per rohem HTTP-Client an, und zwar auf jedem Login-Pfad, und stellen sicher, dass ohne Code kein geschützter Endpunkt erreichbar ist. So fällt ein Rückfall beim nächsten Release auf und nicht erst beim nächsten Angreifer.

   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)

Ergänzende Härtung

• Alle Login-Pfade gleich behandelnÄltere API-Versionen, mobile Apps, SSO, Token-Refresh und Passwort-Reset brauchen dieselbe Prüfung. Die OWASP-Empfehlungen zu MFA nennen ausdrücklich separate APIs, über die sich Nutzer anmelden können.
• Code-Eingaben begrenzenStrikte Grenzen für Fehlversuche bei der Code-Prüfung verhindern, dass sich ein sechsstelliger Code durchprobieren lässt.
• Challenge-Token eng fassenNach erfolgreicher Prüfung oder wenigen Fehlversuchen verwerfen und nie als Ersatz für ein Sitzungstoken akzeptieren.
• Auffällige Abläufe protokollierenErfolgreiche Passwortprüfungen ohne anschließende Code-Prüfung, gefolgt von Zugriffen auf sensible Endpunkte, sind ein starkes Signal für Monitoring und SOC.
• Endpunkte isoliert testenPentests und API-Security-Tests sollten Authentifizierungs-Endpunkte ohne Oberfläche prüfen und jede Antwort auf vorzeitig ausgegebene Tokens untersuchen.

Grundlagen: Multifactor Authentication Cheat Sheet (öffnet externe Website) · SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management (Juli 2025) (öffnet externe Website) · RFC 6238: TOTP: Time-Based One-Time Password Algorithm (Mai 2011) (öffnet externe Website) · RFC 8176: Authentication Method Reference Values (Juni 2017) (öffnet externe Website)

Diese Einordnung ist keine Rechtsberatung.