A JWT elleni sikeres támadás ritkán igényli egy modern aláírás feltörését. Elég, ha az alkalmazás csak dekódolja a claims-et, rossz kulcsot fogad el, nem ellenőrzi az audience-t, vagy hosszú életű bearer tokent naplóz. A kis formátum körül teljes autentikációs rendszer épül. Kulcsok, lejárat, revokáció, böngészős tárolás és authorization ugyanannyira számít, mint az algoritmus.

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

A header és payload kulcs nélkül olvasható. Támadó tetszőleges user ID-t vagy admin szerepet írhat saját tokenbe. Minden claim megbízhatatlan, amíg a signature és a kötelező szabályok nem érvényesek.

Az authorization csak teljes validáció után induljon. Részben ellenőrzött objektum ne jusson tovább más réteghez.

A token nem választhat biztonsági policyt

A header algoritmust nevez, a verifier azonban saját allowlisttel hasonlítja össze. Történelmi hibák unsigned token vagy szimmetrikus-aszimmetrikus keverés elfogadásából származtak.

A kid megbízhatatlan input. Nem lehet tetszőleges fájlútvonal, SQL-részlet vagy URL, csak megbízható kulcskészlet indexe.

Issuer és audience ugyanolyan fontos, mint a signature

Egy ismert szervezet helyesen aláírt tokenje lehet másik alkalmazásnak szánt credential. Audience check nélkül rossz kontextusban használható.

Multi-tenant rendszernél a tenant claimnek egyeznie kell a route-tal, fiókkal és objektummal. Az aláírt állítás nem ad automatikusan jogot minden tenant adatához.

Az időclaims kis, dokumentált toleranciát kapjon

Az exp és nbf megbízható órához viszonyítandó. Kis clock skew elfogadható, nagy tolerancia meghosszabbítja a lopott token életét.

A teszt ellenőrizze a pontos lejárati határt, jövőbeli tokent és hibás órát. Időszinkronizációs probléma miatt nem szabad korlátlanul figyelmen kívül hagyni a hibát.

A hosszú access lifetime lassítja a revokációt

Jelszócsere, alkalmazott távozása vagy szerepkör eltávolítása után a self-contained token tovább működhet. Központi denylist visszaadja a kontrollt, de shared state-et vezet be.

Rövid access token és rotált refresh token gyakori megoldás. Gyanús eseménynél a refresh family és szükség szerint az aktív sessionök visszavonhatók.

A payload legyen minimális

Aláírt JWT-ben sem titkos a jelszó, privát kulcs vagy bizalmas profil. Még egy e-mail és szerepkörlista is sok kliensbe és diagnosztikai rendszerbe kerülhet.

A szükséges stabil claims csökkenti a privacy kockázatot és a fejlécméretet. Változó részletet autoritatív szolgáltatásból kell lekérni.

A böngészős tárolásnak nincs univerzális receptje

JavaScriptből elérhető token XSS esetén ellopható. HttpOnly cookie korlátozza az olvasást, de CSRF és SameSite kezelés kell. A JWT cookie-ban továbbra is cookie credential.

A domének, kliensarchitektúra és threat model dönt. Egyik tároló sem javít ki veszélyes DOM sinkeket vagy kontrollálatlan third-party scriptet.

Az aláírt szerepkör nem objektumjogosultság

Az editor claim nem jelent jogot minden dokumentumhoz. Az alkalmazás tulajdonost, tenantot, objektumállapotot és műveletet ellenőriz aktuális doménadat alapján.

A JWT validáció identitáskörnyezetet ad. A végső döntést külön policy réteg és külön teszt kezeli.

A kulcsrotációt incidens előtt kell megtervezni

A privát kulcs szivároghat és rendszeresen cserélendő. A szolgáltatások cache-elt publikus kulcsokat, átfedést és gyors kompromittált-kulcs kivonást igényelnek.

A gyakorlat feltárja a hardcoded kulcsot, stale cache-t és azt a monitoringot, amely nem különbözteti meg az ismeretlen key ID-t a hibás signature-től.

A kompromittált aláírókulcs minden tokent érint

Privát kulcs birtokában a támadó tetszőleges claims-szel adhat ki tokent. Nem elég a régi tokenek lejáratára várni. A kulcsot minden verifierben ki kell vonni.

Az incident plan meghatározza a refresh tokenek, sessionök és felhasználói értesítés kezelését. A hosszú cache TTL meghosszabbíthatja a támadást.

A replay külön probléma

Érvényes aláírás nem akadályozza meg ugyanazon request ismétlését. Egyszeri pénzügyi vagy admin művelet idempotency keyt, nonce-ot vagy szerveroldali használati rekordot igényel.

A rövid időablak csökkenti, de nem szünteti meg a kockázatot. A business műveletnek retry esetén is biztonságosnak kell maradnia.

A teszt elsősorban elutasításokat bizonyít

Módosított payload, wrong audience, idegen issuer, expired token, tiltott algoritmus, ismeretlen key és malformed szegmens mind külön teszteset. Egy sikeres login nem elegendő.

A produkciós metrika különböztesse meg a normál expirációt az invalid signature hirtelen növekedésétől. A log credential helyett biztonságos kontextust tároljon.

A szigorúság tervezett tulajdonság

A biztonságos verifier pontosan tudja, ki adhat ki tokent, milyen kulccsal, hol használható és meddig érvényes. Minden más elutasítandó, még akkor is, ha könnyen dekódolható.

A központi könyvtár segít, de minden szolgáltatásnak bizonyítania kell az aktuális konfigurációt. A régi engedékeny út nem maradhat állandó kompatibilitási kerülőként.

A konfigurációs audit minden verifierre kiterjed

Az engedélyezett algoritmus, issuer, audience, clock skew és kulcsforrás legyen verziózott központi policy. A belső admin API, websocket gateway és háttérworker ugyanazt a biztonsági profilt kapja, mint a fő HTTP szolgáltatás.

Az audit felderíti a hardcoded secretet, túl nagy időtoleranciát és azokat a deployokat, amelyek nem frissítik a JWKS cache-t. Minden kivételhez tulajdonos, indok és lejárati dátum tartozik.

Az error handling ne segítsen a támadónak

A kliensnek rendszerint elég a 401 vagy 403 és egy stabil gépi hibakód. Nem szükséges megmondani, pontosan melyik aláírási lépés bukott el vagy milyen key ID hiányzik. A részletes ok biztonságos belső telemetrybe kerül.

A monitoring külön méri az expired, wrong audience, unknown issuer és invalid signature eseményeket. Hirtelen változás hibás rolloutot, stale cache-t vagy támadást jelezhet, miközben a bearer érték soha nem kerül a metrikába.

A válasz következetessége azért is fontos, mert a különböző hibaidő vagy szöveg mellékcsatornán keresztül felfedheti, mely tokenrészt fogadta el a rendszer.