JWT lähemalt: tokenite turvalisus, haavatavused ja parimad praktikad

JSON Web Token’id (JWT-d) on olekuvaba autentimise de facto standard tänapäevastes veebirakendustes. Just see paindlikkus viib aga ikka ja jälle tõsiste väärseadistusteni. Kui meie penetratsioonitestijana JWT-d näeme, ei näe me lihtsalt sessiooni identifikaatorit – me näeme krüptograafilist ründepinda.

JWT anatoomia: päis, payload ja allkiri

JWT koosneb kolmest osast: päisest, payloadist ehk tokeni sisust ja allkirjast, mis on üksteisest eraldatud punktiga (.). Penetratsioonitestija jaoks näeb kinni püütud JWT esmapilgul välja nagu pikk näiliselt juhuslike märkide jada. Siin on üks näide päris elust:

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

Päis ja payload on lihtsalt Base64Url-kodeeritud JSON-objektid. Need on ainult kodeeritud, mitte krüpteeritud. Igaüks, kellel on tokenile ligipääs, saab need andmed dekodeerida ja läbi lugeda.

JWT struktuur pildis

JWT (tehniliselt JWS – JSON Web Token „allkirjastatud kujul“) koosneb kolmest punktidega eraldatud osast: Header.Payload.Signature.

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

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

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

Päis

Päis sisaldab metaandmeid tokeni enda kohta, eelkõige tokeni tüüpi ja krüptograafilist algoritmi, millega token on kaitstud. Kui ülaltoodud tokeni esimese osa dekodeerida, saad:

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

Payload

Payload sisaldab tegelikke väiteid ehk claim’e kasutaja kohta. See on turvahindamise ajal peamine manipuleerimise sihtmärk. Meie näite keskmine osa dekodeerub selliseks:

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

Allkiri

Kuna päist ja payloadi saab igaüks vaevata lugeda või muuta, sõltub iga JWT-põhise mehhanismi turvalisus otsustavalt krüptograafilisest allkirjast.

Väljastav server arvutab räsi Base64Url-kodeeritud päise ja payloadi pealt ning kasutab selleks salajast allkirjastamisvõtit. See mehhanism tagab kaks asja:

1. Kuna allkiri tuletatakse otse tokeni ülejäänud osast, muudab juba ühe baidi muutmine päises või payloadis allkirja sobimatuks.
2. Ilma serveri salajast allkirjastamisvõtit teadmata ei tohiks võltsitud päise või payloadi jaoks olla võimalik korrektset allkirja luua.

Mida ründajad JWT-st otsivad

Kuna JWT-d on juba oma olemuselt loetavad, ei käsitle ründajad neid krüpteeritud andmetena, vaid väärtusliku luureallikana. Ründaja vaatevinklist peituvad loogikavead enamasti payloadis. Need kriitilised väited vaatame esimesena üle:

Payloadi luure: kust teave välja lekib

Kuna payload on nähtav igaühele, kelle käes token on, peaksid arendajad seda käsitlema avaliku teabena. Turvahindamistel leiame regulaarselt tarbetuid sisemisi detaile, mis omaväidete kaudu välja lekivad:

• Sisevõrgu kaart: omaväited nagu "node_ip": "10.0.4.12", "cluster": "prod-us-east-1a" või "db_host": "internal-db.local" reedavad sisevõrgu arhitektuuri ja IP-vahemikud.
• Järeldused raamistiku ja identiteedipakkuja kohta: väidete nimetamistavad reedavad aluseks oleva tehnoloogiavirna. Väited nagu http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name viitavad Microsofti .NET-i või Entra ID taustsüsteemile ja lubavad meil sihipäraselt rünnata just sellele virnale omaseid haavatavusi.
• Isikuandmed: e-posti aadresside, telefoninumbrite, täisnimede või postiaadresside tarbetu avaldamine – otsene vastuolu isikuandmete kaitse üldmäärusega (GDPR).
• Klientkeskkondade ja rollide loendamine: väited nagu "tenant_id": "uuid", "is_god_mode": false või "permissions": ["read:profile"] paljastavad autoriseerimisskeemi ja annavad meile täpsed parameetrinimed õiguste laiendamiseks.

Näide liiga jutukast JWT payloadist päris elust:

{
  "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-tokenid ja refresh-tokenid: arhitektuur ja hoiustamine

Turvaline JWT-lahendus tugineb kahe tokeni süsteemile: lühikese elueaga access-tokenid (bearer-tokenid) ja pika elueaga refresh-tokenid. Nende vale hoiustamine on kaugelt kõige sagedasem haavatavus, millest me aru anname.

Bearer-tokenid (access-tokenid)

• Access-tokenid autoriseerivad API-päringuid ja on teadlikult lühikese elueaga – tavaliselt 5 kuni 15 minutit.
• Hoia neid ainult rakenduse muutmälus. Loobu localStorage’ist ja sessionStorage’ist, sest iga õnnestunud XSS-haavatavus annab need ründajale kätte.

Refresh-tokenid

• Refresh-tokenite ainus ülesanne on hankida pärast aegumist uusi access-tokeneid.
• Nende koht on HttpOnly-, Secure- ja SameSite-küpsistes. See takistab JavaScripti ligipääsu, vähendab tuntavalt tokenivargust XSS-i kaudu ja aitab ühtlasi CSRF-i leevendada.

Penetratsioonitestija käsiraamat: levinud JWT-rünnakud

Veebirakenduse auditil käivad penetratsioonitesti meeskonnad tavaliselt läbi järgmised ründevektorid.

A. Vead allkirja kontrollimisel

Paljud JWT haavatavused ei sünni murtud krüptograafiast, vaid lohakast allkirjakontrollist. Ajalooliselt aktsepteerisid mõned teegid none-algoritmi, nii et ründaja sai allkirja täielikult eemaldada ja samal ajal muuta väiteid nagu kasutaja roll. Kõik suuremad kaasaegsed teegid lükkavad none-i vaikimisi tagasi, kuid pärandrakendustes ja ise ehitatud JWT-lahendustes tuleb see viga endiselt ette – testida tasub alati siis, kui satud mittestandardse tehnoloogiavirna otsa.

Teine klassika on algoritmide segiajamine (algorithm confusion). See on üks kõige raskemate tagajärgedega JWT haavatavusi üldse ja seda tasub täpselt mõista.

• RS256 on asümmeetriline meetod. Server allkirjastab tokenid oma privaatvõtmega ja kontrollib neid vastava avaliku võtmega. Avalik võti on sageli vabalt kättesaadav – näiteks /.well-known/jwks.json lõpp-punkti kaudu.
• HS256 on sümmeetriline meetod. Server kasutab tokenite nii allkirjastamiseks kui ka kontrollimiseks üht ja sama jagatud saladust.

Rünnak kasutab ära seda, mis juhtub, kui server aktsepteerib mõlemat algoritmi, ilma et oodatav algoritm oleks selgesõnaliselt fikseeritud:

1. Ründaja hangib serveri avaliku võtme – sageli triviaalselt JWKS-i lõpp-punktist.
2. Ta muudab tokeni payloadi, näiteks "role": "user" väärtuseks "role": "admin".
3. Ta muudab päises "alg": "RS256" väärtuseks "alg": "HS256".
4. Ta allkirjastab kogu muudetud tokeni (päise ja payloadi) uuesti ning kasutab selleks avalikku võtit HS256 saladusena.
5. Server saab tokeni kätte, näeb alg: HS256 ja kontrollib seda avaliku võtmega kui HMAC-saladusega. Kontroll läheb läbi ja võltsitud token võetakse vastu.

Põhjus ei ole murtud krüptograafia, vaid server, mis usaldab pimesi kliendi saadetud alg-päist, kui otsustab, kuidas tokenit kontrollida. Tavaliselt muudaks alg-i muutmine päises allkirja kehtetuks, sest allkiri katab nii päise kui ka payloadi. Ründaja allkirjastab aga kogu muudetud tokeni uuesti, nii et vahetatud algoritmiga on uus allkiri täiesti kehtiv.

Kaasaegsed teegid on need vead suures osas kõrvaldanud, pärandrakendustes ja ise ehitatud JWT-lahendustes esinevad need aga endiselt.

B. Nõrgad allkirjastamisvõtmed

Rakendused, mis kasutavad sümmeetrilisi meetodeid nagu HS256, on täpselt nii turvalised, kui turvaline on saladus, millega token allkirjastatakse.

Penetratsioonitestil saab kinni püütud JWT-d rünnata täielikult võrguühenduseta, tööriistadega nagu Hashcat või John the Ripper. Nõrgad saladused – ettevõtte nimi, sõnastikusõnad või etteaimatavad fraasid – langevad sageli minutitega. Seejärel saab ründaja luua kehtivaid tokeneid ükskõik millise kasutaja nimel, ilma et peaks sihtrakendusega enam kunagi suhtlema.

C. Süstimine päiseparameetrite kaudu

JWT päised võivad sisaldada valikulisi parameetreid nagu kid (Key ID) ja jku (JWK Set URL), mis aitavad serveril leida kontrollimiseks sobiva võtme. Kuna need väärtused tulevad kliendilt, võib nende pime usaldamine ilma korraliku valideerimiseta avada tõsiseid haavatavusi.

Levinud ründevektorite hulka kuuluvad:

• jku-parameetri manipuleerimine, et suunata päring ründaja kontrollitavale JWKS-i lõpp-punktile;
• kataloogiränne (directory traversal) kid-parameetri kaudu, kui võtmeid laaditakse otse failisüsteemist;
• SQL-i süstimine, kui kid-väärtus pannakse andmebaasipäringusse kokku.

Küpsed JWT-teegid käsitlevad neid stsenaariume turvaliselt, ise kirjutatud kontrolliloogika annab aga turvahindamistel jätkuvalt leide.

D. Vead väidete valideerimisel

Kehtiv allkiri ei tähenda automaatselt, et tokenit tohib usaldada. Iga turvalisuse seisukohalt oluline väide tuleb rakenduses eraldi valideerida.

Penetratsioonitestidel kohtame regulaarselt API-sid, mis:

• võtavad vastu aegunud tokeneid, sest exp-väidet eiratakse;
• ei kontrolli ettenähtud saajat (aud), mistõttu tokeneid saab kordusesitusena kasutada teenuste üleselt;
• usaldavad suvalisi väljastaja (iss) väärtusi;
• toetuvad ainult kliendipoolt kontrollitavatele väidetele nagu role, tenant või permissions, ilma et autoriseerimist serveripoolel kontrollitaks.

Nendel loogikavigadel on praktikas sageli suurem mõju kui krüptograafilistel nõrkustel, sest need lubavad kehtivaid tokeneid kasutada viisil, milleks neid ei mõeldud.

Kaasaegsed tööriistad JWT turvatestimiseks

Base64 käsitsi dekodeerimine ja allkirjade käsitsi manipuleerimine on ebaefektiivne. Penetratsioonitestijad kasutavad nende rünnakute automatiseerimiseks spetsiaalseid tööriistu:

• JWTAuditor: suurepärane, täielikult kliendipoolne testimisplatvorm, mis on tehtud just penetratsioonitestijatele. See võimaldab tokeneid kiiresti analüüsida, haavatavusi automaatselt tuvastada (näiteks none-algoritmi testid või päisesüstimine) ja saladusi võrguühenduseta jõuga murda, ilma et kliendi tundlikud tokenid satuksid kolmandate osapoolte telemeetriasse.
• Burp Suite (laiendus JWT Editor): dünaamilises veebitestis intensiivselt kasutuses, et tokeneid HTTP-proxys kinni püüdmise hetkel otse muuta.
• JWT.io: Auth0 hallatav standardtööriist tokenite kiireks käsitsi dekodeerimiseks ning struktuuri ja allkirjade kontrollimiseks esimeses luurefaasis.
• JWTLens: kerge ja privaatsussõbralik alternatiiv tokenite analüüsiks. See dekodeerib ja verifitseerib tokeneid täielikult brauseris, kasutades natiivset Web Crypto API-t – sinu tokenid ja võtmed ei lahku seega kunagi sinu arvutist. Kuna kontrollimise ajal ei tehta ühtegi võrgupäringut, sobib tööriist ideaalselt algoritmide ja allkirjade turvaliseks valideerimiseks.

Praktilised parimad praktikad kaitseks

Selleks et sinu rakendus ei satuks penetratsioonitesti aruande kriitiliste leidude nimekirja, peaksid arendusmeeskonnad rakendama järgmised põhilised kontrollid:

• Fikseeri oodatavad algoritmid: ära lase kunagi sissetulnud tokenil endal otsustada, kuidas seda kontrollida. Seadista oma valideerimisrutiin selgesõnaliselt kindlale algoritmile (näiteks RS256) ja lükka none-algoritm eranditult tagasi.
• Valideeri väited täielikult: kehtiv allkiri tõendab ainult seda, et tokenit ei ole muudetud – mitte seda, et see on selle kasutaja jaoks praegu kehtiv. Kontrolli igal üksikul päringul selgesõnaliselt exp (aegumine), iss (väljastaja) ja aud (saaja).
• Kohtle sümmeetrilisi saladusi paroolidena: kui sinu arhitektuur nõuab sümmeetrilist allkirjastamist (HS256), on sinu salajane võti sisuliselt juurkasutaja parool. Taga vähemalt 256 bitti entroopiat, genereeri see krüptograafiliselt turvalise juhuarvugeneraatoriga ja hoia turvaliselt keskkonnamuutujates või saladuste halduris – mitte kunagi lähtekoodi sisse kirjutatuna.
• Pea meeles: kodeerimine ei ole krüpteerimine. Ära pane JWT payloadi kunagi tundlikke andmeid, isikuandmeid ega paroole. Kes tokeni kinni püüab, saab selle kohe Base64-st lahti kodeerida.
• Isoleeri tokenite hoiustamine: ära hoia lühikese elueaga access-tokeneid kunagi localStorage’is ega sessionStorage’is, kus nende väljaviimiseks piisab ainsast XSS-haavatavusest. Hoia access-tokeneid rangelt kliendi muutmälus ja pane pika elueaga refresh-tokenid turvalistesse HttpOnly- ja SameSite-küpsistesse.

Edasijõudnutele: phantom-tokeni muster

Kõrgete turvanõuetega keskkondades on kõige tõhusam kaitse kliendipoolse varguse vastu JWT-d frontendile üldse mitte avaldada. Kaasaegsed ettevõttearhitektuurid kasutavad selleks sageli phantom-tokeni mustrit, mis käib nii:

1. Autoriseerimisserver väljastab kliendirakendusele JWT asemel juhusliku läbipaistmatu sessioonistringi.
2. Kui klient saadab API-päringu, edastab ta selle läbipaistmatu stringi.
3. API-lüüs püüab päringu kinni, valideerib läbipaistmatu tokeni autentimisserveri (või sessioonihoidla) vastu ja vahetab selle täielikult täidetud allkirjastatud JWT vastu.
4. API-lüüs edastab tegeliku JWT sisemistele mikroteenustele.

Korduvad küsimused JWT turvalisuse kohta

Kuidas Haxoris saab aidata

Tokenite turvalisus ei kuku harilikult läbi krüptograafia, vaid konfiguratsiooni pärast. Haxoris aitab sul need augud leida enne, kui seda teeb ründaja:

• Veebirakenduste ja API-de penetratsioonitestid, erilise rõhuga autentimis- ja autoriseerimisvoogudel.
• JWT väljastamise ja kontrollimise loogika ning võtmehalduse ülevaatus, sealhulgas JWKS-i käsitlemine ja võtmete rotatsioon.
• Sümmeetriliste allkirjastamisvõtmete tugevuse hindamine võrguühenduseta.
• Tokenite hoiustamise, sessioonide eluea ja refresh-tokeni arhitektuuri disainiülevaatus.

Kokkuvõte

JWT-d ei ole oma olemuselt ebaturvalised. Ebaturvaliseks muutuvad nad hetkel, mil rakendus laseb tokenil endal otsustada, kuidas seda valideerida – või kui kehtivat allkirja koheldakse autoriseerimise asendajana. Fikseeri algoritm, valideeri iga väide, kohtle saladusi juurkasutaja paroolidena ja hoia tokenid brauseri salvestusruumist eemal. Siis kaob suurem osa selles artiklis kirjeldatud leidudest sinu järgmisest penetratsioonitesti aruandest.

Allikad ja edasilugemine

Selle artikli metoodika ja tehnilised üksikasjad on inspireeritud järgmistest autoriteetsetest turvaallikatest ja nende põhjal kohandatud:

1. PortSwigger Web Security Academy. JWT Security Vulnerabilities. Üksikasjalik ülevaade allkirjakontrolli vigadest ja päisesüstimisest. portswigger.net/web-security/jwt
2. InfoSec Writeups. JWT Pentesting: A Journey from Token to Takeover. Praktilised juhtumianalüüsid tokenikonfiguratsioonide ärakasutamisest. infosecwriteups.com
3. Auth0 / JWT.io. Introduction to JSON Web Tokens. Standardi alusdokumentatsioon tokenite struktuuri ja RFC 7519 kohta. jwt.io/introduction
4. JWTAuditor. Security Testing Tool. Kasutusel payloadi manipuleerimiseks ja automatiseeritud haavatavuste hindamiseks. jwtauditor.com

Seotud Haxorise teenused: veebirakenduste ja API-de läbistustestid