‏حمله‌های OAuth: وقتی MFA دیگه جلوی هکر رو نمی‌گیره

تیم Unit 42 تو این گزارش می‌گه با همه‌گیر شدن MFA (یعنی ورود با رمز به‌علاوه‌ی یه کد یا تأیید دوم)، مهاجم‌ها رفتن سراغ دزدیدن توکن‌های OAuth. OAuth همون پروتکلیه که پشت دکمه‌ی «ورود با Google» هست و به یه اپ دیگه اجازه می‌ده بدون رمز، از طرف تو به داده‌هات دسترسی داشته باشه. چون این حمله بعد از ورود و تأیید هویت اتفاق می‌افته، قربانی خودش MFA رو کامل می‌کنه و مهاجم فقط توکن رو برمی‌داره.

مشکل اصلی اینه که توکن‌ها عملاً از رمز عمر بیشتری دارن. خیلی وقت‌ها طولانی‌مدت تنظیم می‌شن، با ریست رمز باطل نمی‌شن، و refresh token (یعنی توکنی که بی‌صدا توکن دسترسی جدید می‌سازه) می‌تونه روزها یا ماه‌ها دسترسی رو زنده نگه داره. یه تحقیق بزرگ هم نشون داده ۱۸.۵۳ درصد سایت‌هایی که OAuth دارن، بیشتر از حداقل لازم دسترسی می‌خوان.

گزارش چند ضعف رو هم اسم می‌بره که این ماندگاری بدترشون می‌کنه. تو COSF مهاجم یه اتصال OAuth (مثلاً «Slack رو وصل کن») رو تو اپ هدف شروع می‌کنه، نیمه‌کاره نگهش می‌داره و لینکش رو برای قربانی می‌فرسته؛ قربانی وارد حساب واقعی خودش می‌شه ولی توکن تو حساب مهاجم می‌نشینه. دو ضعف دیگه هم مخصوص سرویس‌هایی‌ان که توکن‌های صدها اپ رو تو یه انبار مشترک نگه می‌دارن و یه اپ مخرب می‌تونه خودش رو جای اپ معتبر جا بزنه.

نویسنده‌ها حمله‌های فیشینگ OAuth رو سه دسته می‌کنن. ربودن حساب: مثلاً سوءاستفاده از device authorization (همون جریانی که تلویزیون هوشمند یه کد نشون می‌ده و تو تو گوشی واردش می‌کنی)؛ اینجا کد رو سرور مهاجم گرفته و قربانی با وارد کردنش تو صفحه‌ی واقعی مایکروسافت، نشست مهاجم رو تأیید می‌کنه. ربودن مجوز: قربانی روی صفحه‌ی رضایت، به یه اپ با اسم مبهم مثل Security App یا اسم یه برند معروف، Allow می‌زنه. هدایت مخرب: از اعتماد کاربر به دامنه‌ی واقعی ارائه‌دهنده‌ی هویت استفاده می‌شه تا آخر کار به سایت مهاجم فرستاده بشه.

یه نمونه‌ی زیرکانه‌ش رو مایکروسافت مارس ۲۰۲۶ گزارش کرده بود: مهاجم لینکی می‌سازه که عمداً خطا بده، مثلاً prompt=none رو کنار پارامترهایی می‌ذاره که تعامل کاربر لازم دارن. ارائه‌دهنده به جای صفحه‌ی خطا، کاربر رو خودکار به آدرس بازگشتی که مهاجم ثبت کرده می‌فرسته. گزارش می‌گه کیت‌های آماده‌ی فیشینگ (PhaaS) با کد رمزنگاری‌شده و تشخیص ابزار امنیتی، و صفحه‌های ساخته‌شده با LLM، این حمله‌ها رو سریع‌تر و باورپذیرتر کردن. اضافه شدن OAuth به پلتفرم‌هایی مثل Cloudflare هم یعنی یه توکن دزدیده‌شده می‌تونه به DNS و ترافیک سایت دسترسی بده.

برای دفاع، گزارش پیشنهاد می‌ده رضایت دادن کاربرها به اپ‌های جانبی بسته بشه و همه چی از مسیر تأیید ادمین رد بشه. اپ‌هایی با اسم مبهم یا جعلی خودکار مسدود بشن، کپی و پیست کدهای مجوز از منبع نامعتبر زیر نظر باشه، و همه‌ی آدرس‌های بازگشت اپ‌ها (یعنی جایی که کاربر بعد از ورود فرستاده می‌شه) مدام بررسی بشن که به دامنه‌ی تأییدشده برن. نویسنده‌ها معتقدن باید حمله رو تو مرورگر و لحظه‌ی صدور مجوز دید، نه بعدش.

نکات کلیدی:

• توکن OAuth بعد از MFA صادر می‌شه، پس MFA جلوش رو نمی‌گیره و ریست رمز هم باطلش نمی‌کنه
• ۱۸.۵۳ درصد سایت‌های دارای OAuth بیشتر از پروفایل و ایمیل دسترسی می‌خوان
• سه دسته حمله: ربودن حساب، ربودن مجوز با صفحه‌ی رضایت، و هدایت مخرب
• مایکروسافت مارس ۲۰۲۶ کمپینی رو گزارش کرد که با خطای عمدی OAuth کاربر رو به سایت مهاجم می‌فرستاد
• دفاع اصلی: فقط تأیید ادمین برای اپ‌ها، مسدود کردن اسم‌های مبهم و بررسی مداوم آدرس‌های بازگشت