JWT-biztonság: sérülékenységek, támadások és védekezés

A JSON Web Token (JWT) mára az állapotmentes hitelesítés alapértelmezett eszköze a webalkalmazásokban. Rugalmas, és éppen ezért könnyű végzetesen elrontani a beállításait. Amikor egy vizsgálat során JWT-t látunk, nem a munkamenet azonosítóját látjuk benne, hanem kriptográfiai támadási felületet.

A JWT felépítése: fejléc, payload, aláírás

A JWT három részből áll: fejlécből, payloadból és aláírásból, ezeket pont (.) választja el egymástól. Proxyban elkapva egyetlen hosszú, véletlenszerűnek tűnő karakterláncnak látszik. Egy valódi példa:

eyJraWQiOiI5MTM2ZGRiMy1jYjBhLTRhMTktYTA3ZS1lYWRmNWE0NGM4YjUiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJwb3J0c3dpZ2dlciIsImV4cCI6MTY0ODAzNzE2NCwibmFtZSI6IkNhcmxvcyBNb250b3lhIiwic3ViIjoiY2FybG9zIiwicm9sZSI6ImJsb2dfYXV0aG9yIiwiZW1haWwiOiJjYXJsb3NAY2FybG9zLW1vbnRveWEubmV0IiwiaWF0IjoxNTE2MjM5MDIyfQ.SYZBPIBg2CRjXAJ8vCER0LA_ENjII1JakvNQoP-Hw6GG1zfl4JyngsZReIfqRvIAEi5L4HV0q7_9qGhQZvy9ZdxEJbwTxRs_6Lb-fZTDpW6lKYNdMyjw45_alSCZ1fypsMWz_2mTpQzil0lOtps5Ei_z7mM7M8gCwe_AGpI53JxduQOaB5HkT5gVrv9cKu9CsW5MS6ZbqYXpGyOG5ehoxqm8DL5tFYaW3lB50ELxi0KsuTKEbD0t5BCl0aCR2MBJWAbN-xeLwEenaqBiwPVvKixYleeDQiBEIylFdNNIMviKRgXiYuAvMziVPbwSgkZVHeEdF5MQP1Oe2Spac-6IfA

A fejléc és a payload egyszerű, Base64Url-kódolású JSON-objektum. Kódolt, nem titkosított: kulcs nélkül elolvassa bárki, aki hozzájut a tokenhez.

A JWT három része

A JWT – pontosabban JWS, vagyis a JWT aláírt változata – három, ponttal elválasztott szakaszból áll: Header.Payload.Signature.

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

{ "sub": "andrej", "role": "hacker" }

HMACSHA256(
    base64UrlEncode(header) + "." +
    base64UrlEncode(payload),
    "secret"
) = MmM0ZGMxM2Y1NWQ2YTY2YTE

A fejléc

A fejléc magáról a tokenről árul el adatokat: a típusát és azt a kriptográfiai algoritmust, amellyel aláírták. A fenti token első szakasza ezt adja vissza:

{
    "kid": "9136ddb3-cb0a-4a19-a07e-eadf5a44c8b5",
    "alg": "RS256"
}

A payload

A payload hordozza a felhasználóra vonatkozó claimeket, és egy vizsgálat során ez az első számú célpont. A példa középső szakasza így néz ki:

{
    "iss": "portswigger",
    "exp": 1648037164,
    "name": "Andrej Šebeň",
    "sub": "andrej",
    "role": "pentester",
    "email": "andrej@haxoris.com",
    "iat": 1516239022
}

Az aláírás

A fejlécet és a payloadot bárki elolvashatja és át is írhatja, ezért a JWT-re épülő hitelesítés egésze a kriptográfiai aláíráson múlik.

A tokent kiállító szerver a Base64Url-kódolású fejlécből és payloadból titkos kulccsal képez lenyomatot. Ez két dolgot garantál:

1. Az aláírás közvetlenül a token többi részéből származik: ha a fejlécben vagy a payloadban akár egy bájt megváltozik, az aláírás már nem illik hozzá.
2. A szerver titkos kulcsa nélkül nem lehet érvényes aláírást előállítani hamisított fejléchez vagy payloadhoz.

Mit keres a támadó egy JWT-ben?

A JWT tervezésénél fogva olvasható, ezért a támadó felderítési anyagként kezeli, nem titkosított csomagként. A logikai hibák jellemzően a payloadban ülnek. Ezeket a claimeket nézzük meg elsőként:

Felderítés a payloadból: amit egy token elárul

A payloadot bárki elolvassa, akinél a token megfordul, tehát a fejlesztőnek nyilvános adatként kell kezelnie. Vizsgálatok során rendszeresen találunk egyedi claimekben olyan belső részletet, aminek ott semmi keresnivalója:

• A belső hálózat térképe: az olyan claimek, mint a "node_ip": "10.0.4.12", a "cluster": "prod-us-east-1a" vagy a "db_host": "internal-db.local", elárulják a belső architektúrát és a használt címtartományokat.
• A keretrendszer és az identitásszolgáltató: a claimek elnevezése megmutatja a technológiai hátteret. A http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name egyértelműen Microsoft .NET / Entra ID rendszert jelez, így rögtön az arra jellemző sérülékenységeket keressük.
• Személyes adatok: feleslegesen kiadott e-mail-cím, telefonszám, teljes név vagy lakcím – ezek a tokenben azonnal adatvédelmi kockázatot jelentenek (GDPR, CCPA).
• Tenantok és szerepkörök felderítése: a "tenant_id": "uuid", az "is_god_mode": false vagy a "permissions": ["read:profile"] kirajzolja a jogosultsági modellt, és készen adja a paraméterneveket a jogosultságeszkalációhoz.

Egy valódi, túl bőbeszédű JWT-payload:

{
  "iss": "auth.internal-corp.local",
  "sub": "usr_99812",
  "email": "andrej@haxoris.com",
  "role": "admin",
  "internal_ip": "10.240.12.88",
  "db_shard": "shard-04-eu",
  "is_admin": true,
  "exp": 1748037164
}

Access token és refresh token: architektúra és tárolás

A biztonságos JWT-használat két tokenre épül: a rövid életű access tokenre (bearer token) és a hosszú életű refresh tokenre. A rossz tárolási hely a leggyakoribb hiba, amelyet ezen a területen jelentünk.

Access token (bearer token)

• Az access token az API-hívásokat engedélyezi, és szándékosan rövid életű: jellemzően 5–15 perc.
• A helye kizárólag az alkalmazás memóriája. A localStorage és a sessionStorage kiesik: egyetlen sikeres XSS elég ahhoz, hogy a token a támadóhoz kerüljön.

Refresh token

• A refresh token egyetlen feladata, hogy a lejárt access token helyett újat lehessen kérni.
• A helye HttpOnly, Secure, SameSite cookie: a JavaScript nem olvassa ki, az XSS-sel elkövetett tokenlopás sokkal nehezebb lesz, és a CSRF kockázata is csökken.

Gyakori JWT-támadások egy vizsgálat során

Egy webalkalmazás vizsgálatakor jellemzően végigmegyünk a következő támadási irányokon.

A. Hibák az aláírás ellenőrzésében

A JWT-sérülékenységek nagy része nem a kriptográfia gyengeségéből ered, hanem abból, hogy a szerver rosszul ellenőrzi az aláírást. Néhány könyvtár korábban elfogadta a none algoritmust: ilyenkor az aláírás egyszerűen elhagyható, a claimek – például a felhasználó szerepköre – pedig szabadon átírhatók. A ma használt könyvtárak alapértelmezés szerint elutasítják a none algoritmust, a hiba mégis előjön régi alkalmazásokban és saját fejlesztésű JWT-kezelésben. Nem szokványos technológiai háttér esetén mindig érdemes megnézni.

A másik klasszikus az algorithm confusion. Ez a JWT egyik legsúlyosabb hibája, úgyhogy érdemes pontosan végigkövetni.

• Az RS256 aszimmetrikus algoritmus. A szerver a privát kulcsával írja alá a tokent, és a hozzá tartozó publikus kulccsal ellenőrzi. A publikus kulcs sokszor bárki számára elérhető – például a /.well-known/jwks.json végponton.
• A HS256 szimmetrikus algoritmus. A szerver ugyanazzal a megosztott titokkal ír alá és ellenőriz.

A támadás akkor működik, ha a szerver mindkét algoritmust elfogadja, és sehol nincs rögzítve, melyiket várja:

1. A támadó megszerzi a szerver publikus kulcsát, jellemzően egyenesen a JWKS-végpontról.
2. Átírja a payloadot, például a "role": "user" értéket "role": "admin" értékre.
3. A fejlécben az "alg": "RS256" helyett "alg": "HS256" értéket állít be.
4. A teljes módosított tokent (fejléc és payload) újra aláírja, méghozzá a publikus kulccsal mint HS256-titokkal.
5. A szerver megkapja a tokent, látja az alg: HS256 értéket, és a publikus kulcsot HMAC-titokként használva ellenőrzi. Egyezik – a hamisított token átmegy.

A hiba gyökere nem a kriptográfia, hanem az, hogy a szerver vakon a klienstől kapott alg fejlécre bízza, hogyan ellenőrizze a tokent. Az alg átírása normális esetben érvénytelenítené az aláírást, hiszen az aláírás a fejlécre és a payloadra együtt készül. Csakhogy a támadó az egész módosított tokent újra aláírja, így a lecserélt algoritmushoz tartozó aláírás tökéletesen érvényes.

A mai könyvtárak nagyrészt bezárták ezt a rést, régi alkalmazásokban és saját JWT-implementációkban azonban továbbra is felbukkan.

B. Gyenge aláíró kulcsok

Ha az alkalmazás szimmetrikus algoritmussal (HS256) ír alá, pontosan annyira biztonságos, amennyire az aláíráshoz használt titok.

Egy vizsgálat során elkapott JWT teljesen offline támadható, Hashcattel vagy John the Ripperrel. A cégnév, a szótári szó és a kitalálható jelmondat általában percek alatt elesik, onnantól pedig a támadó bármelyik felhasználó nevében állít ki érvényes tokent – anélkül, hogy még egyszer hozzányúlna az alkalmazáshoz.

C. Injekció a fejlécparamétereken keresztül

A JWT fejléce opcionális paramétereket is tartalmazhat – ilyen a kid (Key ID) és a jku (JWK Set URL) –, amelyek megmondják a szervernek, melyik kulccsal ellenőrizzen. Az értékeket a kliens küldi, tehát ha a szerver ellenőrzés nélkül megbízik bennük, komoly rés nyílik.

Gyakori támadási irányok:

• a jku paraméter átírása a támadó saját JWKS-végpontjára;
• directory traversal a kid paraméteren keresztül, ha a szerver közvetlenül a fájlrendszerből tölti be a kulcsokat;
• SQL-injekció ott, ahol a kid értékét összefűzéssel illesztik egy SQL-lekérdezésbe.

A kiforrott JWT-könyvtárak ezeket az eseteket biztonságosan kezelik, a saját ellenőrzési logikából viszont máig kerülnek megállapítások a jelentéseinkbe.

D. Ellenőrizetlen claimek

Az érvényes aláírás önmagában nem jelenti azt, hogy a tokenben meg lehet bízni. Az alkalmazásnak minden biztonsági szempontból fontos claimet ellenőriznie kell.

Vizsgálatok során rendszeresen találunk olyan API-t, amely:

• figyelmen kívül hagyja az exp claimet, és elfogadja a lejárt tokent;
• nem ellenőrzi a címzettet (aud), így ugyanaz a token egy másik szolgáltatásban is működik;
• bármilyen kiállítót (iss) elfogad;
• kizárólag a klienstől érkező claimekre – role, tenant, permissions – támaszkodik, és a szerveroldalon nem kényszeríti ki a jogosultságokat.

A gyakorlatban az ilyen logikai hibák sokszor többet érnek a támadónak, mint a kriptográfiai gyengeségek: teljesen szabályos tokent lehet velük olyasmire használni, amire senki nem számított.

Eszközök a JWT-k vizsgálatához

Base64-et dekódolni és aláírást hamisítani kézzel lassú. Az automatizáláshoz ezeket az eszközöket használjuk:

• JWTAuditor: kliensoldali, kifejezetten pentesztereknek készült platform. Gyors tokenvizsgálat, automatikus ellenőrzések (none algoritmus, fejlécinjekció) és offline törés – anélkül, hogy az ügyfél érzékeny tokenjei idegen telemetriába kerülnének.
• Burp Suite (JWT Editor bővítmény): a dinamikus tesztek alapja. A HTTP-forgalmat proxyban elfogva menet közben módosítjuk vele a tokent.
• JWT.io: az Auth0 tartja karban. Gyors kézi dekódoláshoz, a token szerkezetének és aláírásának ellenőrzéséhez a felderítés elején.
• JWTLens: könnyű, adatvédelem-központú alternatíva. A tokent teljes egészében a böngészőben dekódolja és ellenőrzi, a natív Web Crypto API-val, tehát a tokenek és a kulcsok nem hagyják el a gépet. Az ellenőrzés egyetlen hálózati kérést sem küld, így algoritmust és aláírást biztonságosan lehet vele megnézni.

Hogyan védhető meg egy JWT-alapú hitelesítés?

Ahhoz, hogy az alkalmazás ne a jelentés kritikus megállapításai között végezze, ezt az öt szabályt érdemes kikényszeríteni:

• Rögzítse az elvárt algoritmust: a beérkező token soha ne dönthesse el, hogyan kell ellenőrizni. Állítson be egyetlen konkrét algoritmust (például RS256), a none algoritmust pedig feltétel nélkül utasítsa el.
• Ellenőrizze mindegyik claimet: az érvényes aláírás csak annyit bizonyít, hogy a tartalomhoz senki nem nyúlt hozzá – azt nem, hogy a token most, ennél a felhasználónál érvényes. Minden egyes kérésnél nézze meg az exp, az iss és az aud értékét.
• Kezelje root jelszóként a szimmetrikus titkot: ha az architektúra szimmetrikus aláírást kíván (HS256), a kulcsnak legalább 256 bit entrópiája legyen, kriptográfiailag biztonságos generátorból származzon, és környezeti változóba vagy titokkezelőbe kerüljön – soha ne a forráskódba.
• A kódolás nem titkosítás: a payloadban nincs helye érzékeny adatnak, személyes adatnak vagy jelszónak. Aki elkapja a tokent, egy másodperc alatt visszafejti a Base64-kódolást.
• Válassza szét a tárolást: a rövid életű access token nem kerülhet localStorage-ba vagy sessionStorage-ba, ahonnan egyetlen XSS kiviszi. Az access token a böngésző memóriájában marad, a hosszú életű refresh token pedig Secure, HttpOnly, SameSite cookie-ba való.

Haladó védelem: a phantom token minta

Magas biztonsági igényű környezetben a kliensoldali tokenlopás ellen az véd a leghatékonyabban, ha a JWT el sem jut a frontendig. A nagyvállalati architektúrák ezt gyakran a „phantom token” mintával oldják meg:

1. Az authorizációs szerver JWT helyett véletlenszerű, önmagában semmit el nem áruló azonosítót ad a kliensnek.
2. A kliens ezt az azonosítót küldi minden API-híváskor.
3. Az API-átjáró elfogja a kérést, az azonosítót az authorizációs szervernél (vagy a munkamenettárban) ellenőrzi, és teljes értékű, aláírt JWT-re cseréli.
4. Az átjáró a valódi JWT-t továbbítja a belső mikroszolgáltatásoknak.

Gyakori kérdések a JWT-biztonságról

Miben segít a Haxoris?

A tokenek biztonságát ritkán a kriptográfia töri meg – szinte mindig a konfiguráció. Ezeket a réseket még a támadó előtt megtaláljuk:

• Webalkalmazásokat és API-kat tesztelünk, külön figyelemmel a hitelesítésre és a jogosultságkezelésre.
• Átnézzük, hogyan állítja ki és ellenőrzi az alkalmazás a tokeneket, és hogyan kezeli a kulcsokat – a JWKS-t és a kulcscserét is beleértve.
• Offline megnézzük, mennyire erős a szimmetrikus aláíró kulcs.
• Átvilágítjuk a tervet: hol tárolja a tokent, meddig él a munkamenet, hogyan épül fel a refresh token körüli logika.

Összegzés

A JWT nem eleve rossz megoldás. Attól lesz azzá, hogy az alkalmazás a tokenre bízza, hogyan kell ellenőrizni – vagy hogy az érvényes aláírást jogosultságnak veszi. Rögzített algoritmus, minden claim ellenőrzése, root jelszóként kezelt titok és a böngésző tárolóin kívül tartott token: ezzel a négy szabállyal a cikkben felsorolt megállapítások többsége eltűnik a következő vizsgálati jelentésből.

Források és ajánlott olvasmányok

A cikk módszertani és technikai részletei az alábbi forrásokra épülnek:

1. PortSwigger Web Security Academy. JWT Security Vulnerabilities. Részletes leírás az aláírás-ellenőrzés hibáiról és a fejlécinjekciókról. portswigger.net/web-security/jwt
2. InfoSec Writeups. JWT Pentesting: A Journey from Token to Takeover. Gyakorlati esetek a tokenek rossz beállításainak kihasználásáról. infosecwriteups.com
3. Auth0 / JWT.io. Introduction to JSON Web Tokens. A szabvány alapdokumentációja: a tokenek felépítése és az RFC 7519. jwt.io/introduction
4. JWTAuditor. Security Testing Tool. Eszköz a payload módosításához és az automatikus ellenőrzésekhez. jwtauditor.com

Kapcsolódó Haxoris-szolgáltatások: webalkalmazások és API-k penetrációs tesztelése