VenedyOWASP-Bewertung dieser Seite (Risk-Tabelle): Kategorisierung API Specific; Exploitability (Ausnutzbarkeit) Easy; Prevalence (Verbreitung) Common; Detectability (Auffindbarkeit) Easy; Technical Impact (technische Schwere) Severe; Business Impact: Specific (kundenspezifisch). Begründung laut OWASP: Der Authentifizierungsmechanismus ist exponiert und damit ein leichtes Ziel (auch wenn für manche Probleme fortgeschrittene Fähigkeiten nötig sind, sind Exploit-Tools meist verfügbar); verbreitete Fehlannahmen über Authentifizierungsgrenzen und Implementierungskomplexität machen die Schwachstelle häufig; Methoden zur Erkennung sind verfügbar und leicht zu erstellen.
Wie der Angriff funktioniert
Die API prüft die Identität eines Nutzers fehlerhaft oder unzureichend. Laut OWASP gibt es dafür mehrere typische Ursachen.
- Credential Stuffing und Brute-Force: Die API erlaubt das Durchprobieren geleakter Benutzername/Passwort-Listen (Credential Stuffing) oder Brute-Force gegen ein einzelnes Konto ohne Captcha oder Account-Sperre.
- Schwache Passwörter: Sie akzeptiert schwache Passwörter.
- Sensible Daten in der URL: Sie sendet sensible Daten wie Auth-Tokens oder Passwörter in der URL.
- Fehlende Passwortbestätigung: Sie erlaubt sensible Operationen (E-Mail-Adresse oder Passwort ändern) ohne erneute Passwortbestätigung.
- Fehlerhafte Token-Validierung: Sie validiert die Echtheit von Tokens nicht korrekt, akzeptiert unsignierte oder schwach signierte JWTs ({"alg":"none"}) oder prüft das JWT-Ablaufdatum nicht.
- Schwacher Passwortschutz: Sie nutzt Klartext-, unverschlüsselte bzw. schwach gehashte Passwörter und schwache Verschlüsselungs-Schlüssel.
Bei Microservices ist die API zusätzlich verwundbar, wenn andere Microservices ohne Authentifizierung zugreifen können oder schwache bzw. vorhersagbare Tokens zur Authentifizierung genutzt werden.
Der Angreifer nutzt diese Lücken, um sich gültige Tokens zu verschaffen oder bestehende Schutzmechanismen (z. B. Rate Limiting) zu umgehen.
Schwächen bei Login und Token ermöglichen Identitätsübernahme.
Beispiel
OWASP-Szenario 1 (Umgehung des Rate Limitings per GraphQL-Batching): Der Login-Endpunkt erlaubt nur 3 Anfragen pro Minute - eigentlich ein Brute-Force-Schutz.
- Normale Login-Anfrage:
POST /graphqlmit{ "query":"mutation { login(username:\"\", password:\"\") { token } }" } - Der Angreifer umgeht das Limit, indem er viele Login-Versuche in EINEM Request bündelt (GraphQL Query Batching). Da die API nur Requests, nicht einzelne enthaltene Mutationen zählt, kann er pro erlaubtem Request viele Passwörter gegen das Opferkonto durchprobieren:
POST /graphqlmit einem Array aus mehrerenlogin-Mutationen für victim mit unterschiedlichen Passwörtern (password, 123456, qwerty, ..., 123). - Sobald ein Passwort stimmt, wird das gültige
tokenzurückgegeben und der Angreifer hat das Konto übernommen.
OWASP führt zusätzlich ein Szenario 2: Ein PUT /account ändert die Konto-E-Mail ohne erneute Passwortbestätigung; ein Angreifer mit gestohlenem Auth-Token kann so durch Ändern der E-Mail und anschließenden Passwort-Reset das Konto übernehmen.
Auswirkung
Laut OWASP können Angreifer die vollständige Kontrolle über fremde Konten im System erlangen. Sie können persönliche Daten der Opfer lesen und sensible Aktionen in deren Namen ausführen.
Besonders kritisch: Die Systeme können die Aktionen des Angreifers in der Regel nicht von denen eines legitimen Nutzers unterscheiden.
Geschäftlich bedeutet das Kontoübernahmen (Account Takeover), Datenschutzverletzungen und Betrug im Namen echter Kunden.
So schützt man sich
- Alle möglichen Authentifizierungs-Flows kennen (mobil, Web, Deep Links, One-Click-Logins etc.) und die eigenen Entwickler explizit nach vergessenen Flows fragen.
- Authentifizierungsmechanismen wirklich verstehen - OAuth ist KEINE Authentifizierung, API-Keys ebenfalls nicht.
- Authentifizierung, Token-Erzeugung und Passwortspeicherung nicht selbst neu erfinden, sondern etablierte Standards nutzen.
- Endpunkte für Passwort-Wiederherstellung / 'Passwort vergessen' genauso schützen wie Login-Endpunkte (Brute-Force-Schutz, Rate Limiting, Lockout).
- Für sensible Operationen (z. B. Ändern der Konto-E-Mail oder der 2FA-Telefonnummer) erneute Authentifizierung verlangen.
- OWASP Authentication Cheat Sheet anwenden.
- Wo möglich Multi-Faktor-Authentifizierung (MFA) implementieren.
- Anti-Brute-Force-Mechanismen gegen Credential Stuffing, Dictionary- und Brute-Force-Angriffe einsetzen - strenger als das normale Rate Limiting.
- Account-Lockout- bzw. Captcha-Mechanismen gegen Angriffe auf einzelne Nutzer sowie Prüfungen auf schwache Passwörter implementieren.
- API-Keys nicht zur Nutzer-Authentifizierung verwenden, sondern nur zur Authentifizierung von API-Clients.