JWT: tuzilmasi va zaifliklari

1) JWT nima va undan qayerda foydalaniladi

JWT -’Base64Url (header) formatidagi o’z-o’zini ta’minlaydigan ixcham tasdiqlash konteyneri (claims). Base64Url(payload). Base64Url(signature)`.

• JWS (imzolangan tokenlar - haqiqiylik/yaxlitlik),
• JWE (shifrlangan tokenlar - maxfiylik),
• OIDC/OAuth2/ID tokenlari va service-to-service autentifikatsiyasi sifatida koʻrsatiladi.

Afzalliklari: avtonomiya, keshlash, kichik yuk xarajatlari. Kamchiliklar: noto’g "ri validatsiya qilish xavfi, chaqirib olishning murakkab holatlari.

2) JWT tuzilmasi

2. 1 Sarlavha (header, JSON)

Minimal: kalit algoritmi va identifikatori.

json
{ "alg": "ES256", "kid": "jwt-2025-10", "typ": "JWT" }

’alg’: imzo/shifrlash algoritmi (RS256/ES256/PS256/HS256 va h.k.).
’kid’: kalit koʻrsatgichi (JWKS-rotatsiya uchun).
Ixtiyoriy kalitlar manbalari:’jku’,’x5u’(zaifliklarga qarang § 6. 3).

2. 2 Foydali yuk (payload, JSON)

• `iss` (issuer), `aud` (audience), `sub` (subject)
• ’exp’ (tugash vaqti),’nbf’(oldin emas),’iat’(berilgan)
• ’jti’ (token identifikatori, sharhlar uchun yaroqli)
• domain-tamg’alar:’scope/roles’,’tenant’,’kyc _ level’va boshqalar.

2. 3 Imzo (signature)

JWS = `sign(base64url(header) + "." + base64url(payload), private_key)`

Tekshirish: ochiq kalitda va server kutayotgan algoritmda.

3) Tekshirishning bazaviy invariantlari

1. Algoritm’header’ning mazmuniga ishonmay, resurs-serverning (allow-list) konfiguratsiyasi bilan belgilanadi. alg`.
2. ’iss’ va’aud’ning aniq mos kelishini tekshirish,’exp/nbf’kichik’clock _ skew’(30-60s ±) ni hisobga olgan holda.
3. Faqat bitta kalit bo’lmaganda va rotatsiya bo’lmaganda’kid’tokenlarini rad etish; aks holda -’kid’ni talab qilish.
4. Obyekt darajasida avtorizatsiyasiz hech qanday tamgʻaga ishonmaslik (BOLA-first).
5. Parsing - kripto tekshiruvidan keyin; dekodlashdan oldingi o’lchamni bazaviy tekshirish.

4) JWS vs JWE

JWS: imzolangan, lekin oʻqib boryapmiz. Payload PII/sirlarga kiritmang.
JWE: payloadni shifrlaydi; integratsiya qiyinroq, asosiy model tanqidiy.
Ko’pgina API’larda JWS + payload’dagi sezgir ma’lumotlarga taqiq etarli.

5) Tokenning hayot sikli

Access: qisqa muddat (5-30 daqiqa).
Refresh: uzoq (7-30 kun), rotate-on-use (bir marta ishlatiladigan), «qora ro’yxat»’jti/sid’ni saqlash.
Revocation: TTL bilan’jti’ro’yxati, opaque-tokenlar uchun introspektsiya, hodisalarda’exp’qisqartmasi.
Kalitlar rotatsiyasi: JWKS (eski + yangi), «Kalitlar rotatsiyasi» maqolasiga qarang.

6) Tez-tez uchraydigan zaifliklar va ularni qanday yopish kerak

6. 1’alg = none ’/algoritm almashtirish

Xulosa: server’alg’maydoniga ishonadi va imzolanmagan tokenni qabul qiladi.
Himoya: serverdagi qattiq algoritmlar allow-list; ’none’ va kutilmagan qiymatlarni rad etish.

6. 2 RS256 → HS256 swap (simmetrizatsiya)

Xulosa: tajovuzkor’alg’HS256 o’rnini bosadi va HMAC-sir sifatida ochiq kalitdan foydalanadi.
Himoya: kalitni algoritmga moslash; simmetrik/assimmetrik provayderlarni bitta’kid’ga aralashtirmaslik.

6. 3 Kalit inyeksiyasi (’kid/jku/x5u’)

• ’jku’ JWKS nazoratini ko’rsatadi (o’z kalitini qo’yadi).
• ’x5u ’/’ x5c’ tashqi sertifikatlarni suiiste’mol qilish.
• ’kid’ in bilan yo’l/SQL (’../../privkey. pem’’yoki’’’OR 1 = 1 --’’).

• Olib tashlangan’jku/x5u’ni eʼtiborsiz qoldirish yoki domenlarning qattiq allow-listini filtrlash.
• ’kid’ dan faqat lokal katalog (jadval/kesh), fayl yoʻllarisiz/SQL konkatenatsiyasiz foydalanish.
• JWKS ishonchli URL, qisqa TTL, imzo/pinning kanalidan yuklanadi.

6. 4 HS256 zaif sirlari

Xulosa: HMAC-sir qisqa/oqish → imzoni almashtirish.
Himoya: asimmetriya (RS/ES/PS) yoki sir uzunligi ≥ 256 bit, sirlar - faqat KMSda.

6. 5 Yo’q/nevalid tamg’alar

Hech’aud ’/’ iss ’/’ exp’→ tokeni kross-servis uchun mos yoki cheksiz.
Juda uzoq’exp’→ buzilish xavfi.
Himoyalanish:’exp’tamg’alarining to’liq to’plamini talab qilish,’nbf ’/’ iat’ni’clock _ skew’bilan tasdiqlash.

6. 6 Replay va tokenni o’g "irlash

Mohiyati: tokenni ushlash/takrorlash (loglarda, XSS, TLSsiz MitM oqishi).

• TLS везде, `Secure`+`HttpOnly` cookie, SameSite=Lax/Strict.
• DPoP/PoP (tokenni mijoz kalitiga bogʻlash) va/yoki hamkorlar uchun mTLS.
• Qisqa’exp’, refresh-rotatsiya, device-binding.

6. 7 XSS/ombor orqali oqish

JWT’localStorage ’/’ sessionStorage’→ da JS mavjud.
Himoya: access-tokenlarni HttpOnly-cookie-da saqlash (agar cookie-model mavjud boʻlsa) + qattiq CSP/Trusted Types.
SPA uchun kukisiz - tokenni xotirada izolyatsiya qilish, minimal yashash, XSS dan himoya qilish.

6. 8 CSRF

Xulosa: cookie-sessiyalarda uchinchi tomon saytidan so’rovlar.
Himoya: SameSite, anti-CSRF tokenlari (double submit),’Origin/Referer’tekshirish, Fetch-Metadata filtrlari.

6. 9 Oversize/o’lchamni suiiste’mol qilish

Mohiyati: katta payload/sarlavhalar, parsing uchun DoS.
Himoya: sarlavhalar/tana o’lchamlari limitlari, early-reject 431/413, markalar fix-to’plami.

6. 10’typ ’/’ cty’almashtirish

Mohiyati: JOSE-obʼektlarga kiritilgan turdagi chalkashliklar (’typ:’JWT’).
Himoya: xavfsizlik uchun’typ/cty’ga eʼtibor bermaslik, belgilangan algoritmlar va tamgʻalar sxemasiga tayanish.

7) Tokenlarni saqlash va topshirish

7. 1 Server API (machine-to-machine)

mTLS/HMAC, JWT uchun asimmetriya, kanallar - mesh orqali.
Kalitlar ombori - KMS/HSM, jadval bo’yicha rotatsiya, yopiq JWKS.

7. 2 Brauzer mijozlari

HttpOnly Secure Cookie для access/refresh; qisqa TTL; yangilash - «silent refresh» orqali’SameSite = None’faqat HTTPS ostida.
Qattiq CSP, Trusted Types, XSS dan himoya qilish; SPA uchun - iloji bo’lsa, tokenni diskda saqlamang.

8) JWKS, rotatsiya va chaqirib olish

JWKS avtorizator tomonidan e’lon qilinadi; iste’molchilar 5-15 daqiqa davomida kesh qiladilar.
Rotatsiya rejasi: yangi’kid’qoʻshish → imzolashni boshlash → N kundan keyin eskisini JWKS → purge’dan olib tashlash.
Sharh:’jti/sid’c TTL ro’yxatlari; hodisa sodir bo’lganda vaqtincha’exp’va fors-logout’ni qisqartirish (nogironlashtirish refresh).

9) Multi-tenant va ma’lumotlarni minimallashtirish

’tenant ’/’ org’ ni faqat arxitektura boʻyicha kiritish; aks holda PDP atributlarini’sub’bo’yicha tortish.
Hech qanday PII; yorliqlarning minimal to’plami → oqish va korelatsiya xavfi kamroq.

10) Amaldagi validatsiya chek-varaqasi (resurs serveri)

• Parsim faqat imzo va bazaviy o’lchov limitlari tekshirilgandan keyin.
• ’alg’ning konfiguratsiyasi; kutilmaganda rad etish.
• Tekshirish’iss’∧’aud’∧’exp’∧’nbf’∧’iat’(s’clock _ skew’).
• ’kid’ni lokal katalog/JWKS (qisqa TTL) boʻyicha tekshirish.
• Tashqi belgilarni filtrlash/normallashtirish (’jku/x5u’- faqat allow-list).
• Tamg’alarning uzunligi/tarkibini cheklash.
• Resursga obʼekt avtorizatsiyasini qoʻllash (BOLA-first).
• ’kid’,’sub’,’aud’,’iss’,’jti’,’exp’,’tenant’,’trace _ id’(PIIsiz).
• Imzo xatolari, kechikishlar, rotatsiya auditi ko’rsatkichlari.

11) Xavfsiz siyosat misollari (psevdo)

11. 1 Algoritm kutish moslamalari

yaml jwt:
expected_issuer: "https://auth. example. com"
expected_audience: ["wallet-service"]
allowed_algs: ["ES256"] # fix the jwks_url: "https ://auth. example. com/.well-known/jwks. json"
jwks_cache_ttl: 600s clock_skew: 60s required_claims: ["iss","aud","sub","exp","iat"]

11. 2 Masofadagi’jku/x5u’dan voz kechish

yaml reject_untrusted_key_sources: true allowed_jku_hosts: ["auth. example. com"] # if absolutely necessary

11. 3 Sharhlar ro’yxati misoli (Redis)

pseudo if redis. exists("revoke:jti:" + jti) then deny()
if now() > exp then deny()

12) Kuzatish va forenzika

Метрики: `jwt_verify_fail_total{reason}`, `jwt_expired_total`, `jwks_refresh_total`, доля `kid`.
Logi (strukturalangan):’iss/aud/sub/kid/jti/exp/tenant/trace _ id’, rad etish sababi.
Dashbordlar: «tez orada tugaydi», validatsiya xatolarining ko’payishi, mintaqalar/mijozlar bo’yicha taqsimlanish.
Alertlar:’verify _ fail’(imzo/algoritm), JWKS xatolari, muddati o’tgan tokenlar ulushi.

13) Antipatternlar

Ishonchli’alg’iz token; ’none’ ni qoʻllab-quvvatlash.
Uzoq umr ko’radigan access-tokenlar va refresh-rotatsiyaning yo’qligi.
HS256 maxfiy/maxfiy ENVda KMSsiz.
’jku/x5u’ ni istalgan domendan qabul qilish; JWKSni allow-listsiz dinamik yuklash.
Payload JWS ga PII/sirlarni qoʻyish.
XSS-xavflar mavjud bo’lgan taqdirda tokenlarni’localStorage’da saqlash.
Validatsiya xatolarini oʻchirish («soft error» bilan 200 ni qaytarish).
BOLA tekshiruvlarining yo’qligi va faqat’scope/role’ga tayanish.

14) iGaming/Moliya xususiyatlari

Tamg’alar:’kyc _ level’,’risk _ tier’,’tenant’, qattiq’aud’.
Write-operatsiyalar uchun qisqa TTL (depozitlar/xulosalar), kritik yo’nalishlar uchun PoP/DPoP yoki mTLS.
Tartibga solish auditi: kirish/rad etishning o’zgarmas jurnallari, mintaqa chegaralarida loglarni saqlash.
Hamkorlarda/PSPda alohida kalitlar/’ aud’, pertenant kalitlar va alohida JWKS mavjud.

15) Prod-tayyorlik chek-varaqasi

• Qattiq allow-list algoritmlari;’none’taqiqlangan.
• ’iss/aud/exp/nbf/iat/jti’tekshirilmoqda; qisqa’exp’.
• JWKS, qisqa TTL kesh; ’kid’ ulushlari monitoringi.
• Refresh — rotate-on-use; ’jti/sid’ s TTL ro’yxatlari; sharhlar pleybuki.
• Kritik yo’nalishlarda PoP/DPoP yoki mTLS.
• Brauzer uchun HttpOnly-cookies, CSP/Trusted Types vs XSS; CSRF himoyasi.
• Payload-da PIIsiz; eng kam tamg’alar to’plami.
• Validatsiya va rad etish bo’yicha metrika/loglar; alertlar JWKS/verify_fail.
• Salbiy stsenariy testlari: RS → HS swap,’kid’inʼeksiya,’jku’spoofing, oversize, clock-skew.

16) TL; DR

Algoritm va kalitlarni server tomoniga oʻrnating,’alg’ga ishonmang,’iss/aud/exp/nbf/iat/jti’ni talab qiling. Kalitlarni JWKS orqali almashtiring, tokenlarni qisqa yashaydigan, refresh esa bir marta ishlatiladigan qilib saqlang. Tokenlarni xavfsiz saqlang (veb uchun HttpOnly cookie), tamg’alarni minimallashtiring, PII qo’ymang. ’jku/x5u/kid’ vektorlarini yoping, zaif sirli HS256 oldini oling, tanqidiy yo’llarda PoP/DPoP yoki mTLS qo’shing va doimo BOLA tekshiruvlarini o’tkazing.