JWT: სტრუქტურა და დაუცველობა

1) რა არის JWT და სად გამოიყენება იგი

JWT არის კომპაქტური თვითკმარი განცხადება კონტეინერი 'BaseeceUrl (header) ფორმატით. Base64Url(payload). Base64Url(signature)`.

• JWS (ხელმოწერილი ნიშნები - ნამდვილობა/მთლიანობა),
• JWE (დაშიფრული ნიშნები - კონფიდენციალურობა),
• OIDC/OAuth2, როგორც Access/ID ნიშნები, ასევე ავტორიზაციის სამსახურის მომსახურება.

უპირატესობები: ავტონომია, ქეშირეთობა, მცირე ღირებულების ხარჯები. უარყოფითი მხარეები: არასწორი ვალიდაციის რისკი, გაწვევის რთული შემთხვევები.

2) JWT სტრუქტურა

2. 1 სათაური (header, JSON)

მინიმალური: ალგორითმი და გასაღების იდენტიფიკატორი.

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

'alg': ხელმოწერის/დაშიფვრის ალგორითმი (RS256/ES256/PS256/HS256 და ა.შ.).
'kid': გასაღების ინდექსი (JWKS როტაციისთვის).
სურვილისამებრ საკვანძო წყაროები: 'jku', 'x5u' (იხ. დაუცველობა § 6. 3).

2. 2 დატვირთვა (payload, JSON)

• `iss` (issuer), `aud` (audience), `sub` (subject)
• 'exp' (გასვლის დრო), 'nbf' (არა უადრეს), 'iat' (გაცემულია)
• 'jti' (ტოქსინის იდენტიფიკატორი შესაფერისია მიმოხილვისთვის)
• დომენის სტიგმები: 'scope/roles', 'tenant', 'kyc _ level' და ა.შ.

2. 3 ხელმოწერა

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

შემოწმება: მკაცრად შესაბამისი საზოგადოებრივი გასაღები და ზუსტად ის ალგორითმი, რომელსაც სერვერი ელოდება.

3) ძირითადი ინვარიანტები

1. ალგორითმი ფიქსირდება რესურსის სერვერის კონფიგურაციით (allow-list) და არ ენდობა შინაარსს 'header. alg`.
2. შეამოწმეთ 'iss' და 'aud' ზუსტი დამთხვევისთვის, 'exp/nbf' - მცირე 'clock _ skew' (± 30-60s) გათვალისწინებით.
3. უარი თქვით ნიშნები 'kid' გარეშე მხოლოდ იმ შემთხვევაში, თუ ერთადერთი გასაღები არ არის როტაცია; წინააღმდეგ შემთხვევაში - მოითხოვეთ 'kid'.
4. არ ენდოთ რაიმე სტიგმას ობიექტის დონეზე ავტორიზაციის გარეშე (BOLA-first).
5. პარსინგი - კრიპტოვალუტის შემდეგ; ძირითადი ზომის შემოწმება დეკოდირებამდე.

4) JWS vs JWE

JWS: გაფორმებულია, მაგრამ წაიკითხეთ. ნუ მოათავსებთ PII/საიდუმლოებებს.
JWE: დაშიფვრა payload; ინტეგრაცია უფრო რთულია, საკვანძო მოდელი კრიტიკულია.
API- ს უმეტესობა საკმარისია JWS + - ში მგრძნობიარე მონაცემების აკრძალვა payload- ში.

5) ნიშნის სასიცოცხლო ციკლი

წვდომა: მოკლე დროში (5-30 წუთი).
Refresh: გრძელი (7-30 დღე), rotate-on-use (ერთჯერადი), შეინახეთ „შავი სია“ 'jti/sid'.
Revocation: 'jti' s TTL სიები, ინტროსპექცია opaque ნიშნებისთვის, ინციდენტების შემცირება 'exp'.
გასაღებების როტაცია: JWKS გადახურვით (ძველი + ახალი), იხილეთ სტატია „გასაღების როტაცია“.

6) ხშირი დაუცველობა და როგორ დავხუროთ ისინი

6. 1 'alg = nonone '/ალგორითმის შემცვლელი

არსი: სერვერი ენდობა ველს 'alg' და იღებს დაუსაბუთებელ ნიშანს.
დაცვა: სერვერზე ალგორითმების მკაცრი ალგორითმი; უარყავით 'none' და მოულოდნელი მნიშვნელობები.

6. 2 RS256 - HS256 swap (სიმეტრიზაცია)

არსი: თავდამსხმელი შეცვლის 'alg' HS256- ს და იყენებს საზოგადოებრივ გასაღებს, როგორც HMAC საიდუმლოებას.
დაცვა: დააკავშიროთ გასაღები კონფიგურაციის ალგორითმზე; არ აურიოთ სიმეტრიული/ასიმეტრიული პროვაიდერები ერთ 'kid' -ში.

6. 3 გასაღების ინექცია ('kid/jku/x5u')

• 'jku' მიუთითებს თავდამსხმელის მიერ კონტროლირებად JWKS (მისი გასაღები).
• 'x5u '/' x5c' გარე სერთიფიკატების ბოროტად გამოყენება.
• 'kid' ბილიკის ინექციით/SQL ('' "../../privkey. pem '' ან '' 'OR 1 = 1 -').

• უგულებელყოთ წაშლილი 'jku/x5u' ან გაფილტრეთ მკაცრი allow სიის დომენები.
• 'kid' გამოიყენოთ მხოლოდ როგორც გასაღები ადგილობრივ კატალოგში (ცხრილი/ქეში), ფაილური ტრასების გარეშე/SQL concatenations.
• JWKS დატვირთეთ სანდო URL, მოკლე TTL, ხელმოწერა/არხის pinning.

6. 4 სუსტი საიდუმლოებები HS256 (ბრუტფორსი)

არსი: HMAC საიდუმლო მოკლე/იხვები - ხელმოწერის ჩანაცვლება.
დაცვა: გამოიყენეთ ასიმეტრია (RS/ES/PS) ან საიდუმლო სიგრძე 256 ბიტი, საიდუმლოებები მხოლოდ KMS- ში.

6. 5 არარსებული/არასასურველი სტიგმები

არ არის 'aud '/' iss '/' exp' ნიშნის ჯვარი შესაფერისი ან უსასრულოა.
ძალიან გრძელი „ექსპრესი“ კომპრომისის რისკს წარმოადგენს.
დაცვა: მოითხოვეთ სტიგმების სრული ნაკრები, 'exp' მოკლე, 'nbf '/' iat' კოორდინაცია 'clock _ skew' - ით.

6. 6 Replay და ნიშნის ქურდობა

არსი: ნიშნის ჩარევა/გამეორება (გაჟონვა ლოგოებში, XSS, MitM TLS გარეშე).

• TLS везде, `Secure`+`HttpOnly` cookie, SameSite=Lax/Strict.
• DPoP/PoP (ნიშნის დაკავშირება კლიენტთან) ან/და mTLS პარტნიორებისთვის.
• მოკლე 'exp', refresh როტაცია, მოწყობილობა.

6. 7 გაჟონვა XSS/საცავის საშუალებით

არსი: JWT შენახვა 'localStorage '/' sessionStorage' არის ხელმისაწვდომი JS.
დაცვა: შეჯახების ნიშნების შენახვა Conly-cookie (თუ შესაძლებელია cookie მოდელი) + მკაცრი CSP/Trusted Types.
Cookie- ს გარეშე SPA- სთვის - მეხსიერების ნიშნის იზოლირება, მინიმალური ცხოვრება, XSS- დან დაცვა.

6. 8 CSRF

არსი: ქუქი-ფაილების სესიების დროს, მესამე მხარის საიტიდან მოთხოვნა.
დაცვა: SameSite, anti-CSRF ნიშნები (ორმაგი წყალქვეშა), 'Origin/Referer' შემოწმება, Fetch-Metadata ფილტრები.

6. 9 Oversize/ზომების ბოროტად გამოყენება

არსი: უზარმაზარი payload/სათაურები, DoS პარსინგისთვის.
დაცვა: სათაურების/სხეულის ზომის ლიმიტები, early-reject 431/413, წებოვანი ფიქსირებული ნაკრები.

6. 10 ჩანაცვლება 'typ '/' cty'

არსი: ტიპის დაბნეულობა ('typ: „JWT“'), ინვესტიცია JOSE ობიექტებით.
დაცვა: უგულებელყოს უსაფრთხოების 'typ/cty', დაეყრდნოს ფიქსირებულ ალგორითმებს და სტიგმების სქემას.

7) ტოქსინების შენახვა და გადაცემა

7. 1 სერვერის API (მანქანა მანქანა)

mTLS/HMAC, სასურველია ასიმეტრია JWT- სთვის, არხები - მასის საშუალებით.
საკვანძო საცავი - KMS/HSM, გრაფიკული როტაცია, JWKS გადახურვით.

7. 2 ბრაუზერის კლიენტები

HttpOnly Secure Cookie для access/refresh; მოკლე TTL; განახლება - „silent refresh“ - ით 'SameSite = None' მხოლოდ HTTPS- ის ქვეშ.
მკაცრი CSP, Trusted Types, დაიცვას XSS; SPA- სთვის - თუ ეს შესაძლებელია, დისკზე არ შეინახოთ ნიშანი.

8) JWKS, როტაცია და მიმოხილვა

JWKS გამოქვეყნებულია ავტორიზატორის მიერ; მომხმარებლები 5-15 წუთის განმავლობაში ქაჩავენ.
როტაციის გეგმა: დაამატეთ ახალი 'kid' და დაიწყეთ მათი ხელმოწერა N- ის შემდეგ ძველი JWKS-purge- დან წაშლა.
მიმოხილვა: სიები 'jti/sid' c TTL; ინციდენტთან ერთად, დროებით შეამცირეთ 'exp' და fors-logout (ინვალიდი ინვალიდი).

9) Multi-tenant და მონაცემთა შემცირება

ჩართეთ 'tenant '/' org' ნიშანი მხოლოდ იმ შემთხვევაში, თუ საჭიროა არქიტექტურა; წინააღმდეგ შემთხვევაში, ამოიღეთ ატრიბუტები PDP- დან 'sub- ზე.
არა PII; სტიგმების მინიმალური ნაკრები ნაკლები გაჟონვის და კორელაციის რისკია.

10) სავალდებულო პრაქტიკული შემოწმების სია (რესურსის სერვერი)

• პარსიმი მხოლოდ ხელმოწერის შემოწმების შემდეგ და ზომების ძირითადი ლიმიტები.
• 'alg' კონფიგურაციიდან; უარყავით მოულოდნელი.
• შეამოწმეთ 'iss' aud 'aud' 'exp' nbf- ის 'iat' ('clock _ skew').
• შეამოწმეთ 'kid' ადგილობრივი დირექტორია/JWKS (მოკლე TTL).
• გარე ინდიკატორების გაფილტვრა/ნორმალიზება ('jku/x5u' - მხოლოდ ალოუ სია).
• შეზღუდეთ სტიგმების სიგრძე/შემადგენლობა (სქემა).
• გამოიყენეთ ობიექტის უფლებამოსილება რესურსზე (BOLA-first).
• 'kid', 'sub', 'aud', 'iss', 'jti', 'exp', 'tenant', 'trace _ id' (PII გარეშე).
• ხელმოწერის შეცდომების მეტრიკა, დაგვიანება, როტაციის აუდიტი.

11) უსაფრთხო პოლიტიკოსის მაგალითები (ფსევდო)

11. 1 ალგორითმის მოლოდინების კონფიგურაცია

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 დისტანციური უარი 'jku/x5u'

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

11. 3 მიმოხილვების ჩამონათვალის მაგალითი (Redis)

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

12) დაკვირვება და წინსვლა

Метрики: `jwt_verify_fail_total{reason}`, `jwt_expired_total`, `jwks_refresh_total`, доля `kid`.
Logs (სტრუქტურირებული): 'iss/aud/sub/kid/jti/exp/tenant/trace _ id', უარის თქმის მიზეზი.
დაშბორდები: „მალე ამოიწურება“, ვალიდაციის შეცდომების ზრდა, რეგიონების/მომხმარებლების განაწილება.
ალერტები: ზრდა 'verify _ fail' (ხელმოწერა/ალგორითმი), JWKS შეცდომები, ვადაგადაცილებული ნიშნების წილი.

13) ანტიპატერები

ენდობა ნიშნის 'alg'; 'none- ს მხარდაჭერა.
გრძელი წვდომის ნიშნები და რეფრესის როტაციის არარსებობა.
HS256 მოკლე საიდუმლოებით/საიდუმლო ENV- ში KMS- ის გარეშე.
მიიღეთ 'jku/x5u' ნებისმიერი დომენიდან; დინამიურად ჩამოტვირთეთ JWKS ალოუ-სიის გარეშე.
განათავსეთ PII/საიდუმლოებები payload JWS- ში.
შეინახეთ ნიშნები „localStorage“ -ში XSS რისკებით.
შეჩერდით ვალიდაციის შეცდომებს (დააბრუნეთ 200 „რბილი ერორიდან“).
BOLA შემოწმების არარსებობა და მხოლოდ 'scope/role' დაეყრდნო.

14) iGaming/ფინანსების სპეციფიკა

სტიგმები: 'kyc _ level', 'risk _ tier', 'tenant', მკაცრი 'aud'.
მოკლე TTL write ოპერაციებისთვის (ანაბრები/დასკვნები), PoP/DPoP ან mTLS კრიტიკული მარშრუტებისთვის.
მარეგულირებელი აუდიტი: შეყვანის/წარუმატებლობის უცვლელი ჟურნალები, რეგიონის საზღვრებში ლოგოების შენახვა.
პარტნიორებს/PSP- ს აქვთ ცალკეული გასაღებები/' aud ', გასაღებები და ინდივიდუალური JWKS.

15) მზადყოფნის სიის სია

• ალგორითმების მკაცრი ალგორითმი; 'none' აკრძალულია.
• 'iss/aud/exp/nbf/iat/jti' შემოწმებულია; მოკლე 'exp'.
• JWKS გადახურვით, მოკლე TTL ქეში; 'kid' აქციების მონიტორინგი.
• Refresh — rotate-on-use; სიები 'jti/sid' s TTL; მიმოხილვების ფლეიბუკი.
• PoP/DPOP ან mTLS კრიტიკულ მარშრუტებზე.
• Sconly-cookies ბრაუზერისთვის, CSP/Trusted Types XSS- ის წინააღმდეგ; CSRF დაცვა.
• PII გარეშე payload; სტიგმების მინიმალური ნაკრები.
• მეტრიკი/ლოგები ვალიდაციისა და უარის თქმის შესახებ; ალერტები JWKS/verify _ fail.
• უარყოფითი სკრიპტების ტესტები: RS-HS swap, 'kid' - ინექცია, 'jku' spoofing, oversize, clock-skew.

16) TL; DR

ჩაწერეთ ალგორითმი და გასაღებები სერვერის მხარეს, არ ენდოთ 'alg' ნიშანს, მოითხოვეთ 'iss/aud/exp/nbf/iat/jti'. გადაიტანეთ გასაღებები JWKS- ით გადახურვით, შეინარჩუნეთ ნიშნები მოკლევადიანი, ხოლო რეფრესი ერთჯერადი. შეინახეთ ნიშნები უსაფრთხოდ (Sconly Only-cookie ვებისთვის), მინიმუმამდე დაიყვანეთ ბრენდები, არ დააყენოთ PII. დახურეთ 'jku/x5u/kid' ვექტორები, მოერიდეთ HS256- ს სუსტი საიდუმლოებებით, დაამატეთ PoP/DPoP ან mTLS კრიტიკულ მარშრუტებზე და ყოველთვის გააკეთეთ BOLA შემოწმება რესურსის დონეზე.