JWT saugumas: pažeidžiamumai, atakos ir geroji praktika

JSON Web Token (JWT) šiuolaikinėse web aplikacijose tapo pagrindiniu būdu autentifikuoti naudotoją nesaugant sesijos serveryje. Būtent lankstumas, dėl kurio jis išpopuliarėjo, veda ir prie lemtingų konfigūracijos klaidų. Įsilaužimų teste JWT nėra tiesiog sesijos identifikatorius – tai kriptografinis atakos paviršius.

JWT sandara: antraštė, payload ir parašas

JWT sudaro trys dalys: antraštė, payload ir parašas. Jas skiria taškas (.). Tarpiniame serveryje perimtas JWT iš pradžių atrodo kaip ilga, tarsi atsitiktinių ženklų eilutė. Štai pavyzdys iš realios aplinkos:

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

Antraštė ir payload – tai tiesiog Base64Url formatu užkoduoti JSON objektai. Jie tik užkoduoti, o ne užšifruoti: viską, kas ten įrašyta, iškoduoja ir perskaito bet kas, kurio rankose atsiduria tokenas.

JWT struktūra viename paveiksle

Pasirašytas JWT, tiksliau vadinamas JWS, sudarytas iš trijų taškais atskirtų dalių: Header.Payload.Signature.

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

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

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

Antraštė

Antraštėje surašyti metaduomenys apie patį tokeną: jo tipas ir kriptografinis algoritmas, kuriuo tokenas pasirašytas. Pirmoji aukščiau pateikto tokeno dalis iškoduota atrodo taip:

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

Payload

Payload dalyje surašyti teiginiai (angl. claims) apie naudotoją. Saugumo patikros metu tai pirmasis manipuliacijos taikinys. Iškoduota vidurinė pavyzdžio dalis:

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

Parašas

Antraštę ir payload gali perskaityti ir perrašyti bet kas, todėl viso JWT pagrindu veikiančio mechanizmo saugumas remiasi kriptografiniu parašu.

Tokeną išduodantis serveris savo slaptu pasirašymo raktu apskaičiuoja Base64Url formatu užkoduotos antraštės ir payload maišos reikšmę. Šis mechanizmas garantuoja du dalykus:

1. Parašas tiesiogiai išvedamas iš likusios tokeno dalies, todėl užtenka pakeisti vieną antraštės ar payload baitą, kad parašas nebesutaptų.
2. Neturint serverio slapto pasirašymo rakto, suklastotai antraštei ar payload teisingo parašo sugeneruoti neįmanoma.

Ko JWT tokene ieško užpuolikas

JWT perskaitomas jau pagal pačią sandarą, todėl užpuolikas jį vertina ne kaip užšifruotų duomenų paketą, o kaip vertingą žvalgybos medžiagą. Logikos klaidos paprastai glūdi būtent payload dalyje. Šiuos teiginius peržiūrime pirmiausia:

Žvalgyba iš payload: ką tokenas išduoda pats

Payload mato kiekvienas, kurio rankose atsiduria tokenas, todėl programuotojui jį verta laikyti vieša informacija. Patikrų metu pasirinktiniuose teiginiuose reguliariai randama vidinių detalių, kurioms ten ne vieta:

• Vidinio tinklo žemėlapis: tokie teiginiai kaip "node_ip": "10.0.4.12", "cluster": "prod-us-east-1a" ar "db_host": "internal-db.local" atskleidžia vidinę architektūrą ir naudojamus adresų diapazonus.
• Karkaso ir tapatybės valdymo pėdsakai: teiginių pavadinimai išduoda technologijų rinkinį. Pavyzdžiui, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name vienareikšmiškai nurodo Microsoft .NET arba Entra ID serverio pusę, ir tada ieškoma būtent šiai aplinkai būdingų pažeidžiamumų.
• Asmens duomenys: be reikalo atskleistas el. pašto adresas, telefono numeris, visas vardas ar gyvenamosios vietos adresas. Tokene jie iškart tampa ir BDAR klausimu.
• Klientų ir rolių apskaita: "tenant_id": "uuid", "is_god_mode": false ar "permissions": ["read:profile"] išpiešia teisių modelį ir paduoda gatavus parametrų pavadinimus teisėms eskaluoti.

Per daug atviras JWT payload, su kokiu susiduriama praktikoje:

{
  "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
}

Bearer ir refresh tokenai: architektūra ir saugojimas

Saugus JWT sprendimas remiasi dviejų tokenų schema: trumpaamžiu prieigos tokenu (bearer token) ir ilgaamžiu atnaujinimo tokenu (refresh token). Neteisingas jų saugojimas – dažniausias radinys, apie kurį šioje srityje pranešame.

Bearer tokenai (prieigos tokenai)

• Prieigos tokenas autorizuoja API užklausas ir yra sąmoningai trumpaamžis: paprastai nuo 5 iki 15 minučių.
• Jo vieta – tik aplikacijos atmintyje. localStorage ir sessionStorage atkrenta: pakanka vienos sėkmingos XSS spragos, kad tokenas atsidurtų pas užpuoliką.

Refresh tokenai

• Vienintelė atnaujinimo tokeno užduotis – pasibaigus galiojimui gauti naują prieigos tokeną.
• Jo vieta – HttpOnly, Secure, SameSite slapukas: JavaScript jo neperskaito, tokeno vagystė per XSS tampa gerokai sunkesnė, o kartu mažėja ir CSRF rizika.

Dažniausios JWT atakos įsilaužimų teste

Tikrinant web aplikaciją paprastai pereinama per šias atakų kryptis.

A. Parašo tikrinimo klaidos

Didžioji dalis JWT pažeidžiamumų kyla ne iš sulaužytos kriptografijos, o iš paviršutiniško parašo tikrinimo. Istoriškai kai kurios bibliotekos priimdavo none algoritmą: parašą buvo galima tiesiog nuimti ir tuo pačiu metu laisvai perrašyti teiginius, pavyzdžiui, naudotojo rolę. Šiuolaikinės bibliotekos none pagal numatytuosius nustatymus atmeta, tačiau paveldėtose aplikacijose ir pačių parašytame JWT apdorojime ši klaida vis dar pasitaiko. Susidūrus su nestandartiniu technologijų rinkiniu, tai verta patikrinti visada.

Antroji klasika – algorithm confusion, arba algoritmų supainiojimas. Tai vienas sunkiausių JWT pažeidžiamumų, todėl jį verta atsekti žingsnis po žingsnio.

• RS256 – asimetrinis algoritmas. Serveris parašą sukuria savo privačiuoju raktu, o tikrina atitinkamu viešuoju raktu. Viešasis raktas dažnai laisvai prieinamas, pavyzdžiui, /.well-known/jwks.json galiniame taške.
• HS256 – simetrinis algoritmas. Serveris ir pasirašymui, ir tikrinimui naudoja tą patį bendrą raktą.

Ataka pasinaudoja tuo, kas nutinka, kai serveris priima abu algoritmus ir niekur nėra fiksuota, kurio iš jų jis laukia:

1. Užpuolikas gauna serverio viešąjį raktą – dažnai visai paprastai, tiesiai iš JWKS galinio taško.
2. Jis perrašo payload, pavyzdžiui, vietoj "role": "user" įrašo "role": "admin".
3. Antraštėje vietoj "alg": "RS256" jis įrašo "alg": "HS256".
4. Visą pakeistą tokeną (antraštę ir payload) jis pasirašo iš naujo, viešąjį raktą naudodamas kaip HS256 raktą.
5. Serveris gauna tokeną, mato alg: HS256 ir parašą tikrina viešąjį raktą naudodamas kaip HMAC raktą. Parašas sutampa, ir suklastotą tokeną serveris priima.

Priežastis – ne sulaužyta kriptografija, o tai, kad serveris aklai patiki kliento atsiųstai alg antraštei nuspręsti, kaip tokenas turi būti tikrinamas. Įprastai alg pakeitimas parašą padarytų negaliojantį, nes parašas apima ir antraštę, ir payload. Tačiau užpuolikas iš naujo pasirašo visą pakeistą tokeną, todėl pakeistą algoritmą atitinkantis parašas galioja nepriekaištingai.

Šiuolaikinės bibliotekos šias klaidas didžiąja dalimi pašalino, tačiau paveldėtose aplikacijose ir pačių parašytame JWT apdorojime jos pasitaiko iki šiol.

B. Silpni pasirašymo raktai

Jei aplikacija pasirašo simetriniu algoritmu (HS256), ji yra lygiai tiek saugi, kiek saugus pasirašymui naudojamas raktas.

Įsilaužimų teste perimtą JWT galima atakuoti visiškai neprisijungus – tokiais įrankiais kaip Hashcat ar John the Ripper. Įmonės pavadinimas, žodyno žodis ar nuspėjama frazė paprastai krinta per kelias minutes, o po to užpuolikas išduoda galiojančius tokenus bet kurio naudotojo vardu, daugiau nebeliesdamas testuojamos aplikacijos.

C. Injekcija per antraštės parametrus

JWT antraštėje gali būti neprivalomų parametrų, pavyzdžiui, kid (Key ID) ir jku (JWK Set URL), kurie serveriui nurodo, kuriuo raktu tikrinti parašą. Šias reikšmes siunčia klientas, todėl pasitikėjimas jomis be patikros atveria rimtą spragą.

Dažniausios atakų kryptys:

• jku parametro perrašymas į paties užpuoliko valdomą JWKS galinį tašką;
• katalogų perėjimas (directory traversal) per kid parametrą, jei raktai įkeliami tiesiai iš failų sistemos;
• SQL injekcija ten, kur kid reikšmė sujungiama į duomenų bazės užklausą.

Subrendusios JWT bibliotekos šiuos atvejus apdoroja saugiai, tačiau pačių parašyta tikrinimo logika ataskaitose radinių duoda iki šiol.

D. Nepatikrinti teiginiai

Galiojantis parašas savaime nereiškia, kad tokenu galima pasitikėti. Aplikacija privalo patikrinti ir kiekvieną saugumui svarbų teiginį.

Testuose reguliariai pasitaiko API, kurios:

• ignoruoja exp teiginį ir priima pasibaigusio galiojimo tokenus;
• netikrina numatyto gavėjo (aud), todėl tas pats tokenas tinka ir kitoje paslaugoje;
• priima bet kokį išdavėją (iss);
• pasikliauja vien kliento valdomais teiginiais, tokiais kaip role, tenant ar permissions, o serverio pusėje teisių netikrina apskritai.

Praktikoje tokios logikos klaidos užpuolikui neretai duoda daugiau nei kriptografinės silpnybės: visiškai teisėtas tokenas panaudojamas tam, ko niekas nebuvo numatęs.

Įrankiai JWT saugumo testavimui

Base64 iškoduoti ir parašą perdirbti rankomis – lėta. Atakoms automatizuoti naudojami specializuoti įrankiai:

• JWTAuditor: kliento pusėje veikianti platforma, sukurta būtent saugumo testuotojams. Leidžia greitai peržiūrėti tokenus, automatiškai ieškoti pažeidžiamumų (pavyzdžiui, none algoritmo ar antraštės injekcijos) ir laužti raktus neprisijungus, nerizikuojant, kad jautrūs kliento tokenai pateks į svetimą telemetriją.
• Burp Suite (JWT Editor plėtinys): dinaminio testavimo darbo įrankis. Perimant HTTP srautą tarpiniame serveryje, tokenas keičiamas čia pat.
• JWT.io: Auth0 prižiūrimas standartinis įrankis greitam rankiniam iškodavimui, taip pat tokeno struktūrai ir parašui patikrinti žvalgybos pradžioje.
• JWTLens: lengva, privatumui pirmenybę teikianti alternatyva tokenams peržiūrėti. Iškoduoja ir tikrina tokenus visiškai naršyklėje, su integruota Web Crypto API, todėl raktai ir tokenai kompiuterio nepalieka. Tikrinimo metu įrankis nesiunčia nė vienos tinklo užklausos, todėl algoritmus ir parašą patvirtinti galima saugiai.

Praktinė apsauga

Kad aplikacija nepatektų į ataskaitos kritinių radinių sąrašą, kūrimo komandai verta įdiegti penkias pagrindines taisykles:

• Fiksuokite laukiamą algoritmą. Įeinantis tokenas niekada neturi spręsti, kaip jį tikrinti. Tikrinimo logikoje nustatykite vieną konkretų algoritmą (pavyzdžiui, RS256), o none atmeskite be išimčių.
• Tikrinkite visus teiginius. Galiojantis parašas įrodo tik tai, kad tokeno niekas nelietė, o ne tai, kad šiam naudotojui jis dabar galioja. Kiekvienos užklausos metu tikrinkite exp (galiojimo pabaiga), iss (išdavėjas) ir aud (numatytas gavėjas).
• Su simetriniu raktu elkitės kaip su slaptažodžiu. Jei architektūra reikalauja simetrinio pasirašymo (HS256), raktui reikia bent 256 bitų entropijos iš kriptografiškai saugaus generatoriaus, o laikyti jį dera aplinkos kintamajame arba paslapčių valdyklėje, o ne pirminiame kode.
• Kodavimas nėra šifravimas. Payload dalyje nėra vietos nei jautriems duomenims, nei asmens duomenims, nei slaptažodžiams. Kas tokeną perima, tas Base64 iškoduoja jį akimirksniu.
• Atskirkite tokenų saugojimą. Trumpaamžis prieigos tokenas neturi patekti į localStorage ar sessionStorage saugyklą, iš kurios jį ištraukia viena XSS spraga. Prieigos tokenas lieka naršyklės atmintyje, o ilgaamžis atnaujinimo tokenas priklauso Secure, HttpOnly, SameSite slapukui.

Papildomas sustiprinimas: phantom token modelis

Aukštų saugumo reikalavimų aplinkoje nuo vagystės kliento pusėje veiksmingiausiai apsaugo tai, kad JWT apskritai nepasiekia naršyklės. Didelių organizacijų architektūroje tai dažnai sprendžiama „phantom token“ modeliu:

1. Autorizacijos serveris kliento aplikacijai vietoj JWT išduoda atsitiktinę, nieko neatskleidžiančią sesijos eilutę.
2. Kiekvienoje API užklausoje klientas siunčia būtent šią eilutę.
3. API šliuzas (angl. API gateway) užklausą perima, eilutę patikrina autorizacijos serveryje arba sesijų saugykloje ir iškeičia į pilnavertį, pasirašytą JWT.
4. Tikrąjį JWT šliuzas persiunčia vidinėms mikropaslaugoms.

Ką apie tai sako Lietuvos reguliavimas

Lietuvos kibernetinio saugumo teisės aktai tokenų atskirai nemini, tačiau saugumo reikalavimai taikomi visai informacinei sistemai, o autentifikacija yra viena jos dalių.

Pagrindinis teisės aktas – Kibernetinio saugumo įstatymas (toliau – KSĮ). NIS2 direktyva perkelta ne atskiru įstatymu, o šį įstatymą išdėstant nauja redakcija – įstatymu Nr. XIV-2902, kuris įsigaliojo 2024 m. spalio 18 d. Konkretūs reikalavimai surašyti Kibernetinio saugumo reikalavimų apraše, patvirtintame Vyriausybės nutarimu Nr. 945. Kibernetinio saugumo subjektams jame nustatytos trys reguliariai pasikartojančios pareigos: visos informacinės sistemos pažeidžiamumų skenavimas ne rečiau kaip kas 6 mėnesius (45.8 papunktis), kasmetinis atitikties vertinimas, kurį subjektas atlieka pats sau (48.1 papunktis), ir kibernetinio saugumo auditas ne rečiau kaip kas 3 metus (48.3 papunktis bei KSĮ 14 str. 8 d.).

Nė viena iš šių trijų pareigų nėra įsilaužimų testas. Įsilaužimų testavimo Lietuvos teisė nereikalauja, o testuotojų licencijų ar registro nėra – licencijavimas įstatyme apskritai neminimas. JWT autentifikacijai iš to plaukia labai praktiška išvada: reguliarus spragų skenavimas parodys pasenusią biblioteką, bet nepasakys, ar serveris priima alg: none ir ar aud iš tikrųjų tikrinamas. Tai randama tik rankiniu testavimu, kuris užsakomas savo iniciatyva. Kur eina ši riba, plačiau aptarta straipsnyje ar įsilaužimų testavimas privalomas, o pasirengimas trejų metų auditui – straipsnyje apie kibernetinio saugumo auditą.

Terminai skaičiuojami kiekvienam subjektui atskirai. Aprašo 71 ir 72 punktai nustato pereinamuosius terminus: organizaciniams reikalavimams – 12 mėnesių, išvardytiems techniniams – 24 mėnesiai. Abu skaičiuojami nuo to paties subjekto registracijos Kibernetinio saugumo informacinėje sistemoje (KSIS) datos, todėl visai rinkai bendros kalendorinės datos nėra.

Antras sluoksnis – asmens duomenų apsauga. BDAR 32 straipsnio 1 dalies d punktas reikalauja reguliariai testuoti, vertinti ir tikrinti techninių ir organizacinių priemonių veiksmingumą, tačiau nenurodo, kokia konkrečiai patikra turi būti atlikta. Jei payload dalyje laikomi asmens duomenys, o tokenas iš localStorage nuteka į svetimą domeną, kalbama nebe apie techninę klaidą, o apie asmens duomenų saugumo pažeidimą su atitinkama pareiga pranešti Valstybinei duomenų apsaugos inspekcijai.

Vieną dalyką verta pasakyti iškart. Haxoris – Slovakijos įmonė, o mūsų sritis – techninis saugumo testavimas ir pasirengimo vertinimas. KSĮ 14 str. 8 d. numatyto kibernetinio saugumo audito neatliekame, išvados dėl įstatymo reikalavimų vykdymo neteikiame ir sertifikatų neišduodame. Dirbame pagal rašytinį užsakovo leidimą ir sutartą apimtį, o rezultatas – ataskaita, kurią auditorius gali patikrinti.

JWT saugumas – dažniausiai užduodami klausimai

Kaip gali padėti Haxoris

Tokenų saugumą retai sulaužo kriptografija – beveik visada jį sulaužo konfigūracija. Šias spragas randame anksčiau nei užpuolikas:

• Web aplikacijų ir API įsilaužimų testavimas, ypatingą dėmesį skiriant autentifikacijos ir teisių suteikimo srautams.
• JWT išdavimo ir tikrinimo logikos bei raktų valdymo peržiūra, įskaitant JWKS apdorojimą ir raktų keitimą.
• Simetrinių pasirašymo raktų atsparumo vertinimas neprisijungus.
• Tokenų saugojimo, sesijų trukmės ir atnaujinimo tokenų architektūros peržiūra.

Apibendrinimas

JWT pagal sandarą nėra nesaugus. Nesaugus jis tampa tą akimirką, kai aplikacija leidžia pačiam tokenui nuspręsti, kaip jis turi būti tikrinamas, arba kai galiojantis parašas laikomas teisių patikros pakaitalu. Fiksuotas algoritmas, kiekvieno teiginio patikra, kaip slaptažodis saugomas raktas, payload be jautrių duomenų ir iš naršyklės saugyklų išimti tokenai – su šiomis penkiomis taisyklėmis didžioji dalis straipsnyje surašytų radinių iš kitos ataskaitos dingsta.

Haxoris šioje srityje dirba techninėje pusėje. Atliekame web aplikacijų ir API įsilaužimų testavimą pagal OWASP WSTG gaires, o aplikacijų saugumo reikalavimus tikriname pagal OWASP ASVS. Jei JWT autentifikacija jau veikia gamybinėje aplinkoje arba artėja jos paleidimas, užsisakykite nemokamą konsultaciją – apimtį suderinsime kartu su jūsų komanda.

Šaltiniai ir rekomenduojama literatūra

Straipsnio metodika ir techninės detalės remiasi šiais viešai prieinamais saugumo šaltiniais:

1. PortSwigger Web Security Academy. JWT Security Vulnerabilities. Išsamus parašo tikrinimo klaidų ir antraštės injekcijų aprašymas. portswigger.net/web-security/jwt
2. InfoSec Writeups. JWT Pentesting: A Journey from Token to Takeover. Praktiniai tokenų konfigūracijos išnaudojimo atvejai. infosecwriteups.com
3. Auth0 / JWT.io. Introduction to JSON Web Tokens. Standarto pagrindinė dokumentacija apie tokenų sandarą ir RFC 7519. jwt.io/introduction
4. JWTAuditor. Security Testing Tool. Įrankis payload perdirbimui ir automatizuotai pažeidžiamumų paieškai. jwtauditor.com

Susijusios Haxoris paslaugos: web aplikacijų ir API įsilaužimų testavimas