ثغرات OAuth وأنماط الهجوم

يجب على خوادم تفويض OAuth التحقق بدقة من معامل redirect_uri. فإذا سمح الخادم بالمطابقة حسب البادئة أو باستخدام أحرف البدل (مثل قبول أي عنوان URL يبدأ بـ "https://app.example.com")، يمكن للمهاجم إنشاء طلب تفويض يعيد التوجيه إلى "https://app.example.com.attacker.com/steal" أو إلى إعادة توجيه مفتوحة على النطاق الشرعي، وسرقة رمز التفويض.

من دون حماية من CSRF، يمكن للمهاجم بدء تدفق OAuth وخداع متصفح الضحية لإكمال التفويض. وبذلك يفوّض الضحية عميل المهاجم دون قصد. ويمنع معامل "state" (RFC 6749) ذلك: يُنشئ العميل state عشوائيًا، ويضمّنه في الطلب، ويتحقق من مطابقته في رد الاستدعاء. ويؤدي عدم التطابق إلى إيقاف التدفق.

على منصات الأجهزة المحمولة، يمكن للتطبيقات الخبيثة تسجيل مخطط URI مخصص مطابق للمخطط الذي يستخدمه عميل OAuth الشرعي، ثم اعتراض رموز التفويض التي يُعاد توجيهها بعد مصادقة المستخدم. ويُعد PKCE (RFC 7636) الحماية الكاملة: فالرمز المعترض لا يفيد من دون متحقق الرمز الذي أنشأه التطبيق الشرعي وحده في بداية التدفق.

عندما يُضمَّن رمز ID أو رمز وصول في جزء من عنوان URL أو في معامل استعلام، تتضمن عمليات التنقل اللاحقة من تلك الصفحة عنوان URL في ترويسة Referer، مما قد يؤدي إلى تسريب الرمز إلى نصوص تحليلات تابعة لجهات خارجية أو إلى موفري CDN. استخدم دائمًا تدفق رمز التفويض مع تسليم الرموز عبر القناة الخلفية لتجنب ظهور الرموز في عناوين URL.

عندما يدعم العميل عدة موفري OAuth، تخدع هجمات الخلط العميل لإرسال رمز تفويض تم الحصول عليه من الموفر A إلى نقطة نهاية الرموز الخاصة بالموفر B. ويجب على العميل التحقق من مطالبة "iss" في رموز ID، وربط رد الاستدعاء بالموفر المحدد الذي بدأ التدفق باستخدام معامل state أو JARM (JWT-Secured Authorization Response Mode).

تستهدف هجمات تزوير الطلبات من جانب الخادم (SSRF) تطبيقات OAuth التي تُجري طلبات HTTP من جانب الخادم إلى redirect_uri. فإذا جلب خادم التفويض redirect_uri للتحقق منه، يمكن للمهاجم تزويده بعنوان IP داخلي (مثل http://169.254.169.254/latest/meta-data/) للوصول إلى البيانات الوصفية لمثيل سحابي أو إلى خدمات داخلية. ويمنع التحقق من redirect_uri بالاعتماد على قائمة سماح صارمة ذلك.

تستخدم تطبيقات كثيرة مطالبة البريد الإلكتروني من رمز ID في OIDC لربط الحسابات بين الموفّرين. فإذا كان المهاجم يسيطر على عنوان بريد إلكتروني يطابق حساب الضحية لدى موفر آخر، فيمكنه التسجيل لدى موفر مختلف باستخدام ذلك البريد والوصول إلى حساب الضحية. والحماية هي ربط الحسابات باستخدام الزوج (iss, sub) فقط، وليس البريد الإلكتروني وحده مطلقًا.

تستغل هجمات التباس خوارزمية JWT التطبيقات التي تثق بترويسة "alg" لاختيار خوارزمية التحقق. وتتمثل الهجمة في تغيير "alg" من "RS256" إلى "HS256" وتوقيع الرمز باستخدام المفتاح العام للخادم باعتباره سر HMAC (بما أن المفتاح العام متاح للجميع). وتتمثل الحماية في تحديد الخوارزمية المتوقعة صراحةً في شفرة التحقق، وعدم الوثوق مطلقًا بمطالبة alg في ترويسة الرمز.

يسجل المهاجمون عملاء OAuth خبيثين بأسماء وشعارات تبدو شرعية، ثم يرسلون روابط تصيد إلى المستهدفين. وترى الضحية شاشة موافقة OAuth حقيقية (تستضيفها Google أو Microsoft وغيرهما) لتطبيق خبيث، فتمنحه الوصول. وتتمثل الحماية في التحقق من أن client_id يعود إلى التطبيق المتوقع؛ إذ توفر Google وMicrosoft برامج للتحقق من العملاء للتطبيقات الشرعية.

يحدث تصعيد النطاق عندما يحصل العميل على رموز ذات أذونات أوسع من تلك التي فوّضها المستخدم. ويمكن لعيوب التنفيذ، مثل تخطي التحقق من النطاق في نقطة نهاية الرموز، أو تخزين الرموز مؤقتًا مع دمج النطاقات من طلبات مختلفة، أو عدم التحقق من أن النطاق في الرمز المُصدر لا يتجاوز النطاق المفوَّض، أن تؤدي جميعًا إلى تصعيد الامتيازات عبر OAuth.

احمِ تطبيقات OAuth من خلال: استخدام التحقق بالمطابقة التامة لـ redirect_uri، وفرض PKCE على جميع العملاء العامين، والتحقق من معامل state للحماية من CSRF، وربط رموز ID باستخدام (iss, sub) وليس البريد الإلكتروني، وتحديد خوارزميات JWT المتوقعة صراحةً، وطلب الحد الأدنى من النطاقات، واستخدام رموز وصول قصيرة العمر مع تدوير رموز التحديث، ومراجعة مظهر شاشة الموافقة للتقليل من مخاطر انتحال العلامة التجارية.

يقبل خادم تفويض OAuth أي redirect_uri يبدأ بـ "https://app.example.com". ما الهجوم الذي يتيحه ذلك؟

هجمات OAuth الرئيسية: إعادة التوجيه المفتوحة بسبب التحقق المتساهل من redirect_uri (استخدم المطابقة التامة)، وCSRF بسبب غياب معامل state، واعتراض الرموز على الأجهزة المحمولة (يخففه PKCE)، وتسريب الرموز في عناوين URL، وهجمات الخلط في إعدادات متعددة الموفّرين (تحقق من iss)، وهجمات SSRF عبر redirect_uri الذي يجلبه الخادم، وتعارض مطالبة البريد الإلكتروني (استخدم iss+sub)، والتباس خوارزمية JWT (ثبّت alg المتوقعة)، والتصيد الاحتيالي عبر شاشات الموافقة المزيفة.