Produktionslektionen zu alg none
Warum der alte alg-none-Fehler weiter relevant ist, wie er in modernen Diensten auftaucht und wie man ihn sauber testet.
alg: none wird oft wie alte JWT-Folklore behandelt, trotzdem prüfe ich diesen Fall noch in echten Assessments. Nicht weil jede Bibliothek heute unsignierte Tokens akzeptiert, sondern weil Produktionssysteme Tokens selten an genau einer sauberen Stelle validieren. Ein Gateway prüft die Signatur, ein interner Worker dekodiert nur Claims, und eine Admin-Route vertraut einem Header, der angeblich nur intern gesetzt wird. So bekommt eine alte Fehlerklasse neue Lebensräume.
Was wirklich schiefgeht
Der Fehler ist meist keine Bibliothek, die stolz unsignierte Tokens akzeptiert. Gefährlich wird ein Entwicklerpfad, bei dem Verifikation im lokalen Test optional war und diese Option überlebt hat. In Node-, Python-, Java- und Go-Stacks sieht das Muster ähnlich aus: Code dekodiert ein Token, um sub, role oder tenant_id zu lesen, und nimmt danach an, dass eine andere Schicht es geprüft hat. Angreifer brauchen dafür keine Raffinesse. Sie entfernen die Signatur, setzen den Header auf {"alg":"none"} und ändern einen Claim mit sichtbarer Autorisierungswirkung.
Ein nützlicher Test vergleicht Antworten, nicht nur Statuscodes. Wenn /api/me das Token ablehnt, aber /api/admin/reports nach einer Claim-Änderung einen anderen Fehler liefert, ist das ein Signal. Vielleicht wurde das Token vor der Prüfung geparst. Vielleicht enthalten Autorisierungslogs jetzt vom Angreifer kontrollierte Kennungen. Das ist kein harmloses Rauschen.
Eine praktische Testabfolge
Beginne mit einem gültigen Token eines Kontos mit niedrigen Rechten. Dekodiere es lokal, behalte die Payload-Struktur bei und erstelle eine unsignierte Variante. Ändere jeweils nur einen Claim. role ist auffällig, aber tenant_id, scope, aud und Feature-Flags zeigen oft mehr. Sende das Token an Endpunkte hinter unterschiedlichen Middlewares, besonders Job-APIs, GraphQL-Resolver, Datei-Downloads und Admin-JSON-Routen, die später ergänzt wurden.
Was Verteidiger loggen sollten
Verifikationsfehler sollten früh und langweilig sein. Logge Header-Algorithmus, kid, Issuer, Audience, Pfad und Ablehnungsgrund, aber nie das rohe Token. Alarme für alg: none lohnen sich, weil das aktive Manipulation anzeigt und keine normale Expiration. Ergänze außerdem einen negativen CI-Test, der ein unsigniertes Token durch jeden Verifier schickt.
Die Produktionslehre
Die Korrektur ist eine Policy, nicht nur ein Bibliotheksupdate. Verifier sollten erlaubte Algorithmen im Code pinnen, Tokens vor jeder Claim-Nutzung ablehnen und eine einzige interne Schnittstelle für vertrauenswürdige Claims bereitstellen. Wenn ein Handler einen generischen Decode-Helper aufrufen und ein Dictionary erhalten kann, wird ihn irgendwann jemand zur Autorisierung verwenden. Der sichere Weg muss kürzer sein als der unsichere.