التكوين الخاطئ CORS: مخاطر السياسات المفرطة في التساهل

التأثير

يمكن للمهاجم سرقة البيانات الحساسة والموثقة من مستخدمي التطبيق الضعيف [S2]. إذا قام أحد المستخدمين بزيارة موقع ويب ضار أثناء تسجيل الدخول إلى التطبيق الضعيف، فيمكن للموقع الضار تقديم طلبات مشتركة المصدر إلى API الخاص بالتطبيق وقراءة الردود [S1][S2]. يمكن أن يؤدي ذلك إلى سرقة المعلومات الخاصة، بما في ذلك ملفات تعريف المستخدمين أو رموز CSRF أو الرسائل الخاصة [S2].

السبب الجذري

CORS هي آلية تعتمد على رأس HTTP تسمح للخوادم بتحديد الأصول (المجال أو المخطط أو المنفذ) المسموح لها بتحميل موارد [S1]. تنشأ الثغرات الأمنية عادةً عندما تكون سياسة CORS الخاصة بالخادم مرنة جدًا أو يتم تنفيذها بشكل سيئ [S2]:

• Reflected Origin Header: تقرأ بعض الخوادم رأس Origin من طلب العميل وتكررها مرة أخرى في رأس الاستجابة Access-Control-Allow-Origin (ACAO) [S2]. يسمح هذا بشكل فعال لأي موقع ويب بالوصول إلى المورد [S2].
• أحرف البدل التي تم تكوينها بشكل خاطئ: بينما يسمح حرف البدل * لأي أصل بالوصول إلى أحد الموارد، إلا أنه لا يمكن استخدامه للطلبات التي تتطلب بيانات اعتماد (مثل ملفات تعريف الارتباط أو رؤوس التفويض) [S3]. غالبًا ما يحاول المطورون تجاوز ذلك عن طريق إنشاء رأس ACAO ديناميكيًا بناءً على الطلب [S2].
• الإدراج 'خالية': تقوم بعض التطبيقات بإدراج أصل null في القائمة البيضاء، والذي يمكن تشغيله عن طريق الطلبات المعاد توجيهها أو الملفات المحلية، مما يسمح للمواقع الضارة بالتنكر كأصل null للوصول إلى [S2][S3].
• أخطاء التحليل: يمكن أن تسمح الأخطاء في التعبير العادي أو مطابقة السلسلة عند التحقق من صحة رأس Origin للمهاجمين باستخدام نطاقات مثل trusted-domain.com.attacker.com [S2].

من المهم ملاحظة أن CORS لا يمثل حماية ضد تزوير الطلبات عبر المواقع (CSRF) [S2].

الإصلاحات الخرسانية

• استخدام القائمة البيضاء الثابتة: تجنب إنشاء رأس Access-Control-Allow-Origin ديناميكيًا من رأس Origin الخاص بالطلب. بدلاً من ذلك، قارن أصل الطلب بقائمة مضمنة من المجالات الموثوقة [S3].
• تجنب الأصل "الخالي": لا تقم مطلقًا بتضمين null في القائمة البيضاء للأصول المسموح بها [S2].
• تقييد بيانات الاعتماد: قم بتعيين Access-Control-Allow-Credentials: true فقط إذا كان ذلك ضروريًا للغاية للتفاعل المحدد عبر الأصل [S3].
• استخدام التحقق المناسب: إذا كان يجب عليك دعم أصول متعددة، فتأكد من أن منطق التحقق من الصحة لرأس Origin قوي ولا يمكن تجاوزه بواسطة النطاقات الفرعية أو النطاقات المشابهة [S2].

كيفية اختبار FixVibe لذلك

يتضمن FixVibe هذا الآن كفحص نشط مسور. بعد التحقق من النطاق، يرسل active.cors طلبات API من نفس المصدر مع أصل مهاجم اصطناعي ويراجع رؤوس استجابة CORS. لقد عكست التقارير الأصول التعسفية، وأحرف البدل المعتمدة CORS، وCORS المفتوحة على نطاق واسع على نقاط نهاية API غير العامة مع تجنب ضجيج الأصول العامة.