باگ‌های پنهان دنیای باگ بانتی بخش ششم

در مقاله باگ‌های پنهان دنیای باگ بانتی بخش ششم در مورد jwt algorithm confusion صحبت میکنیم که از دید افراد مخفی مانده.

«امضاشده است، پس حتماً امن است.»

دقیقاً همین چیزی است که مهاجمان روی آن حساب می‌کنند.

سردرگمی الگوریتم JWT (JWT Algorithm Confusion) درباره شکستن رمزنگاری نیست. بلکه درباره وادار کردن سرور به این است که توکن را به روش اشتباه اعتبارسنجی کند و با خوشحالی یک توکن جعلی را بپذیرد.

بدون بروت‌فورس. بدون لو رفتن کلیدهای محرمانه. فقط سوءاستفاده از اعتماد به پیکربندی.

🧠 سردرگمی الگوریتم JWT واقعاً چیست؟

JWT از سه بخش تشکیل شده است:

HEADER.PAYLOAD.SIGNATURE

هدر (Header) شامل فیلدی به نام alg است، مانند:

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

سردرگمی الگوریتم زمانی اتفاق می‌افتد که:

• سرور به مقدار alg موجود در توکن اعتماد کند.
• و از نوع کلید اشتباه برای اعتبارسنجی آن استفاده کند.

به زبان ساده:

سرور به مهاجم اجازه می‌دهد انتخاب کند که توکن چگونه اعتبارسنجی شود.

این همان باگ است.

🎯 چرا این باگ بحرانی است؟

JWT Algorithm Confusion می‌تواند منجر به موارد زیر شود:

• دور زدن کامل احراز هویت
• تصاحب حساب کاربری
• جعل هویت مدیر (Admin)
• دسترسی به API بدون داشتن اعتبارنامه

و بدترین بخش ماجرا؟

 توکن کاملاً معتبر به نظر می‌رسد.  اعتبارسنجی امضا همچنان «موفق» می‌شود.  لاگ‌ها یک احراز هویت کاملاً عادی را نشان می‌دهند.

به همین دلیل این باگ اغلب به عنوان P1 / P0 طبقه‌بندی می‌شود.

📹 روند واقعی اکسپلویت (طرز فکر PoC)

Application

   |

   | انتظار دریافت JWT امضاشده با RS256 را دارد

   | (جفت کلید عمومی / خصوصی)

   ↓

Attacker

   |

   | الگوریتم را از RS256 به HS256 تغییر می‌دهد

   | و از کلید عمومی به عنوان HMAC Secret استفاده می‌کند

   ↓

Server

   |

   | ❌ توکن را با منطق اشتباه اعتبارسنجی می‌کند

   ↓

💥 توکن پذیرفته می‌شود → مهاجم احراز هویت می‌شود

هیچ رمزنگاری‌ای شکسته نشده است. فقط از منطق سیستم سوءاستفاده شده است.

🧪 کجا باید به دنبال JWT Algorithm Confusion بگردید؟

این باگ معمولاً در جاهایی دیده می‌شود که:

• JWT برای احراز هویت استفاده می‌شود.
• اعتبارسنجی توکن در سمت سرور انجام می‌شود.
• چندین الگوریتم پشتیبانی می‌شوند (یا پیکربندی اشتباه است).

اهداف پرریسک

• APIها (Authorization: Bearer <JWT>)
• بک‌اندهای موبایل
• پنل‌های مدیریت
• میکروسرویس‌ها
• ابزارهای داخلی یا SSO

اگر JWT از هر چیز ارزشمندی محافظت می‌کند، آن را تست کنید.

🧪 چگونه JWT Algorithm Confusion را پیدا کنیم (مرحله‌به‌مرحله)

مرحله ۱: یک JWT معتبر را دریافت کنید.

به‌صورت عادی وارد حساب شوید و توکن را از یکی از این موارد بردارید:

• هدر Authorization
• کوکی‌ها
• Local Storage

مثال:

Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

مرحله ۲: JWT را Decode کنید.

از ابزارهای زیر استفاده کنید:

• jwt.io (در حالت آفلاین)
• jwt_tool

هدر را بررسی کنید:

{
  "alg": "RS256"
}

این نشان می‌دهد که سرور انتظار چه الگوریتمی را دارد.

مرحله ۳: کلید عمومی (Public Key) را به دست آورید. (مرحله حیاتی)

به دنبال موارد زیر باشید:

• /.well-known/jwks.json
• تنظیمات OpenID
• گواهی‌های عمومی
• پیکربندی‌های اپلیکیشن موبایل

مسیرهای رایج:

/.well-known/jwks.json
/.well-known/openid-configuration

اگر کلید عمومی در دسترس باشد پس به کشف باگ بسیار نزدیک شده‌اید.

مرحله ۴: الگوریتم را تغییر دهید. (تست اصلی)

هدر JWT را به این صورت تغییر دهید:

{
  "alg": "HS256"
}

حالا:

• کلید عمومی را به عنوان HMAC Secret در نظر بگیرید.
• توکن را با HS256 امضا کنید.

اگر سرور آن را بپذیرد → 💥 سردرگمی الگوریتم تأیید شده است.

🧰 ابزارهایی که واقعاً استفاده خواهید کرد

🔧 ابزارهای اصلی

• jwt_tool
• CyberChef
• Burp Suite (Repeater)
• curl

نیازی به اسکنر یا فازینگ نیست.

درک مفهوم در اینجا از ابزارها مهم‌تر است.

🧪 دستورات و Payloadهای واقعی

استفاده از jwt_tool

python3 jwt_tool.py TOKEN \
  -X k \
  -pk public.pem \
  -I

یا به‌صورت دستی ایجاد کنید:

۱- هدر:

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

۲- payload (نقش یا شناسه کاربر را تغییر دهید):

{
  "user": "admin",
  "role": "admin"
}

۳- امضا با:

HMAC secret = PUBLIC KEY

🚩 نشانه‌های قوی که یک باگ واقعی پیدا کرده‌اید

به دنبال این موارد باشید:

• توکن پس از تغییر الگوریتم پذیرفته می‌شود.
• هیچ خطای اعتبارسنجی امضا وجود ندارد.
• دسترسی به Endpointهای محافظت‌شده امکان‌پذیر است.
• ارتقای سطح دسترسی (Role Escalation) موفق است.
• پاسخ‌های API کاملاً عادی به نظر می‌رسند.

اگر برنامه هیچ اعتراضی نکند، برای آن‌ها خبر بدی است.

🧨 چگونه این را به یک P1 / P0 تبدیل کنید؟

JWT Algorithm Confusion زمانی بحرانی می‌شود که:

• JWT برای احراز هویت اصلی استفاده شود.
• نقش‌ها یا مجوزها داخل توکن قرار داشته باشند.
• زمان انقضای توکن طولانی باشد.
• در چندین سرویس استفاده شود.

موارد زیر را نشان دهید:

• توکن جعلی
• دسترسی بدون ورود معتبر
• موفقیت در انجام عملیات سطح بالا

این یعنی فروپاشی کامل اعتماد.

📝 نحوه گزارش این باگ (آماده برای گزارش)

عنوان

JWT Algorithm Confusion امکان دور زدن احراز هویت را فراهم می‌کند.

تأثیر

یک مهاجم می‌تواند با تغییر الگوریتم امضا از RS256 به HS256 و استفاده از کلید عمومی به عنوان HMAC Secret، JWTهای معتبر جعل کند. این موضوع منجر به دور زدن کامل احراز هویت و دسترسی غیرمجاز به منابع محافظت‌شده می‌شود.

 

چرا این موضوع اهمیت دارد؟

• اعتماد رمزنگاری را از بین می‌برد.
• تمام سیستم‌های احراز هویت مبتنی بر توکن را تحت تأثیر قرار می‌دهد.
• منجر به تصاحب حساب کاربری می‌شود.

🧠 چرا بیشتر هانترها این باگ را از دست می‌دهند؟

چون:

• JWT امن به نظر می‌رسد.
• رمزنگاری برای بسیاری ترسناک است.
• به کتابخانه‌ها کورکورانه اعتماد می‌کنند.
• پیکربندی را تست نمی‌کنند.

اما این یک باگ رمزنگاری نیست. بلکه یک باگ منطقی (Logic Bug) است.

🚀 بعد از خواندن این مطلب چه کاری باید انجام دهید؟

هر بار که با JWT روبه‌رو شدید:

• آن را Decode کنید.
• الگوریتم را بررسی کنید.
• به دنبال کلیدهای عمومی بگردید.
• تست Algorithm Confusion را انجام دهید.

همین یک تست می‌تواند به کشف باگ‌هایی با تأثیر بسیار بالا منجر شود.

ادامه این مجموعه

مقاله بعدی:

👉 دور زدن احراز هویت در WebSocket (WebSocket Authorization Bypass)
اینکه چگونه برنامه‌های Real-Time احراز هویت را فراموش می‌کنند و باعث نشت داده‌های زنده می‌شوند.