JWT: ساختار و آسیب پذیری

1) JWT چیست و در کجا استفاده می شود

JWT یک ظرف ادعای خود شامل جمع و جور در فرمت 'Base64Url (هدر) است. Base64Url (payload) Base64Url (امضا)

• JWS (نشانه های امضا شده - صحت/یکپارچگی)،
• JWE (نشانه های رمزگذاری شده - حریم خصوصی)،
• OIDC/OAuth2 به عنوان نشانه های دسترسی/شناسه و همچنین احراز هویت سرویس به سرویس.

مزایا: استقلال، قابلیت اطمینان، سربار کم. معایب: خطر اعتبارسنجی نادرست، موارد فراخوان پیچیده.

2) ساختار JWT

2. 1 هدر (JSON)

حداقل: الگوریتم و شناسه کلیدی.

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

«alg»: الگوریتم امضا/رمزگذاری (RS256/ES256/PS256/HS256 و غیره).
'kid': اشاره گر به کلید (برای چرخش JWKS).
منابع کلیدی اختیاری: 'jku'، 'x5u' (نگاه کنید به آسیب پذیری § 6. 3).

2. 2 بارگیری (JSON)

• 'iss' (صادر کننده)، 'aud' (مخاطب)، 'sub' (موضوع)
• 'exp' (زمان انقضا)، 'nbf' (نه قبل از)، 'iat' (صادر شده)
• 'jti' (شناسه نشانه، قابل لغو)
• تمبرهای دامنه: «دامنه/نقش»، «مستاجر»، «kyc _ level» و غیره

2. 3 امضا

JWS = 'علامت (base64url (header) +'. '+ base64url (payload), private_key)'

تأیید: کلید عمومی کاملاً متناظر و دقیقاً الگوریتمی که سرور انتظار دارد.

3) بررسی پایه ثابت

1. الگوریتم توسط پیکربندی سرور منبع (allow-list) ثابت شده است و با محتویات "header اعتماد ندارد. همه چیز.
2. بررسی «iss» و «aud» برای یک بازی دقیق، «exp/nbf» - با در نظر گرفتن کوچک «clock _ skew» (± 30-60).
3. توکن ها را بدون «بچه» فقط در صورت وجود یک کلید واحد و بدون چرخش رد کنید. در غیر این صورت، درخواست «بچه».
4. به تمبرهای بدون مجوز سطح شیء (BOLA-first) اعتماد نکنید.
5. تجزیه - پس از تایید رمزنگاری; بررسی اندازه اولیه قبل از رمزگشایی.

4) JWS در مقابل JWE

JWS: امضا شده اما قابل خواندن است. PII/اسرار بارگیری را وارد نکنید.
JWE: رمزگذاری محموله ؛ ادغام دشوارتر است، مدل کلیدی حیاتی است.
در اکثر API ها، ممنوعیت JWS + در داده های حساس در payload کافی است.

5) چرخه عمر توکن

دسترسی: کوتاه مدت (5-30 دقیقه).
تازه کردن: طولانی تر (7-30 روز)، چرخش در استفاده (یک بار)، نگه داشتن «لیست سیاه» 'jti/sid'.
ابطال: لیست 'jti' with TTL، خودآزمایی برای نشانه های مبهم، اختصار 'exp' برای حوادث.
چرخش کلید: JWKS با همپوشانی (قدیمی + جدید)، مقاله «چرخش کلید» را ببینید.

6) آسیب پذیری های مکرر و نحوه بستن آنها

6. 1 'alg = none '/جایگزینی الگوریتم

خط پایین: سرور به فیلد «alg» اعتماد می کند و یک توکن بدون علامت را می پذیرد.
حفاظت: لیست اجازه سخت الگوریتم ها در سرور ؛ «هیچ» و ارزش های غیر منتظره را رد کنید.

6. 2 RS256 → تعویض HS256 (تقارن)

خط پایین: یک مهاجم «alg» را با HS256 جایگزین می کند و از کلید عمومی به عنوان یک راز HMAC استفاده می کند.
حفاظت: اتصال کلید به الگوریتم با پیکربندی ؛ ارائه دهندگان متقارن/نامتقارن را در یک «kid» مخلوط نکنید.

6. 3 تزریق کلید («بچه/jku/x5u»)

• «jku» به JWKS تحت کنترل مهاجم اشاره می کند (کلید آن را لغزش می کند).
• 'x5u '/' x5c' استفاده از گواهینامه های خارجی.
• 'kid' with/تزریق مسیر SQL ('.. "/../خصوصی. pem «» یا «» OR 1 = 1 - «»).

• چشم پوشی از حذف 'jku/x5u' و یا فیلتر توسط سخت اجازه لیست دامنه.
• «kid» فقط باید به عنوان یک کلید در دایرکتوری محلی (جدول/کش)، بدون مسیرهای فایل/اتصالات SQL استفاده شود.
• JWKS از URL های قابل اعتماد، TTL کوتاه، کانال امضا/پینینگ بارگیری می شود.

6. 4 اسرار ضعیف HS256 (نیروی بی رحم)

خط پایین: HMAC راز کوتاه است/به بیرون درز → signature spoofing.
حفاظت: استفاده از عدم تقارن (RS/ES/PS) یا طول مخفی ≥ 256 بیت، اسرار - فقط در KMS.

6. 5 تمبر گم شده/نامعتبر

No 'aud '/' iss '/' exp' → توکن قابل استفاده یا بینهایت است.
بیش از حد طولانی → خطر سازش.
حفاظت: نیاز به مجموعه ای کامل از علائم، 'exp' کوتاه، 'nbf '/' iat' اعتبار با 'clock _ skew'.

6. 6 پخش و سرقت توکن

ماهیت: رهگیری/تکرار یک نشانه (نشت در سیاهههای مربوط، XSS، MitM بدون TLS).

• TLS везде، کوکی 'Secure' + 'HttpOnly'، SameSite = Lax/Strict.
• DPoP/PoP (اتصال یک توکن به کلید مشتری) و/یا mTLS برای شرکا.
• کوتاه 'exp'، تازه کردن چرخش، دستگاه اتصال.

6. 7 XSS/ذخیره سازی نشت

خط پایین: ذخیره سازی JWT در 'localStorage '/' sessionStorage' → در دسترس JS است.
حفاظت: ذخیره نشانه های دسترسی در HttpOnly-cookie (اگر مدل کوکی امکان پذیر است) + انواع CSP/Trusted دقیق.
برای SPA بدون کوکی ها - رمز را در حافظه جدا کنید، حداقل زندگی کنید، در برابر XSS محافظت کنید.

6. 8 CSRF

خط پایین: در طول جلسات کوکی، درخواست از یک سایت شخص ثالث.
حفاظت: SameSite، نشانه های ضد CSRF (دو بار ارسال)، بررسی منبع/ارجاع، فیلترهای Fetch-Metadata.

6. 9 سوء استفاده بیش از حد/اندازه

Gist: payload/headlines بزرگ، DoS در تجزیه.
حفاظت: عنوان/اندازه بدن محدودیت، اوایل رد 431/413، ثابت مجموعه ای از تمبر.

6. 10 تعویض «نوع »/« نوع»

ماهیت: سردرگمی انواع ("نوع:" JWT ")، اشیاء JOSE تودرتو.
حفاظت: نادیده گرفتن «نوع/cty» برای امنیت، تکیه بر الگوریتم های ثابت و طرح نام تجاری.

7) ذخیره و انتقال توکن

7. 1 API های سرور (ماشین به ماشین)

mTLS/HMAC، ترجیحا عدم تقارن برای JWT، کانال از طریق مش.
فروشگاه کلیدی - KMS/HSM، چرخش برنامه ریزی شده، با هم تداخل دارند JWKS.

7. 2 مشتریان مرورگر

HttpOnly کوکی امن для دسترسی/تازه کردن ؛ TTL کوتاه ؛ به روز رسانی - از طریق «تازه کردن سکوت» با 'SameSite = None' only تحت HTTPS.
CSP دقیق، انواع مورد اعتماد، محافظت در برابر XSS ؛ برای SPA - در صورت امکان، نشانه را روی دیسک ذخیره نکنید.

8) JWKS، چرخش و فراخوانی

JWKS توسط نویسنده منتشر شده است ؛ مصرف کنندگان کش برای 5-15 دقیقه.
طرح چرخش: اضافه کردن یک بچه → شروع آنها را امضا → پس از N روز حذف یکی از قدیمی از JWKS → پاکسازی.
بازخورد: لیست 'jti/sid' با TTL ؛ در صورت بروز حادثه، به طور موقت «exp» و force-logout را کاهش دهید (غیرفعال کردن تازه کردن).

9) چند مستاجر و به حداقل رساندن داده ها

فقط در صورت لزوم با معماری، «مستاجر »/« org» را در نشانه قرار دهید. در غیر این صورت، ویژگی ها را از PDP توسط «sub» بکشید.
بدون PII ؛ حداقل مجموعه تمبرها → خطر نشت و همبستگی کمتر.

10) چک لیست اعتبار عملی (سرور منابع)

• پارسیم تنها پس از تایید امضا و محدودیت اندازه اولیه.
• 'alg' از پیکربندی ؛ موارد غیر منتظره را رد کنید.
• بررسی 'iss' 'aud' 'exp' 'nbf' و 'iat' (با 'clock _ skew').
• «kid» را در دایرکتوری محلی/JWKS (TTL کوتاه) بررسی کنید.
• اشاره گرهای خارجی را فیلتر/نرمال کنید ('jku/x5u' - فقط لیست مجاز).
• محدود کردن طول تمبر/ترکیب (طرح).
• درخواست مجوز منابع شیء (BOLA-first).
• ورود «بچه»، «زیر»، «aud»، «iss»، «jti»، «exp»، «مستاجر»، «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'.
سیاهههای مربوط (ساختار): 'iss/aud/sub/kid/jti/exp/tenant/trace _ id'، دلیل شکست.
داشبورد: «به زودی منقضی می شود»، افزایش خطاهای اعتبار سنجی، توزیع بر اساس منطقه/مشتری.
هشدارها: رشد 'verify _ fail' (امضا/الگوریتم)، خطاهای JWKS، سهم توکن های منقضی شده.

13) ضد گلوله

اعتماد «alg» از نشانه ؛ حمایت از «هیچ»

نشانه های دسترسی طولانی مدت و بدون چرخش تازه.
HS256 با یک راز/راز کوتاه در ENV بدون KMS.
قبول 'jku/x5u' از هر دامنه ؛ JWKS را به صورت پویا بدون لیست مجاز بارگیری کنید.
PII/اسرار را در JWS بارگیری قرار دهید.
ذخیره نشانه ها در «ذخیره سازی محلی» زمانی که خطرات XSS وجود دارد.
سرکوب خطاهای اعتبارسنجی) 200 s «خطای نرم» را برگردانید (.
هیچ BOLA چک و تنها با تکیه بر «دامنه/نقش».

14) ویژگی های iGaming/امور مالی

مارک های: «kyc _ level»، «risk _ tier»، «tenant»، «aud» دقیق.
TTL کوتاه برای عملیات نوشتن (سپرده/خروجی)، PoP/DPoP یا mTLS برای مسیرهای بحرانی.
ممیزی نظارتی: سیاهههای مربوط غیر قابل تغییر از ورودی/شکست، ذخیره سازی سیاهههای مربوط در مرزهای منطقه است.
شرکا/PSP دارای کلید های جداگانه/« aud »، کلید های مستاجر و JWKS جداگانه هستند.

15) تولید لیست آمادگی

• Hard allow-list of algorithms; هیچ کس مجاز نیست.
• 'iss/aud/exp/nbf/iat/jti' بررسی می شوند ؛ «exp» کوتاه است.
• همپوشانی JWKS، کش TTL کوتاه ؛ نظارت بر سهام «کودک»
• تازه کردن - چرخش در استفاده ؛ 'jti/sid' lists with TTL; کتاب بازی را مرور کنید.
• PoP/DPoP یا mTLS در مسیرهای بحرانی.
• HttpOnly-cookies برای مرورگر، انواع CSP/Trusted در مقابل XSS ؛ حفاظت CSRF
• بدون PII در بار ؛ حداقل مجموعه ای از علائم.
• اعتبار سنجی و معیارهای شکست/سیاهههای مربوط; هشدار JWKS/verify_fail
• تست سناریو منفی: RS → مبادله HS، «بچه» -injections، «jku» spoofing، بزرگ، ساعت skew.

16) TL ؛ دکتر متخصص

ثابت الگوریتم و کلید در سمت سرور, اعتماد نمی 'ALG از نشانه, تقاضا' iss/aud/exp/nbf/iat/jti '. کلید ها را از طریق JWKS همپوشانی بچرخانید، نشانه ها را کوتاه مدت نگه دارید و یکبار مصرف را تازه کنید. توکنها را به طور ایمن ذخیره کنید (کوکی HttpOnly برای وب)، تمبرها را به حداقل برسانید، PII را قرار ندهید. بردارهای «jku/x5u/kid» را ببندید، از HS256 با اسرار ضعیف جلوگیری کنید، PoP/DPoP یا mTLS را در مسیرهای بحرانی اضافه کنید و همیشه چک های BOLA را در سطح منابع انجام دهید.