JWT-sårbarheter: alg=none och nyckelförväxling

JWT:er är kryptografiskt signerade, men många bibliotek har haft allvarliga sårbarheter. De mest utnyttjade är attacken alg=none, förväxlingsattacken RS256→HS256 och brute force-angrepp mot svaga hemligheter. Alla beror på att man litar på headerfält som angriparen styr.

JWT-specifikationen tillåter alg:"none" för osignerade token. Bristfälliga bibliotek accepterade detta och hoppade helt över signaturverifieringen. En angripare ändrar payloaden (t.ex. "role":"admin"), anger alg:"none", tar bort signaturen och servern godkänner token.

Original: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyIn0.SIG Attack: eyJhbGciOiJub25lIn0.eyJzdWIiOiJhZG1pbiJ9. (tom signatur, avslutande punkt). En sårbar server verifierar token framgångsrikt och beviljar administratörsåtkomst.

Acceptera aldrig alg:"none" i produktion. Vitlista uttryckligen tillåtna algoritmer: jwt.decode(token, key, algorithms=["HS256"]). De flesta moderna bibliotek (PyJWT 2+, jsonwebtoken 9+) avvisar alg=none som standard.

Om en server använder RS256 och en klient ändrar alg till HS256 kan servern verifiera med sin publika RSA-nyckel som HMAC-hemlighet. Eftersom den publika nyckeln är ... offentlig kan angriparen signera godtyckliga payloadar med den, och servern verifierar dem.

Steg: 1) Hämta den publika nyckeln från JWKS-endpointen. 2) Skapa en skadlig payload. 3) Signera med HMAC-SHA256 med de råa PEM-bytena från den publika nyckeln som HMAC-hemlighet. 4) Ange alg:"HS256" i headern. 5) Serverns HS256-kodväg verifierar token framgångsrikt.

Ange alltid den förväntade algoritmen explicit i verifieringsanropet. Härled aldrig algoritmen från token-headern. Använd separata kodvägar för RS256 och HS256 som inte kan växlas av anroparen.

HS256 med svaga hemligheter (mindre än 256 bitars entropi) kan knäckas offline med brute force. Verktyg som hashcat stöder JWT-knäckning: hashcat -a 0 -m 16500 token.txt wordlist.txt. Använd kryptografiskt slumpmässiga hemligheter på minst 32 byte.

kid-headern (nyckel-ID:t) väljer vilken nyckel som ska användas. Om servern använder kid som parameter i en SQL-fråga eller som filsökväg utan sanering: kid="../../dev/null" → HMAC med en tom nyckel → förfalskad token godkänns. Sanera alltid kid.

jwk-headern bäddar in en publik nyckel för verifiering. En sårbar server kan använda den inbäddade nyckeln direkt, vilket låter angriparen tillhandahålla sitt eget nyckelpar, signera token med den privata nyckeln och bädda in den publika nyckeln. Verifiera endast mot registrerade nycklar.

Vissa implementationer glömde att kontrollera exp-anspråket eller använde serverns klocka inkonsekvent. Validera alltid exp, nbf och iat explicit. Använd ett bibliotek som kontrollerar dessa som standard och inaktivera aldrig validering av anspråk i produktion.

JWT-sårbarheter uppstår genom att man litar på alg-headern, accepterar alg=none och använder svaga hemligheter. Åtgärd: lås fast algoritmerna hos verifieraren, använd starka hemligheter och sanera kid. Nästa steg: säkra metoder för JWT-implementation.