JWT-Schwachstellen
Was ist JWT-Schwachstellen?
JWT-SchwachstellenKlassen von Implementierungsfehlern bei der JSON-Web-Token-Validierung, die das Falschen von Tokens, Rechteausweitung oder Umgehung der Authentifizierung erlauben.
JSON Web Tokens sind in Authentifizierung und API-Autorisierung weit verbreitet, doch ihre flexiblen Signaturoptionen haben mehrere wiederkehrende Schwachstellenklassen hervorgebracht. Der Klassiker alg=none tritt auf, wenn der Verifier ein unsigniertes Token akzeptiert. Schwache HS256-Secrets lassen sich offline brechen und ermoglichen beliebige Tokens. Key Confusion entsteht, wenn ein Server ein HS256-Token mit dem offentlichen RSA-Schlussel als HMAC-Secret validiert. Weitere Probleme: fehlende Signaturprufung, Akzeptanz abgelaufener Tokens, kid-Header-Injection (Path Traversal, SQLi) sowie jwk/jku-Angriffe. Gegenmassnahmen: Algorithmus serverseitig fixieren, starke asymmetrische Schlussel, kid per Allowlist validieren und JWTs als untrusted Input behandeln.
● Beispiele
- 01
Header {"alg":"none"} wird von einer fehlerhaft konfigurierten Bibliothek akzeptiert.
- 02
Server validiert ein RS256-Token mit dem Public Key als HS256-HMAC-Secret.
● Häufige Fragen
Was ist JWT-Schwachstellen?
Klassen von Implementierungsfehlern bei der JSON-Web-Token-Validierung, die das Falschen von Tokens, Rechteausweitung oder Umgehung der Authentifizierung erlauben. Es gehört zur Kategorie Anwendungssicherheit der Cybersicherheit.
Was bedeutet JWT-Schwachstellen?
Klassen von Implementierungsfehlern bei der JSON-Web-Token-Validierung, die das Falschen von Tokens, Rechteausweitung oder Umgehung der Authentifizierung erlauben.
Wie funktioniert JWT-Schwachstellen?
JSON Web Tokens sind in Authentifizierung und API-Autorisierung weit verbreitet, doch ihre flexiblen Signaturoptionen haben mehrere wiederkehrende Schwachstellenklassen hervorgebracht. Der Klassiker alg=none tritt auf, wenn der Verifier ein unsigniertes Token akzeptiert. Schwache HS256-Secrets lassen sich offline brechen und ermoglichen beliebige Tokens. Key Confusion entsteht, wenn ein Server ein HS256-Token mit dem offentlichen RSA-Schlussel als HMAC-Secret validiert. Weitere Probleme: fehlende Signaturprufung, Akzeptanz abgelaufener Tokens, kid-Header-Injection (Path Traversal, SQLi) sowie jwk/jku-Angriffe. Gegenmassnahmen: Algorithmus serverseitig fixieren, starke asymmetrische Schlussel, kid per Allowlist validieren und JWTs als untrusted Input behandeln.
Wie schützt man sich gegen JWT-Schwachstellen?
Schutzmaßnahmen gegen JWT-Schwachstellen kombinieren typischerweise technische Kontrollen und operative Praktiken, wie in der Definition oben beschrieben.
● Verwandte Begriffe
- identity-access№ 574
JWT (JSON Web Token)
Kompaktes, URL-sicheres Token-Format (RFC 7519) mit signierten JSON-Claims; weit verbreitet als Access Token, ID Token und Sitzungscontainer.
- identity-access№ 088
Bearer Token
Opake oder strukturierte Credential (RFC 6750), die allein durch Besitz Zugriff auf eine Ressource gewahrt - ohne Nachweis, dass der Trager der rechtmassige Inhaber ist.
- identity-access№ 007
Access Token
Kurzlebige Credential, ausgestellt vom Authorization Server, mit der ein Client geschutzte Ressourcen einer API im Namen eines Nutzers oder Dienstes aufruft.
- appsec№ 052
API-Sicherheit
Disziplin, APIs so zu entwerfen, zu bauen und zu betreiben, dass Authentifizierung, Autorisierung, Datenoffenlegung und Missbrauchsresistenz auch unter Angriff Bestand haben.
- identity-access№ 076
Authentifizierung
Verfahren, mit dem überprüft wird, dass eine Entität – Benutzer, Gerät oder Dienst – tatsächlich diejenige ist, die sie zu sein vorgibt, bevor ein Zugriff gewährt wird.
- compliance№ 781
OWASP Top 10
Awareness-Dokument der OWASP, das die kritischsten Sicherheitsrisiken für Webanwendungen auflistet und periodisch anhand realer Schwachstellendaten aktualisiert wird.