در مقاله باگ‌های پنهان دنیای باگ بانتی بخش سوم در مورد آسیب‌پذیری‌ OAuth Misbinding صحبت میکنیم که از دید افراد مخفی مانده.

باگ‌های OAuth خطرناک‌اند چون امن به نظر می‌رسند

HTTPS وجود دارد.

ورود با Google یا GitHub وجود دارد.

توکن‌ها، پارامتر State و Redirectها هم وجود دارند.

اما با این حال، تنها یک اشتباه منطقی می‌تواند OAuth را به یک تصاحب حساب (Account Takeover) خاموش تبدیل کند؛ جایی که:

• قربانی به‌صورت کاملاً عادی وارد حساب خود می‌شود.
• هیچ چیز «هک‌شده» به نظر نمی‌رسد.
• اما مهاجم همچنان به حساب دسترسی پیدا می‌کند.

در این مطلب، آسیب‌پذیری OAuth Misbinding را بررسی می‌کنیم؛ ضعفی که نه رمز عبور را سرقت می‌کند، نه توکن‌ها را حدس می‌زند و نه هشداری ایجاد می‌کند.

این حمله از اعتماد اشتباه میان هویت (Identity) و نشست کاربر (Session) سوءاستفاده می‌کند.

🧠 OAuth Misbinding چیست؟

OAuth Misbinding زمانی رخ می‌دهد که:

• یک Authorization Code یا Token مربوط به OAuth
• به‌درستی به نشست کاربری که فرایند ورود را آغاز کرده متصل (Bind) نشده باشد
• و برنامه آن را برای کاربر دیگری بپذیرد.

به زبان ساده:

• برنامه به ارائه‌دهنده OAuth اعتماد می‌کند.
• اما فراموش می‌کند بررسی کند که این توکن واقعاً متعلق به چه کاربری است.

و همین نقطه، منشأ آسیب‌پذیری است.

🎯 چرا این باگ بسیار خطرناک است؟

OAuth Misbinding می‌تواند منجر به موارد زیر شود:

• تصاحب کامل حساب (Full Account Takeover)
• جابه‌جایی نشست میان کاربران (Cross-User Session Swapping)
• نشت توکن‌ها (Token Leakage)
• دسترسی پایدار از طریق OAuth Refresh Token

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

 در بسیاری از موارد، خود قربانی ناخواسته فرایند ورود را تکمیل می‌کند.

 نه بدافزاری وجود دارد، نه فیشینگ و نه هیچ هشدار امنیتی.

به همین دلیل این آسیب‌پذیری معمولاً در سطح P1 دسته‌بندی می‌شود.

سناریوی واقعی سوءاستفاده (PoC Mindset)

برنامه تصور می‌کند: «ارائه‌دهنده OAuth این ورود را تأیید کرده است.»

اما هرگز این سؤال را نمی‌پرسد: «این تأیید برای کدام کاربر صادر شده است؟»

🧪 چگونه OAuth Misbinding را پیدا کنیم؟ (گام‌به‌گام)

مرحله ۱: نقاط ورود OAuth را شناسایی کنید

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

• Login with Google
• Continue with GitHub
• Sign in using SSO

اندپوینت‌های رایج:

/auth/google
/oauth/login
/login/oauth
/auth/callback

مرحله ۲: جریان OAuth را رهگیری کنید

با استفاده از Burp Suite موارد زیر را رهگیری کنید:

• درخواست Authorization در OAuth
• ریدایرکت به ارائه‌دهنده OAuth
• درخواست Callback

نمونه Callback:

/callback?code=AUTH_CODE&state=STATE_VALUE

مقادیر زیر را ذخیره کنید:

• code
• state

مرحله ۳: کد OAuth مهاجم را به دست آورید

1. با حساب مهاجم وارد شوید.
2. فرایند OAuth را کامل کنید.
3. مقدار code=ATTACKER_CODE را استخراج کنید.
4. اجازه ندهید کد منقضی شود.

این کد، ابزار حمله شماست.

مرحله ۴: کد را برای کاربر دیگری بازپخش (Replay) کنید

اکنون:

• از حساب خارج شوید
• یا مرورگر دیگری باز کنید
• یا با حساب قربانی وارد شوید

سپس درخواست زیر را ارسال کنید:

/callback?code=ATTACKER_CODE&state=VICTIM_STATE

🚨 اگر نشست قربانی این درخواست را بپذیرد، آسیب‌پذیری OAuth Misbinding تأیید شده است.

🧰 ابزارهایی که واقعاً نیاز دارید

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

• Burp Suite
• Proxy
• Repeater
• مرورگر با چند پروفایل
• curl (اختیاری)

برای کشف این آسیب‌پذیری به اتوماسیون نیاز ندارید.

درک صحیح منطق برنامه مهم‌تر از ابزارهاست.

🧪 Payloadها و تغییراتی که اهمیت دارند

1️⃣ تست استفاده مجدد از Code

/callback?code=SAME_CODE&state=NEW_STATE

Authorization Code باید:

• یک‌بارمصرف باشد
• به کاربر وابسته باشد
• به نشست کاربر متصل باشد

2️⃣ جابه‌جایی State

/callback?code=ATTACKER_CODE&state=RANDOM

اگر ورود همچنان موفق باشد، اتصال CSRF به‌درستی پیاده‌سازی نشده است.

3️⃣ حذف کامل State

/callback?code=ATTACKER_CODE

اگر درخواست پذیرفته شود، آسیب‌پذیری در سطح بحرانی (Critical) قرار دارد.

4️⃣ تست بین دستگاهی (Cross-Device)

• OAuth را روی موبایل آغاز کنید.
• آن را روی دسکتاپ تکمیل کنید.

اگر بدون هیچ بررسی اضافی پذیرفته شود، احتمالاً مکانیزم اتصال نشست ضعیف است.

🚩 نشانه‌هایی که نشان می‌دهد به یک باگ واقعی نزدیک شده‌اید

به موارد زیر توجه کنید:

• ورود حتی پس از Logout همچنان کار می‌کند.
• OAuth بدون کوکی معتبر کار می‌کند.
• یک Code چند بار قابل استفاده است.
• پارامتر State در سمت سرور اعتبارسنجی نمی‌شود.
• نشست کاربر پیش از تکمیل OAuth ایجاد می‌شود.

همه این موارد نشانه‌های هشداردهنده مهمی هستند.

🧨 چگونه این آسیب‌پذیری به P1 تبدیل می‌شود؟

OAuth Misbinding زمانی بسیار خطرناک می‌شود که:

• OAuth روش اصلی ورود کاربران باشد.
• توکن‌های OAuth برای دسترسی به API استفاده شوند.
• Refresh Tokenها به‌صورت ناامن ذخیره شوند.
• برنامه به‌صورت خودکار حساب‌های OAuth را لینک کند.

در این شرایط ممکن است پیامدهای زیر رخ دهد:

• دسترسی پایدار و طولانی‌مدت
• تصاحب کامل حساب
• جعل هویت کاربران دیگر

📝 نحوه گزارش آسیب‌پذیری

عنوان گزارش

OAuth Misbinding Allows Cross-User Account Takeover

تأثیر (Impact)

مهاجم می‌تواند با استفاده مجدد از یک OAuth Authorization Code معتبر، قربانی را به حسابی که تحت کنترل مهاجم است وارد کند.

به دلیل نبود اتصال صحیح میان توکن OAuth و نشست کاربری آغازکننده فرایند ورود، این ضعف منجر به تصاحب حساب بدون آگاهی قربانی می‌شود.

اهمیت آسیب‌پذیری

• مدل اعتماد SSO را نقض می‌کند.
• تمام کاربران OAuth را تحت تأثیر قرار می‌دهد.
• پس از کلیک اولیه، نیاز به تعامل بیشتری از سوی کاربر ندارد.

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

زیرا:

• OAuth در ظاهر بسیار امن به نظر می‌رسد.
• افراد بیش از حد به ارائه‌دهندگان OAuth اعتماد می‌کنند.
• جریان‌های OAuth پیچیده و گیج‌کننده هستند.
• بسیاری از شکارچیان باگ پس از مشاهده ورود موفق، بررسی را متوقف می‌کنند.

در حالی که آسیب‌پذیری‌های OAuth معمولاً در منطق برنامه نهفته‌اند، نه در خود اندپوینت‌ها.

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

دفعه بعد که با OAuth مواجه شدید:

• فقط CSRF را تست نکنید.
• فقط Redirectها را بررسی نکنید.
• حتماً اتصال هویت (Identity Binding) را آزمایش کنید.

زیرا معمولاً آسیب‌پذیری‌های ارزشمند دقیقاً در همین بخش پنهان شده‌اند.

🐾 قسمت بعدی این مجموعه

در مطلب بعدی بررسی خواهیم کرد:

 Race Conditions in Business Logic

اینکه چگونه ارسال هم‌زمان درخواست‌ها می‌تواند منطق مالی، اعتبارها، محدودیت‌ها و مکانیزم‌های کنترلی را دور بزند؛ همراه با نمونه‌های عملی و PoCهای واقعی.

با من همراه باشید