Cyber Security Academy · Lektion

Token-Angriffe und Härtung

Authentifizierungsabläufe vor Missbrauch schützen

Lektion 4 von 413 Schritte

Token-Angriffe und Härtung ist eine kostenlose Cyber Security Academy-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Cyber Security Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Cyber Security Academy-Kurs umfasst insgesamt 4 Lektionen.

Tokens als Anmeldedaten

In moderner Authentifizierung sind Tokens Anmeldedaten. Wer ein gültiges Bearer-Token besitzt, wird bis zu dessen Ablauf oder Widerruf als authentifizierte Partei behandelt.

Der Diebstahl eines Tokens entspricht damit dem Diebstahl von Anmeldedaten.
Bei der Absicherung geht es vor allem darum, die Token-Lebensdauer zu begrenzen, Tokens an einen Besitzer zu binden und einen schnellen Widerruf zu ermöglichen.

Diese Lektion behandelt Angriffe auf OAuth-, OIDC- und SAML-Tokens sowie die entsprechenden Schutzmaßnahmen.

JWT-Algorithmusverwechslung

Bei einem klassischen JWT-Angriff wird der alg-Header missbraucht.

Wird alg: none akzeptiert, kann ein Angreifer signaturlose Tokens fälschen.
Bei der Verwechslung von RS256 und HS256 signiert der Angreifer ein Token mit dem öffentlichen RSA-Schlüssel als HMAC-Geheimnis neu.

Abwehr: Legen Sie den erwarteten Algorithmus serverseitig fest und lassen Sie niemals zu, dass das Token den verwendeten Prüfpfad bestimmt.

Vulnerable: verify(token, key)  // alg taken from header
Hardened:   verify(token, key, { algorithms: ["RS256"] })
// reject alg:none, reject HS* when RS* expected

Token-Diebstahl durch XSS und Logs

Die häufigste Kompromittierung eines Tokens ist der schlichte Diebstahl eines gültigen Tokens.

XSS liest Tokens aus localStorage oder dem Speicher.
Tokens in URLs gelangen über den Browserverlauf, Referrer-Header und Server-Logs nach außen.
Ausführliches Logging von Authorization-Headern.

Verwenden Sie für Browser-Sitzungen bevorzugt httpOnly-, Secure- und SameSite-Cookies und entfernen Sie Tokens aus Logs und URLs.

Set-Cookie: session=...; HttpOnly; Secure; SameSite=Lax
// keeps JS (and thus XSS) from reading the token

Replay-Angriffe

Bei einem Replay-Angriff wird ein abgefangenes gültiges Token wiederverwendet, um als das Opfer zu handeln.

Schutz bieten kurze Ablaufzeiten, eine einmalige nonce (OIDC) und die Nachverfolgung von Assertion-IDs (SAML).
TLS verhindert das passive Abfangen im Netzwerk.
Sendergebundene Tokens verhindern die Wiederverwendung selbst dann, wenn sie gestohlen wurden.

Replay defenses:
  short exp + nonce/jti uniqueness
  TLS everywhere
  sender-constrained tokens (mTLS / DPoP)

Sendergebundene Tokens

Bearer-Tokens können von jedem verwendet werden, der sie besitzt. Sendergebundene Tokens werden an einen bestimmten Client-Schlüssel gebunden.

An mTLS gebundene Tokens (RFC 8705) verknüpfen das Token mit dem TLS-Zertifikat des Clients.
DPoP (RFC 9449) bindet das Token an einen Proof-of-Possession-Schlüssel, mit dem der Client jede Anfrage signiert.

Ein gestohlenes Token ist dann ohne den passenden privaten Schlüssel nutzlos.

DPoP: each request carries a signed proof JWT
  DPoP: <proof-jwt signed with client private key>
  Authorization: DPoP <access_token>

Kurze Lebensdauer und Refresh-Rotation

Begrenzen Sie den Zeitraum, in dem ein gestohlenes Token verwendet werden kann.

Halten Sie Access-Tokens kurzlebig (Minuten).
Verwenden Sie eine Refresh-Token-Rotation: Bei jedem Refresh wird ein neues Refresh-Token ausgegeben und das alte ungültig gemacht.
Erkennen Sie die Wiederverwendung eines bereits rotierten Refresh-Tokens als Hinweis auf einen Diebstahl und widerrufen Sie die gesamte Kette.

On /token refresh:
  issue new RT, invalidate old RT
  if old RT presented again -> breach -> revoke family

Token-Widerruf und Introspection

Selbstständige JWTs bleiben bis zu ihrem Ablauf gültig, was den Widerruf erschwert. Stellen Sie Mechanismen bereit, mit denen sich der Zugriff schnell unterbinden lässt.

Ein Widerrufs-Endpunkt (RFC 7009) macht Refresh- und Access-Tokens ungültig.
Introspection (RFC 7662) ermöglicht es einem Resource Server, den Status eines Tokens in Echtzeit zu prüfen.
Führen Sie für kritische Widerrufe anhand von jti eine Sperrliste.

POST /introspect  token=...
  -> { "active": true, "sub": "...", "scope": "read" }
POST /revoke      token=...

Durchsetzung von Audience und Scope

Ein gültiges Token ist nicht automatisch für Ihre API autorisiert. Erzwingen Sie die vorgesehene Verwendung.

Prüfen Sie aud, damit ein für einen anderen Dienst ausgestelltes Token nicht bei Ihrem Dienst wiederverwendet werden kann.
Erzwingen Sie den Scope für jeden Endpunkt; gehen Sie nicht davon aus, dass ein gültiges Token vollständigen Zugriff gewährt.
Validieren Sie iss, um Tokens nicht vertrauenswürdiger Aussteller zu blockieren.

So verhindern Sie die dienstübergreifende Wiederverwendung von Tokens und Confused-Deputy-Missbrauch.

Mix-up- und Cross-Provider-Angriffe

Wenn ein Client mehrere Identity Provider unterstützt, können Mix-up-Angriffe ihn dazu bringen, einen von einem IdP ausgestellten Code oder ein Token an einen anderen, vom Angreifer ausgewählten Endpunkt zu senden.

Der Client verliert den Überblick darüber, von welchem AS eine Response stammt.
Abwehr: Binden Sie Responses mithilfe des Parameters iss (RFC 9207) an den Aussteller und validieren Sie state für jeden Provider.

/authorize ... &state=<provider-bound>
callback must include &iss=<expected-AS>
client verifies iss matches the AS it started with

Sichere Speicherung und Übertragung

Wo und wie Tokens gespeichert werden, bestimmt das Risiko einer Offenlegung.

Browser-Sitzungen: httpOnly-, Secure- und SameSite-Cookies; vermeiden Sie localStorage.
Mobile Geräte: OS-Keychain/Keystore, niemals Klartextdateien.
Server: Secrets Manager, Verschlüsselung im Ruhezustand und Least-Privilege-Berechtigungen.
Verwenden Sie bei der Übertragung immer TLS; betten Sie Tokens niemals in Query-Strings ein.

Checkliste zur Token-Härtung

Führen Sie die Schutzmaßnahmen zu einer operativen Grundlage zusammen.

Legen Sie Algorithmen fest; weisen Sie alg: none und Verwechslungsangriffe zurück.
Validieren Sie iss, aud, exp, signature, nonce/state.
Kurze TTL für Access-Tokens sowie Refresh-Rotation mit Erkennung der Wiederverwendung.
Bevorzugen Sie sendergebundene Tokens (DPoP/mTLS) für APIs mit hohem Schutzbedarf.
Unterstützen Sie Widerruf und Introspection.
Speichern Sie Tokens sicher und halten Sie sie aus URLs und Logs heraus.

Hardening baseline:
  [ ] alg pinned, none rejected
  [ ] iss/aud/exp/sig/nonce validated
  [ ] short TTL + RT rotation + reuse detection
  [ ] DPoP/mTLS for sensitive scopes
  [ ] revoke + introspect available

Schnelltest: Gestohlene Tokens unschädlich machen

Wählen Sie die Maßnahme, die den Schaden durch den Token-Diebstahl selbst am besten begrenzt.

Beantworte es in der interaktiven Lektion

Zusammenfassung: Token-Angriffe und Härtung

Die wichtigsten Erkenntnisse:

Tokens sind Anmeldedaten; ihr Diebstahl entspricht einer Kontoübernahme.
Schützen Sie JWTs durch Festlegen der Algorithmen und die Validierung von iss, aud, exp, signature, nonce.
Begrenzen Sie die Gefährdung durch kurze Lebensdauern und Refresh-Rotation mit Erkennung der Wiederverwendung.
Sendergebundene Tokens (DPoP/mTLS) machen gestohlene Bearer-Tokens unschädlich.
Stellen Sie Widerruf und Introspection bereit und halten Sie Tokens aus URLs, Logs und localStorage heraus.

Kostenlos starten

Lerne Cyber Security Academy mit einem KI-Tutor — kostenlos

Schreibe und führe echten Code in deinem Browser aus, bekomme sofortige Hilfe von einem 24/7 KI-Tutor und setze dein Lernen im Web oder in der App fort.

Kurse: 76
Lektionen: 303

Kostenlos lernen Den vollständigen Kurs ansehen

Häufig gestellte Fragen

Ist die Lektion „Token-Angriffe und Härtung“ kostenlos?

Ja — der vollständige Text von „Token-Angriffe und Härtung“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Cyber Security Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Cyber Security Academy-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Token-Angriffe und Härtung“?

Authentifizierungsabläufe vor Missbrauch schützen Du übst Cyber Security Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Cyber Security Academy zu starten?

Keine Vorkenntnisse erforderlich. Cyber Security Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „Token-Angriffe und Härtung“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Cyber Security Academy-Lektion Code schreiben und ausführen?

Ja. Jede Cyber Security Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

← Zurück zu Cyber Security Academy