Authentifizierung, Logik & Architektur-Fehler.

Password-Recovery — wiederkehrende Fehler

• Vorhersagbare Tokens. Reset-Tokens basierend auf Timestamp + User-ID. Test: zwei Resets Sekunden auseinander anfordern, Tokens diffen.
• Response-Timing-Leak. POST /forgot-password {email:x@y} liefert 200 in 80ms für nicht-existierende User, 300ms für existierende. Username-Enumeration via Timing.
• Body-Shape-Leak. "Wir haben eine E-Mail gesendet" vs "Wenn die Adresse existiert, wurde eine E-Mail gesendet". Erstere leakt.
• Token-Reuse / Non-Expiry. Gleiches Token funktioniert nach erster Nutzung; gültig Tage statt Minuten.
• Second-Factor-Downgrade. Password-Reset umgeht TOTP. Nach Reset User eingeloggt ohne MFA-Challenge.
• Reset-Link enthält Session-Token. Link mit Kollegen teilen teilt die Session.
• Host-Header-Injection. Host: attacker.com im Reset-Request lässt E-Mail-Link auf Angreifer zeigen. Häufig in Apps, die Host-Header zum Konstruieren der Reset-URL nutzen.

JWT — häufige Misuses

• alg: none. Token mit Header {"alg":"none"} und leerer Signatur re-signen. Server akzeptiert wenn er Algorithmen nicht whitelisted hat.
• HS256 mit RSA-Public-Key. Server erwartet RS256, akzeptiert HS256. Angreifer nutzt den RSA-Public-Key als HMAC-Secret → forged beliebige Tokens.
• Key-ID-Injection. kid-Header in SELECT key FROM keys WHERE id=? ohne Parameterisierung → SQL-Injection. Oder kid: ../../../etc/passwd für File-Read.
• Audience-Claim ignoriert. Token für Service A ausgestellt, von Service B mit gleichem Signing-Key akzeptiert. Cross-Service-Replay.
• Expiry ignoriert. Token vom letzten Quartal noch akzeptiert.
• Verteidigung. Erlaubten Algorithmus hardcoden. iss, aud, exp, nbf explizit validieren. Tokens mit unerwarteten Headern abweisen.

CORS-Misconfigs

• Reflect-and-Allow-Credentials. Server liest Origin, echot ihn als Access-Control-Allow-Origin, setzt Allow-Credentials: true. Jede Angreifer-Site kann authentifizierte Responses lesen.
• Null-Origin erlaubt. Sandbox-iframes und data:-URLs senden Origin: null. Erlauben heißt: sandboxed Page kann exfiltrieren.
• Subdomain-Wildcard. *.example.com trusted; Angreifer übernimmt vergessene Subdomain → trusted Origin.
• Test. Request mit Origin: https://attacker.com senden. Wenn Response Access-Control-Allow-Origin: https://attacker.com + Allow-Credentials: true enthält, ausnutzbar.

API-first-Fallstricke

• Mass-Assignment. PATCH /user/me {role:"admin"} akzeptiert, weil JSON-Deserializer per default alle Felder bindet (Rails Strong-Params aus, Spring kein DTO).
• GraphQL-Introspection in Produktion. {__schema{types{name,fields{name}}}} liefert volles Schema. Versteckte Mutations finden.
• GraphQL-Query-Cost-DoS. Nested Query: {user{posts{user{posts{user{posts{id}}}}}}}. Kein Depth-/Cost-Limit = einzelner Request legt Server lahm.
• Batched-Mutation-Auth. Auth-Check auf Single-Mutation-Endpoint, fehlt auf Batched-Mutation-Endpoint.
• HTTP-Method-Override. POST mit X-HTTP-Method-Override: DELETE umgeht WAF-Regel, die auf DELETE filterte.

Arbeits-Top-10 der Business-Logic-Fehler

1. Negative Menge. Warenkorb akzeptiert quantity: -3; Total wird negativ; Refund ausgestellt.
2. Rabatt-Stacking. Zwei Single-Use-Codes via parallele Requests angewendet.
3. Step-Skipping. Direkter POST auf Schritt 5 eines 5-Schritt-Wizards ohne Schritte 1–4.
4. Race-Condition-Double-Spend. Zwei gleichzeitige Withdrawal-Requests, Balance nur einmal dekrementiert.
5. Currency-Rounding-Missbrauch. 0.0001 BTC wiederholt kaufen wenn Rundung dem User zugutekommt.
6. Trial-Period-Reset. Account löschen + mit gleicher E-Mail neu erstellen = neuer Trial.
7. Autorisierung auf falscher Schicht. UI versteckt Admin-Button, API-Endpoint prüft Rolle nicht.
8. Cancel nach Success. Cancel-Order-Endpoint reverst Inventory-Dekrement, aber nicht den Discount-Verbrauch.
9. Voucher-/Referral-Exploit. Self-Referral via zwei Accounts, beide bekommen Bonus.
10. State-Machine-Bypass. Order geht von PENDING direkt zu FULFILLED ohne PAID.