JWT tartalma: miért nem egyenlő a dekódolás az ellenőrzéssel?

A JSON Web Token (JWT) három szövegdarab, amelyet pontok kötnek össze: egy fejléc, egy payload és egy aláírás. Az első kettő csak kódolt, nem titkosított, ezért bárki, akinél a token van, elolvashatja őket. Az aláírás segítségével a szerver ellenőrizheti, hogy egy megbízható fél állította-e ki a tokent, és hogy nem módosította-e valaki. A token dekódolása megmutatja, mit állít. Csak az ellenőrzés mondja meg, hogy hihetsz-e neki.

JWT dekódolóLejárt a token, vagy még érvényes?Próbáld ki ingyen

A három rész

A token így néz ki: header.payload.signature. A jwt.io híres példatokenjének első része:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Az első két rész JSON, amelyet base64url-kódolással alakítottak szöveggé. Ez a forma URL-ekben is biztonságosan használható. Az első rész dekódolva:

{"alg":"HS256","typ":"JWT"}

Ugyanennek a példának a payloadja dekódolva:

{"sub":"1234567890","name":"John Doe","iat":1516239022}

A payload tartalmazza a claimeket, vagyis állításokat a felhasználóról vagy a munkamenetről. Az aláírás az első két részből és egy kulcsból számolódik, ezért egyetlen karakter módosítása után már nem egyezik. A base64url visszafejtéséhez nincs szükség kulcsra, ezért soha ne tegyél jelszót, privát kulcsot vagy személyes adatot a payloadba.

Regisztrált claimek

Az RFC 7519, a JWT-k szabványa, néhány rövid claimnevet fenntart:

iss (kiállító): ki hozta létre a tokent.
sub (alany): akire a token vonatkozik, általában felhasználói azonosító.
aud (címzett): az a szolgáltatás, amelynek a tokent szánják.
exp (lejárati idő): az időpont, utána a token érvénytelen.
nbf (nem korábban): az a legkorábbi időpont, amikortól a token érvényes.
iat (kiállítás ideje): a token létrehozásának időpontja.

Az időpontok az 1970. január 1-jétől (UTC) eltelt másodpercek, ezt hívják Unix-időnek. A példában nincs exp, ezért a szabvány szerint soha nem jár le. Egy valódi tokennek legyen lejárati ideje. Más nevek, például a role vagy az email, az alkalmazásra tartoznak.

A dekódolás nem ellenőrzés

A dekódolás a tokent a pontoknál szétbontja, visszafejti a base64url-t, és beolvassa a JSON-t. Megmutatja, mit állít a token, és ugyanezt teszi egy hamisított tokennel is, mert bárki írhat bármilyen claimet bármilyen aláírással.

Az ellenőrzés a helyes kulccsal újraszámolja az aláírást, és megnézi, hogy egyezik-e. Azt is ellenőrzi, hogy az exp és az nbf közrefogja-e az aktuális időt, valamint hogy az iss és az aud a szolgáltatás által elvárt értékek-e. Az az alkalmazás, amely ellenőrzés nélkül olvassa ki a role claimet, bárkiben megbízik, aki a tokent írta. Ez gyakori hiba.

HS256, RS256 és ES256

Az alg érték nevezi meg a módszert. Háromféle a leggyakoribb:

HS256 a HMAC SHA-256-tal. Egyetlen közös titkos kulcs ír alá és ellenőriz is, ezért a titoknak azon a szerveren kell maradnia, amely a tokeneket kiállítja.
RS256 egy RSA-aláírás SHA-256-tal. A kiállító privát kulccsal ír alá, a nyilvános kulccsal pedig bárki ellenőrizhet. Más szolgáltatások így tokeneket tudnak ellenőrizni anélkül, hogy létrehozni is tudnák őket.
ES256 egy ECDSA-aláírás a P-256 görbével és SHA-256-tal. Úgy működik, mint az RS256, de kisebb kulcsokkal és aláírásokkal.

Használd a HS256-ot, ha egyetlen szolgáltatás állítja ki és ellenőrzi a tokenjeit. Használd az RS256-ot vagy az ES256-ot, ha más szolgáltatásoknak olyan tokeneket kell ellenőrizniük, amelyeket nem ők állítottak ki.

A fejlécben megbízásból fakadó problémák

A fejlécet az írja, aki a tokent küldi, ezért az ellenőrzőnek nem szabad hagynia, hogy az határozza meg a szabályokat.

alg: none. Aláírás nélküli token deklarálhatja a "alg":"none" értéket. Egyes könyvtárak egykor elfogadták az ilyen tokeneket, és kihagyták az ellenőrzést. Az engedélyezett algoritmusokat a saját kódodban add meg, soha ne a tokenből vedd át.
Algoritmus-összekeverés. A szerver RS256-ot vár, és nyilvános kulcsa van. Egy támadó olyan HS256-os tokent küld, amelyet ezzel a nyilvános kulccsal, mint HMAC-titokkal írt alá. Az az ellenőrző, amely elfogadja bármelyik algoritmust, amelyet a fejléc megnevez, elfogadja ezt a tokent is. Minden kulcsot pontosan egy algoritmushoz kössél.
Gyenge titkok. A támadó birtokában van a fejléc, a payload és az aláírás, ezért offline tesztelheti a lehetséges titkokat. Egy rövid titkot vagy egy gyakori szót egy ilyen listával gyorsan megtörhet. Az RFC 7518 szerint egy HS256-kulcsnak legalább 256 bit hosszúnak és véletlenszerűnek kell lennie.

Éles token beillesztése egy weboldalba

Egy érvényes, le nem járt token bárki számára működik, aki birtokolja, lejártáig. Kezeld jelszóként. Mielőtt bármelyik oldalba beillesztenéd, derítsd ki, hogy az oldal elküldi-e szervernek. Egy teljesen a böngészőlapon futó eszköznek nincs erre szüksége. Bármelyik oldalt ellenőrizheted úgy, hogy a böngésző fejlesztői eszközeiben figyeled a hálózati kéréseit.

A tokeneket lejáratuk előtt általában nem lehet visszavonni, hacsak a szerver nem vezet listát róluk. Ha egy élő token kiszivárog, kérd meg a szolgáltatást, hogy vonja vissza a munkamenetet, vagy cserélje le a kulcsait. Ahol lehet, hibakereséshez teszt-környezetbeli tokent használj. A JWT dekódoló a három részt a böngészőlapodon olvassa be, és a beillesztett adatok sehova nem mennek.

Webhookok: ugyanaz az elv megosztott titokkal

A legtöbb webhook-szolgáltató a kérés törzséről HMAC-et küld egy fejlécben, amelyet a közös titkukkal számoltak ki. A fogadód ugyanazt a HMAC-et számolja ki, és összeveti a kettőt. A gyakori hibák apróak. A JSON a hash-elés előtt újraformázódik, így a bájtok megváltoznak. A teszt-titkot éles forgalomon használják. Vagy az aláírásokat sima szövegegyenlőséggel hasonlítják össze, ami időzítési információt szivárogtathat ki. Használj konstans idejű összehasonlítást.

A Webhook-aláírás ellenőrző a beillesztett titokból és törzsből számolja ki az aláírást a GitHub, a Stripe, a Slack, a Shopify vagy bármely HMAC-séma esetén, így láthatod, egyezik-e a két érték.

Rövid válaszok

Titkosított a JWT?

Nem. A szabványos JWT aláírt, bárki elolvashatja a fejlécét és a payloadját. Csak az aláírás védi a módosítástól.

Mi történik, ha módosítom a payloadot?

Az aláírás nem fog egyezni, ezért az ellenőrző szerver elutasítja a tokent. A claimek olvasása nem ellenőrzi az aláírást, ezért a dekódoló továbbra is a módosított változatot mutatja.