أليس CSRF مشكلة أمنية في المتصفح؟
https://stackoverflow.com/questions/224049
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
فيما يتعلق بهجمات تزوير طلب المواقع المشتركة (CSRF)، إذا كانت ملفات تعريف الارتباط هي أكثر طرق المصادقة استخدامًا، فلماذا تسمح متصفحات الويب بإرسال ملفات تعريف الارتباط الخاصة ببعض النطاقات (وإلى هذا المجال) من صفحة تم إنشاؤها من مجال آخر؟
ألا يمكن منع CSRF بسهولة في المتصفح عن طريق عدم السماح بمثل هذا السلوك؟
بقدر ما أعرف، لا يتم تنفيذ هذا النوع من الفحص الأمني في متصفحات الويب، لكنني لا أفهم السبب.هل حصلت على شيء خاطئ؟
حول CSRF:
يحرر:أعتقد أنه لا ينبغي إرسال ملفات تعريف الارتباط على http POST في الحالة المذكورة أعلاه.هذا هو سلوك المتصفح الذي يفاجئني.
المحلول
لماذا لا يرسل المتصفح ملفات تعريف الارتباط؟
الموقع أ (http://www.sitea.com) يقوم بتعيين ملف تعريف الارتباط للمستخدم.
ينتقل المستخدم إلى الموقع ب (http://www.siteb.com).يتميز الموقع "ب" بالتكامل مع الموقع "أ" - انقر هنا للقيام بشيء ما في الموقع "أ"!ينقر المستخدمون على "هنا".
بقدر ما يمكن للمتصفح أن يخبرنا، يتخذ المستخدم قرارًا واعيًا بتقديم طلب إلى الموقع "أ"، لذا فهو يتعامل معه بنفس الطريقة التي يتعامل بها مع أي طلب إلى الموقع "أ"، وهذا يتضمن إرسال ملفات تعريف الارتباط للموقع "أ" في الطلب إلى الموقع أ.
يحرر:أعتقد أن المشكلة الرئيسية هنا هي أنك تعتقد أن هناك فرقًا بين ملفات تعريف الارتباط للمصادقة وملفات تعريف الارتباط الأخرى.يمكن استخدام ملفات تعريف الارتباط لتخزين أي شيء - تفضيلات المستخدم، أو آخر أعلى نتيجة لك، أو رمز الجلسة.ليس لدى المتصفح أي فكرة عن الغرض من استخدام كل ملف تعريف ارتباط.أنا يريد يجب أن تكون ملفات تعريف الارتباط الخاصة بي متاحة دائمًا للموقع الذي قام بتعيينها، وأريد أن يتأكد الموقع من أنه يتخذ الاحتياطات اللازمة.
أم أنك تقول أنه إذا بحثت في ياهو عن "gmail"، ثم نقرت على الرابط الذي ينقلك إليه http://mail.google.com, ، لا ينبغي عليك تسجيل الدخول، حتى لو طلبت من Gmail أن يبقيك مسجلاً للدخول, ، لأنك نقرت على الرابط من موقع آخر؟
نصائح أخرى
لا يعني ذلك أن المتصفح يرسل ملف تعريف الارتباط إلى أو من نطاق خارجي، بل إنه تمت مصادقتك وأن الموقع لا يتحقق من صحة مصدر الطلب، لذلك فهو يعامله كما لو أن الطلب جاء من موقع.
وبقدر ما إذا كان المتصفح يجب أن لا يسمح بذلك ...ماذا عن المواقف العديدة التي تكون فيها الطلبات عبر المواقع مرغوبة؟
يحرر:للتوضيح، لا يتم إرسال ملف تعريف الارتباط الخاص بك عبر النطاقات.
لا أعلم أن هناك الكثير الذي يمكن للمتصفح فعله في هذا الموقف نظرًا لأن الهدف من هجوم XSRF هو توجيه المتصفح إلى نقطة أخرى في التطبيق من شأنها أن تؤدي شيئًا سيئًا.لسوء الحظ، ليس لدى المتصفح أي فكرة عما إذا كان الطلب الذي يتم توجيهه لإرساله ضارًا أم لا.على سبيل المثال، بالنظر إلى المثال الكلاسيكي لـ XSRF:
<img src="http://domain.com/do_something_bad" />
ليس من الواضح للمتصفح أن هناك شيئًا سيئًا يحدث.وبعد كل شيء، كيف يمكن معرفة الفرق بين هذا وهذا:
<img src="http://domain.com/show_picture_if_authenticated" />
تحتوي الكثير من البروتوكولات القديمة على ثغرات أمنية كبيرة - فكر في ما تم اكتشافه مؤخرًا نقاط ضعف DNS.كما هو الحال في أي أمان للشبكة، تقع مسؤولية النقاط النهائية على عاتقها؛نعم، من المؤسف أن يتعين علينا إصلاح هذه المشكلة بأنفسنا، ولكن إصلاحها على مستوى المتصفح أصعب كثيرًا.هناك بعض الحالات الواضحة (<img src="logoff.php"> تبدو مريبة للغاية، أليس كذلك؟)، ولكن ستكون هناك دائمًا حالات هامشية.(ربما يكون برنامج نصي GD في ملف PHP بعد كل شيء.) ماذا عن استعلامات AJAX؟وما إلى ذلك وهلم جرا...
لا يتم إرسال ملفات تعريف الارتباط الخاصة بموقع ما إلى موقع آخر أبدًا.في الواقع، لتنفيذ هجوم CSRF ناجح، لا يحتاج المهاجم إلى الوصول إلى ملفات تعريف الارتباط هذه.
في الأساس، يخدع المهاجم المستخدم، الذي قام بالفعل بتسجيل الدخول إلى موقع الويب المستهدف، للنقر على رابط أو تحميل صورة من شأنها أن تفعل شيئًا ما على الموقع المستهدف باستخدام بيانات اعتماد ذلك المستخدم.
أي أن المستخدم يقوم بتنفيذ الإجراء، وقد خدع المهاجم المستخدم للقيام بذلك.
قال بعض الأشخاص إنهم لا يعتقدون أن المتصفح يمكنه فعل الكثير.
انظر الى هذا:
http://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html
إنها نظرة عامة على اقتراح لرأس HTTP جديد للمساعدة في تخفيف هجمات CSRF.
اسم الرأس المقترح هو "Origin" وهو في الأساس رأس "Referer" مطروحًا منه المسار، وما إلى ذلك.
