JWT drošība: ievainojamības, uzbrukumi un labā prakse

JSON Web Token (JWT) mūsdienu tīmekļa lietotnēs ir kļuvis par galveno veidu, kā autentificēt lietotāju, neglabājot sesiju serverī. Tieši elastība, kas to padarīja populāru, noved arī pie liktenīgām konfigurācijas kļūdām. Ielaušanās testā JWT nav vienkārši sesijas identifikators, bet kriptogrāfiska uzbrukuma virsma.

JWT uzbūve: galvene, payload un paraksts

JWT sastāv no trim daļām: galvenes, payload un paraksta. Tās atdala punkts (.). Starpniekserverī pārtverts JWT sākumā izskatās pēc garas, šķietami nejaušu rakstzīmju virknes. Lūk, piemērs no reālas vides:

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

Galvene un payload ir vienkārši Base64Url formātā kodēti JSON objekti. Tie ir tikai kodēti, nevis šifrēti: visu, kas tur ierakstīts, atkodē un izlasa ikviens, kam tokens nonāk rokās.

JWT struktūra vienā attēlā

JWT jeb, precīzāk, JWS (parakstīts JWT) sastāv no trim ar punktu atdalītām daļām: Header.Payload.Signature.

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

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

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

Galvene

Galvenē ir metadati par pašu tokenu: tā tips un kriptogrāfiskais algoritms, ar kuru tokens ir parakstīts. Augstāk redzamā tokena pirmā daļa atkodētā veidā izskatās šādi:

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

Payload

Payload daļā ir apgalvojumi jeb claims par lietotāju. Drošības pārbaudē tas ir pirmais manipulācijas mērķis. Piemēra vidējā daļa atkodētā veidā:

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

Paraksts

Galveni un payload izlasīt un pārrakstīt var ikviens, tāpēc visa uz JWT balstītā mehānisma drošība ir atkarīga no kriptogrāfiskā paraksta.

Serveris, kas izdod tokenu, ar savu slepeno parakstīšanas atslēgu aprēķina jaucējvērtību no Base64Url formātā kodētas galvenes un payload. Šis mehānisms garantē divas lietas:

1. Paraksts ir tieši atvasināts no pārējā tokena, tāpēc pietiek nomainīt vienu baitu galvenē vai payload daļā, lai paraksts vairs nesakristu.
2. Bez servera slepenās parakstīšanas atslēgas viltotai galvenei vai payload daļai pareizu parakstu izveidot nevar.

Ko uzbrucējs meklē JWT saturā

JWT jau pēc uzbūves ir lasāms, tāpēc uzbrucējs to uztver nevis kā šifrētu datu paketi, bet kā vērtīgu izlūkošanas materiālu. Loģikas kļūdas parasti mīt tieši payload daļā. Šos apgalvojumus apskatām vispirms:

Izlūkošana no payload: ko tokens izstāsta pats

Payload redz ikviens, kam tokens nonāk rokās, tāpēc izstrādātājam tas jāuztver kā publiska informācija. Pārbaudēs regulāri atrodam pielāgotos apgalvojumos iekšējas detaļas, kurām tur nav vietas:

• Iekšējā tīkla karte: tādi apgalvojumi kā "node_ip": "10.0.4.12", "cluster": "prod-us-east-1a" vai "db_host": "internal-db.local" atklāj iekšējo arhitektūru un izmantotos adrešu diapazonus.
• Ietvara un identitātes pārvaldnieka pēdas: apgalvojumu nosaukumi izstāsta tehnoloģiju kopumu. Piemēram, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name viennozīmīgi norāda uz Microsoft .NET vai Entra ID aizmugursistēmu, un tad meklējam tieši šai videi raksturīgās ievainojamības.
• Personas dati: lieki atklāta e-pasta adrese, tālruņa numurs, pilns vārds vai dzīvesvietas adrese. Tokenā tie uzreiz kļūst arī par datu aizsardzības jautājumu.
• Klientu un lomu uzskaite: "tenant_id": "uuid", "is_god_mode": false vai "permissions": ["read:profile"] izzīmē autorizācijas modeli un pasniedz gatavus parametru nosaukumus tiesību eskalācijai.

Pārāk atklāts JWT payload, ar kādu sastopamies praksē:

{
  "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 tokens un refresh tokens: arhitektūra un glabāšana

Droša JWT ieviešana balstās uz divu tokenu shēmas: īslaicīgs access tokens (bearer tokens) un ilglaicīgs refresh tokens. Nepareiza to glabāšana ir biežākais konstatējums, ko šajā jomā ziņojam.

Access tokens (bearer tokens)

• Access tokens autorizē API pieprasījumus un ir apzināti īslaicīgs: parasti no 5 līdz 15 minūtēm.
• Tā vieta ir tikai lietotnes atmiņā. localStorage un sessionStorage atkrīt: pietiek ar vienu veiksmīgu XSS ievainojamību, lai tokens nonāktu pie uzbrucēja.

Refresh tokens

• Refresh tokena vienīgais uzdevums ir pēc derīguma beigām saņemt jaunu access tokenu.
• Tā vieta ir HttpOnly, Secure, SameSite sīkdatnē: JavaScript to neizlasa, tokena zādzība caur XSS kļūst ievērojami grūtāka, un mazinās arī CSRF risks.

Biežākie JWT uzbrukumi ielaušanās testā

Tīmekļa lietotnes pārbaudē parasti izejam cauri šādiem uzbrukuma virzieniem.

A. Kļūdas paraksta pārbaudē

Lielākā daļa JWT ievainojamību rodas nevis no salauztas kriptogrāfijas, bet no paviršas paraksta pārbaudes. Vēsturiski dažas bibliotēkas pieņēma none algoritmu: parakstu varēja vienkārši noņemt un tikmēr brīvi pārrakstīt apgalvojumus, piemēram, lietotāja lomu. Mūsdienu bibliotēkas none pēc noklusējuma noraida, tomēr mantotās lietotnēs un pašu rakstītā JWT apstrādē šī kļūda parādās joprojām. Ja priekšā ir nestandarta tehnoloģiju kopums, to ir vērts pārbaudīt vienmēr.

Otrā klasika ir algorithm confusion jeb algoritmu sajaukšana. Šī ir viena no smagākajām JWT ievainojamībām, tāpēc to ir vērts izsekot soli pa solim.

• RS256 ir asimetrisks algoritms. Serveris parakstu izveido ar savu privāto atslēgu un pārbauda ar atbilstošo publisko atslēgu. Publiskā atslēga bieži ir brīvi pieejama, piemēram, /.well-known/jwks.json galapunktā.
• HS256 ir simetrisks algoritms. Serveris gan parakstīšanai, gan pārbaudei izmanto vienu un to pašu koplietoto atslēgu.

Uzbrukums izmanto to, kas notiek, ja serveris pieņem abus algoritmus un nekur nav fiksēts, kuru no tiem tas gaida:

1. Uzbrucējs iegūst servera publisko atslēgu, bieži pavisam vienkārši, tieši no JWKS galapunkta.
2. Viņš pārraksta payload, piemēram, "role": "user" vietā ieliek "role": "admin".
3. Galvenē "alg": "RS256" vietā viņš ieraksta "alg": "HS256".
4. Visu pārveidoto tokenu (galveni un payload) viņš paraksta no jauna, izmantojot publisko atslēgu kā HS256 atslēgu.
5. Serveris saņem tokenu, redz alg: HS256 un parakstu pārbauda, publisko atslēgu izmantojot kā HMAC atslēgu. Paraksts sakrīt, un viltoto tokenu serveris pieņem.

Cēlonis nav salauzta kriptogrāfija, bet gan tas, ka serveris akli uztic klienta sūtītajai alg galvenei izlemt, kā tokens jāpārbauda. Parastā gadījumā alg maiņa parakstu padarītu nederīgu, jo paraksts aptver gan galveni, gan payload. Taču uzbrucējs no jauna paraksta visu pārveidoto tokenu, tāpēc nomainītajam algoritmam atbilstošais paraksts ir nevainojami derīgs.

Praksē to atrodam tur, kur paraksta pārbaudei ir atļauts vairāk nekā viens algoritms.

B. Vājas parakstīšanas atslēgas

Ja lietotne paraksta ar simetrisku algoritmu (HS256), tā ir tieši tik droša, cik droša ir parakstīšanai izmantotā atslēga.

Ielaušanās testā pārtvertam JWT var uzbrukt pilnībā bezsaistē, ar tādiem rīkiem kā Hashcat vai John the Ripper. Uzņēmuma nosaukums, vārdnīcas vārds vai paredzama frāze parasti krīt dažās minūtēs, un pēc tam uzbrucējs izdod derīgus tokenus jebkura lietotāja vārdā, mērķa lietotnei vairs nepieskaroties.

C. Injekcija caur galvenes parametriem

JWT galvenē var būt neobligāti parametri, piemēram, kid (Key ID) un jku (JWK Set URL), kas serverim norāda, ar kuru atslēgu parakstu pārbaudīt. Šīs vērtības sūta klients, tāpēc uzticēšanās tām bez pārbaudes atver nopietnu spraugu.

Biežākie uzbrukuma virzieni:

• jku parametra pārrakstīšana uz uzbrucēja paša JWKS galapunktu;
• ceļa šķērsošana (directory traversal) caur kid parametru, ja atslēgas ielādē tieši no failu sistēmas;
• SQL injekcija tur, kur kid vērtību ar konkatenāciju iepin datubāzes vaicājumā.

Nobriedušas JWT bibliotēkas šos gadījumus apstrādā droši, taču pašu rakstīta pārbaudes loģika konstatējumus ziņojumos dod joprojām.

D. Nepārbaudīti apgalvojumi

Derīgs paraksts pats par sevi nenozīmē, ka tokenam var uzticēties. Lietotnei jāpārbauda arī katrs drošības ziņā nozīmīgais apgalvojums.

Testos regulāri sastopam API, kas:

• ignorē exp apgalvojumu un pieņem tokenus ar beigušos derīguma termiņu;
• nepārbauda paredzēto saņēmēju (aud), tāpēc vienu un to pašu tokenu var izmantot citā pakalpojumā;
• pieņem jebkuru izdevēju (iss);
• paļaujas tikai uz klienta kontrolētiem apgalvojumiem, piemēram, role, tenant vai permissions, un servera pusē tiesības nepārbauda vispār.

Praksē šādas loģikas kļūdas uzbrucējam bieži dod vairāk nekā kriptogrāfiskas vājības: pilnīgi likumīgu tokenu var izmantot tam, ko neviens nebija paredzējis. Radniecīgas kategorijas tehniskais apraksts apkopots vikilapās Insecure Direct Object Reference un Authorization Bypass.

Rīki JWT drošības testēšanai

Base64 atkodēt un parakstu pārveidot ar roku ir lēni. Uzbrukumu automatizēšanai izmantojam specializētus rīkus:

• JWTAuditor: klienta pusē strādājoša platforma, kas veidota tieši drošības testētājiem. Ļauj tokenus ātri apskatīt, automātiski meklēt ievainojamības (piemēram, none algoritmu vai galvenes injekciju) un lauzt atslēgas bezsaistē, neriskējot ar klienta sensitīvu tokenu nonākšanu svešā telemetrijā.
• Burp Suite (JWT Editor paplašinājums): dinamiskās testēšanas darbarīks. HTTP plūsmu pārtverot starpniekserverī, tokenu maina turpat uz vietas.
• JWT.io: Auth0 uzturēts standarta rīks ātrai atkodēšanai ar roku, kā arī tokena struktūras un paraksta pārbaudei izlūkošanas sākumā.
• JWTLens: viegla, uz privātumu vērsta alternatīva tokenu apskatei. Atkodē un pārbauda tokenus pilnībā pārlūkprogrammā, ar iebūvēto Web Crypto API, tāpēc atslēgas un tokeni datoru nepamet. Pārbaudes laikā rīks nesūta nevienu tīkla pieprasījumu, un tas algoritmu un paraksta apstiprināšanu padara drošu.

Praktiskā aizsardzība

Lai lietotne nenonāktu ziņojuma kritisko konstatējumu sarakstā, izstrādes komandai ir vērts ieviest piecus pamatnoteikumus:

• Fiksējiet gaidāmo algoritmu. Ienākošais tokens nekad nedrīkst izlemt, kā to pārbaudīt. Iestatiet pārbaudes loģikā vienu konkrētu algoritmu (piemēram, RS256), bet none noraidiet bez izņēmumiem.
• Pārbaudiet visus apgalvojumus. Derīgs paraksts pierāda tikai to, ka tokenam neviens nav pieskāries, nevis to, ka šim lietotājam tas tagad ir derīgs. Katrā pieprasījumā pārbaudiet exp (derīguma termiņš), iss (izdevējs) un aud (paredzētais saņēmējs).
• Pret simetrisko atslēgu izturieties kā pret paroli. Ja arhitektūra prasa simetrisku parakstīšanu (HS256), atslēgai vajadzīga vismaz 256 bitu entropija no kriptogrāfiski droša ģeneratora, un glabāties tai ir vides mainīgajā vai slepeno datu pārvaldniekā, nevis pirmkodā.
• Kodēšana nav šifrēšana. Payload daļā nav vietas ne sensitīviem datiem, ne personas datiem, ne parolēm. Kas tokenu pārtver, tas Base64 atkodē vienā mirklī.
• Nošķiriet tokenu glabāšanu. Īslaicīgais access tokens nedrīkst nonākt localStorage vai sessionStorage krātuvē, no kurienes to izvelk viena XSS ievainojamība. Access tokens paliek pārlūkprogrammas atmiņā, bet ilglaicīgais refresh tokens pieder Secure, HttpOnly, SameSite sīkdatnei.

Papildu nostiprināšana: phantom token modelis

Augstu drošības prasību vidē pret zādzību klienta pusē visefektīvāk pasargā tas, ka JWT līdz priekšgalam vispār nenonāk. Lielo organizāciju arhitektūrā to bieži risina ar „phantom token“ modeli:

1. Autorizācijas serveris klienta lietotnei JWT vietā izsniedz nejaušu, pašu par sevi neko neizpaudošu sesijas virkni.
2. Katrā API pieprasījumā klients nosūta tieši šo virkni.
3. API vārteja pieprasījumu pārtver, virkni pārbauda autorizācijas serverī vai sesiju krātuvē un apmaina pret pilnvērtīgu, parakstītu JWT.
4. Īsto JWT vārteja pārsūta iekšējiem mikropakalpojumiem.

Ko par to saka Latvijas regulējums

Latvijas kiberdrošības regulējums tokenus atsevišķi nepiemin, taču drošības prasības attiecas uz visiem informācijas sistēmas komponentiem, un autentifikācija ir viens no tiem.

Nacionālās kiberdrošības likuma (turpmāk – NKDL) 25. panta piektās daļas 2. punkts uzliek kiberdrošības pārvaldniekam pienākumu ne retāk kā reizi gadā veikt informācijas un komunikācijas tehnoloģiju drošības pārbaudi un atbilstoši tās rezultātiem organizēt konstatēto trūkumu novēršanu. Ministru kabineta noteikumu Nr. 397 „Minimālās kiberdrošības prasības“ 131. punkts A klases informācijas sistēmai prasa ielaušanās testu pirms nodošanas ekspluatācijā un pēc tam vismaz reizi trijos gados. Ja pašvaldības e-pakalpojums, klientu portāls vai mobilā lietotne sesijas balsta uz JWT, tokenu izdošana un pārbaude ir tāda pati pārbaudāmā virsma kā ugunsmūra konfigurācija vai publiskais serveris.

Otrs slānis ir datu aizsardzība. Vispārīgās datu aizsardzības regulas (VDAR) 32. panta 1. punkta d) apakšpunkts prasa regulāri testēt, izvērtēt un novērtēt drošības pasākumu efektivitāti, taču nenosaka, kādai tieši pārbaudei ir jābūt. Ja payload daļā glabājas personas dati un tokens no localStorage krātuves aizplūst uz svešu domēnu, runa vairs nav par tehnisku kļūdu, bet par personas datu aizsardzības pārkāpumu ar attiecīgo paziņošanas pienākumu Datu valsts inspekcijai.

Vienu lietu ir vērts pateikt uzreiz. HAXORIS ir Slovākijas uzņēmums, un NKDL 44. pantā noteikto atbilstības auditu neveicam; to veic neatkarīgs kiberdrošības auditors. Strādājam tehniskajā pusē: testējam lietotnes un sagatavojam ziņojumu, kuru auditors var pārbaudīt. Kā šī procedūra norit un kurš to drīkst veikt, aprakstīts rakstā par kiberdrošības auditu. Uz ko un cik bieži testēšanas pienākums attiecas, apskatīts rakstā par to, vai ielaušanās testēšana ir obligāta.

JWT drošība – biežāk uzdotie jautājumi

Kā HAXORIS var palīdzēt

Tokenu drošību reti salauž kriptogrāfija; gandrīz vienmēr to salauž konfigurācija. Šīs spraugas atrodam, pirms tās atrod uzbrucējs:

• Tīmekļa lietotņu un API ielaušanās testēšana ar īpašu uzsvaru uz autentifikācijas un autorizācijas plūsmām.
• JWT izdošanas un pārbaudes loģikas, kā arī atslēgu pārvaldības caurskate, tostarp JWKS apstrāde un atslēgu maiņa.
• Simetrisko parakstīšanas atslēgu izturība, ko pārbaudām bezsaistē.
• Tokenu glabāšanas, sesiju ilguma un refresh tokena arhitektūras caurskate.

Kopsavilkums

JWT pēc uzbūves nav nedrošs. Nedrošs tas kļūst brīdī, kad lietotne ļauj pašam tokenam izlemt, kā to pārbaudīt, vai kad derīgu parakstu uztver par autorizācijas aizstājēju. Fiksēts algoritms, katra apgalvojuma pārbaude, kā parole glabāta atslēga, payload bez sensitīviem datiem un no pārlūkprogrammas krātuvēm izņemti tokeni: ar šiem pieciem noteikumiem lielākā daļa rakstā uzskaitīto konstatējumu no nākamā ziņojuma pazūd.

HAXORIS šajā jomā strādā tehniskajā pusē. Veicam tīmekļa lietotņu un API ielaušanās testēšanu atbilstoši OWASP WSTG vadlīnijām, bet lietotņu drošības prasības pārbaudām atbilstoši OWASP ASVS. Ja JWT autentifikācija jau strādā produkcijā vai tuvojas palaišanai, piesakieties bezmaksas konsultācijai, un kopā ar jūsu komandu saskaņosim tvērumu.

Avoti un ieteicamā literatūra

Raksta metodika un tehniskās detaļas balstītas šādos publiski pieejamos drošības avotos:

1. PortSwigger Web Security Academy. JWT Security Vulnerabilities. Detalizēts paraksta pārbaudes kļūdu un galvenes injekciju apraksts. portswigger.net/web-security/jwt
2. InfoSec Writeups. JWT Pentesting: A Journey from Token to Takeover. Praktiski gadījumi par tokenu konfigurācijas izmantošanu. infosecwriteups.com
3. Auth0 / JWT.io. Introduction to JSON Web Tokens. Standarta pamatdokumentācija par tokenu uzbūvi un RFC 7519. jwt.io/introduction
4. JWTAuditor. Security Testing Tool. Rīks payload pārveidošanai un automatizētai ievainojamību meklēšanai. jwtauditor.com

Saistītie Haxoris pakalpojumi: tīmekļa lietotņu un API ielaušanās testēšana