ما هو CSRF وكيف تحمي تطبيقك من هجماته؟
الكاتب: فريق تحرير Domeny.ForSale تاريخ النشر
باختصار: CSRF هجوم يدفع فيه موقع خارجي متصفح مستخدم مسجّل الدخول إلى إرسال طلب غير مرغوب فيه إلى موقع آخر. إذا كان الموقع المستهدف يكتفي بالتحقق من تسجيل دخول المستخدم، فقد ينفّذ العملية دون موافقته الواعية. وتعتمد الحماية أساسًا على تدابير داخل التطبيق: رموز CSRF، والإعدادات المناسبة لملفات تعريف الارتباط، والتحقق من مصدر الطلبات.
كيف يعمل CSRF — مثال من لوحة إدارة متجر
CSRF اختصار لـ Cross-Site Request Forgery، أي تزوير الطلبات عبر المواقع. يستغل الهجوم إمكانية إرفاق المتصفح ملف تعريف ارتباط الجلسة تلقائيًا بالطلبات الموجّهة إلى موقع معين. ويتيح هذا الملف للخادم التعرّف على المستخدم المسجّل دخوله دون مطالبته بكلمة المرور مجددًا.
تخيّل أنك تدير متجرًا إلكترونيًا، ولوحة الإدارة مفتوحة أمامك. تزور في علامة تبويب أخرى صفحة أعدّها المهاجم. تحاول هذه الصفحة إرسال طلب إلى لوحة الإدارة لتغيير عنوان البريد الإلكتروني المرتبط بحسابك.
إذا أرفق المتصفح ملف تعريف ارتباط الجلسة، ولم تتحقق لوحة الإدارة أيضًا من أصالة الطلب، فقد يتعامل الخادم معه بوصفه قرارًا صادرًا عنك. لا يحتاج المهاجم إلى معرفة كلمة المرور أو قراءة ملف تعريف الارتباط؛ يكفي أن يستخدمه المتصفح عند إرسال الطلب.
يشبه ذلك أن يقدّم شخص ما أمرًا للتنفيذ ممهورًا بختمك الذي يُرفق تلقائيًا. يتعرّف النظام على الختم، لكنه لا يتحقق مما إذا كنت تريد فعلًا تنفيذ تلك العملية بعينها.
متى قد ينجح الهجوم، وما الذي لا يمنعه؟
يتطلب هجوم CSRF المعتاد توافر عدة شروط: أن تكون للمستخدم جلسة نشطة، وأن يرسل المتصفح بيانات المصادقة تلقائيًا، وأن يقبل التطبيق طلبًا يمكن توقّع بنيته ويغيّر حالة الحساب. قد يتعلق الأمر بتغيير بيانات، أو إضافة مستخدم، أو حذف سجل. وتتوقف العواقب على العمليات المتاحة وصلاحيات الضحية.
لا يحتاج المهاجم عادةً إلى قراءة استجابة الخادم. قد يمنع المتصفح الصفحة الخارجية من قراءة بيانات لوحة الإدارة، لكن إرسال بعض الطلبات يظل ممكنًا. لذلك، فإن سياسة المصدر الواحد، التي تقيّد وصول السكربتات إلى موارد من مصادر أخرى، لا تغني عن الحماية من CSRF.
كذلك لا يحل HTTPS هذه المشكلة. فهو يشفّر الاتصال ويحمي البيانات أثناء انتقالها، لكنه لا يؤكد أن المستخدم طلب تنفيذ العملية عن وعي. ولا يكفي أيضًا استخدام طريقة POST بدلًا من GET، إذ يمكن لصفحة خارجية إرسال نموذج POST عادي.
يختلف CSRF عن XSS. يقوم XSS على تشغيل شيفرة غير مرغوب فيها ضمن سياق موقع موثوق، بينما يستغل CSRF ثقة الموقع بالطلبات الواردة من متصفح المستخدم. لكن ثغرة XSS قد تقوّض وسائل الحماية من CSRF، كأن تتيح قراءة الرمز مثلًا.
كيف تحمي التطبيق من CSRF؟
أكثر نقاط البداية أمانًا هي الحماية المدمجة في إطار العمل الذي تستخدمه. يجب تفعيلها والتأكد من أنها تشمل جميع العمليات التي تغيّر البيانات، لا نموذج تسجيل الدخول وحده.
- تحقّق من رمز CSRF. هو قيمة لا يمكن توقّعها، يضعها التطبيق في النموذج أو يوفّرها لإرسالها ضمن ترويسة مناسبة. يتحقق الخادم منها قبل تنفيذ العملية. وفي أحد الأساليب الشائعة، يرتبط الرمز بالجلسة؛ ويجب ألا تتمكن صفحة خارجية من قراءته أو تخمينه. ينبغي ألا يُدرج الرمز في عنوان URL.
- اضبط السمة SameSite لملف تعريف ارتباط الجلسة. تحدّ هذه السمة من إرسال الملف في السياقات التي تتضمن مواقع مختلفة. يوفّر الخياران Lax وStrict مستويين مختلفين من القيود، لذا يجب اختبار الخيار المختار مع تسجيل الدخول وعمليات التكامل. تمثّل SameSite طبقة حماية، وليست بديلًا عن الرمز في جميع الحالات.
- تحقّق من مصدر الطلب. تساعد ترويسة Origin، وكذلك Referer ضمن آلية مصممة على نحو مناسب، في تحديد مصدر الطلب. قارِن المصدر بعناوين مسموح بها ومحددة بدقة، بدلًا من الاكتفاء بالبحث عن جزء من اسم النطاق.
- لا تغيّر البيانات عبر GET. ينبغي ألا يؤدي فتح رابط إلى حذف حساب أو تأكيد طلب شراء. يجب أن تستخدم العمليات التي تغيّر البيانات الطرق المناسبة، وأن تظل خاضعة للتحقق من CSRF.
للعمليات شديدة الحساسية، أضف إعادة المصادقة أو خطوة تأكيد منفصلة. وينبغي أيضًا ضبط السمتين Secure وHttpOnly على نحو مناسب لملفات تعريف ارتباط الجلسة، مع أن أيًا منهما لا يمنع CSRF بمفرده.
هل تحتاج API أيضًا إلى الحماية؟
قد تكون API، وهي واجهة للتواصل بين البرامج، عرضة لهجمات CSRF أيضًا إذا كانت تعتمد على جلسة تجري المصادقة عليها بواسطة ملف تعريف ارتباط. فمجرد إرسال الاستجابة بصيغة JSON لا يضمن الأمان.
عندما يضيف العميل رمز الوصول صراحةً في ترويسة Authorization، ولا يرفقه المتصفح تلقائيًا، فإن آلية CSRF المعتادة لا تنطبق غالبًا. لكن هذا لا يعني الحماية من سرقة الرمز أو من XSS. كذلك فإن CORS، وهي آلية تنظّم الوصول بين المصادر المختلفة، ليست وسيلة مستقلة للحماية من CSRF.
ما الذي ينبغي فحصه في موقعك؟
ابدأ بعملية واحدة، مثل تغيير عنوان البريد الإلكتروني. باستخدام حساب اختباري، وفي بيئتك الخاصة أو بموافقة المالك، تحقّق من رفض الطلب الذي لا يحتوي على رمز CSRF أو يحتوي على رمز غير صحيح، ومن أنه لا يغيّر البيانات فعلًا. ثم راجع إعدادات ملف تعريف الارتباط والمسارات الأخرى التي تنفّذ العملية نفسها.
إذا كنت تستخدم نظامًا جاهزًا، فتحقّق من كيفية عمل الحماية بالرجوع إلى الوثائق الرسمية للإصدار المستخدم والإضافات المثبّتة. بصفتك مستخدمًا، لا يمكنك معالجة غياب وسائل الحماية على الخادم؛ لكن يمكنك تقليل المخاطر بتسجيل الخروج بعد الانتهاء من العمل في لوحة تتيح عمليات حساسة. أما بصفتك مالك التطبيق، فابدأ بمراجعة العمليات التي تغيّر البيانات، فهي التي تتطلب التحقق من أن الطلب صادر فعلًا عن واجهة مخوّلة.
اقرأ أيضًا
