تزوير الطلبات عبر المواقع (CSRF)

لماذا يهم

ينفّذ CSRF الناجح تغييراً للبيانات أو إجراءً باسم الضحية: فتغيير البريد أو كلمة المرور قد يؤدي إلى الاستيلاء على الحساب، وقد تُحوَّل الأموال أو تتبدّل الإعدادات دون موافقة. والمستخدم لم يفعل شيئاً خاطئاً ولا يرى شيئاً، ما يجعل اكتشاف الأمر لاحقاً صعباً.

تنجح هذه العيوب في اجتياز كل اختبار وظيفي، لأن الرحلة المعتادة تعمل. ولا تظهر إلا في اختبارات مكتوبة لها، وهي اختبارات رخيصة: طلب ملتقَط، وحساب اختبار، وأداة لإعادة إرساله. واكتشاف رمز مفقود أو غير مفحوص قبل الإصدار يسدّ طريقاً إلى الاستيلاء على الحسابات لا يستطيع المستخدمون حماية أنفسهم منه.

كيف يعمل الطلب المزوَّر

يحتاج CSRF إلى اجتماع ثلاثة أمور. الأول: إجراء يغيّر الحالة، مثل تغيير البريد أو تحويل مال أو حذف بيانات. الثاني: إدارة جلسة تعتمد على بيانات اعتماد يرسلها المتصفح من تلقاء نفسه، فلا تحتاج صفحة المهاجم إلى معرفتها. الثالث: معاملات طلب يستطيع المهاجم توقّعها؛ فإذا كانت كل قيمة في الطلب قابلة للتخمين، أمكن للصفحة بناء الطلب مسبقاً.

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

• النموذج المخفي الذي يرسل POST تلقائياً هو الحامل الكلاسيكي؛ وقد يحمل عنصر <img> أو رابطٌ طلب GET.
• لا يحتاج المهاجم إلى XSS ولا إلى سكربت على الهدف: يستغلّ CSRF سلوك المتصفح نفسه، وهذا ما يميّزه عن البرمجة النصية عبر المواقع (XSS) في الدرس السابق.
• ولأن المهاجم لا يستطيع قراءة الاستجابة، فإن CSRF يفرض إجراءً ولا يسرق بيانات — وهذا التمييز يحدّد شكل كل اختبار.

الدفاعات الثلاثة: الرموز وSameSite والأصل

الدفاع الأساسي التقليدي هو رمز مكافحة التزوير (anti-CSRF token): قيمة لا يمكن توقّعها يربطها الخادم بجلسة المستخدم ويضعها في نماذج كل صفحة. فالنموذج الحقيقي يعيدها، والصفحة الخارجية لا تستطيع قراءتها فلا تستطيع تضمينها. ونمط الرمز المتزامن (synchronizer token) يحفظ القيمة المتوقَّعة في الخادم؛ ونمط الإرسال المزدوج (double-submit) يرسلها في ملف تعريف ارتباط وفي الطلب معاً ويقارنهما، فلا يحتاج إلى حالة في الخادم لكن يجب أن يستعمل قيمة يوقّعها الخادم ويربطها بالجلسة، حتى لا يستطيع مهاجمٌ تمكّن من زرع ملف تعريف ارتباط أن يصنع زوجاً متطابقاً. وفي الحالتين يجب أن يرفض الخادم الطلب عند غياب الرمز أو خطئه — فالرمز الموجود دون فحص لا يحمي شيئاً.

وسمة SameSite على ملف تعريف ارتباط الجلسة هي الطبقة الثانية. فالقيمة Strict أو Lax تمنع المتصفح من إرفاق ملف تعريف الارتباط بمعظم الطلبات التي تبدأ من موقع آخر، ما يوقف النموذج المزوَّر البسيط. عاملها دفاعاً في العمق (defence in depth) لا بديلاً عن الرموز: فـLax ما زالت ترسل ملف تعريف الارتباط في التنقل على المستوى الأعلى بطريقة GET من موقع آخر، وتختلف القيم الافتراضية بين المتصفحات، ولهذا يتوقّع درس ملفات تعريف الارتباط والجلسات في HTTP أن تُضبط السمة صراحةً.

والطبقة الثالثة هي ترويسة Origin، مع Referer بديلاً: عند طلب يغيّر الحالة يتأكد الخادم أن الأصل أصله هو. فالمتصفحات تضيف Origin إلى الطلبات عبر الأصول ولا تستطيع الصفحة تغييرها، فعدم التطابق سبب قوي للرفض؛ لكن الترويسة قد تغيب أو تأتي بالقيمة null، فعلى الخادم أن يقرّر ما يحدث عندئذ أيضاً. وتضع ورقة OWASP المرجعية لمنع تزوير الطلبات هذا الفحص، مثل SameSite، ضمن الدفاع في العمق. وترسل المتصفحات الحالية أيضاً Sec-Fetch-Site (مثل cross-site)، ويقبلها OWASP فحصاً رئيسياً للمتصفحات الحديثة حين تكون Origin هي البديل الاحتياطي. ولا شيء من هذا هو CORS التي تحكم ما يُسمح للصفحة بقراءته: فإرسال نموذج بسيط من موقع آخر يصل إلى الخادم أياً كانت ترويسات CORS، ولهذا قال درس CORS إنها ليست دفاعاً ضد CSRF.

جرّبها: محلّل ملفات تعريف الارتباط (Cookies)

مثال تطبيقي: اختبار إجراء تغيير البريد

خذ تطبيقاً تجريبياً تملكه أو لديك إذن مكتوب باختباره. سجّل الدخول بحساب اختبار والتقط الطلب الذي يغيّر بريد الحساب، بوكيل اعتراضي (intercepting proxy) كما في درس الوكيل الاعتراضي، أو من أدوات المطوّر في المتصفح. والطلب الملتقَط أدناه يحمل ملف تعريف ارتباط جلسة ورمزاً.

الآن أعِد إرساله مع تغيير شيء واحد في كل مرة، بميزة إعادة الإرسال في الوكيل أو بإعادة بنائه في أداة REST API Tester أو في أمر cURL، وراقب الاستجابة والبريد المخزَّن. كل إعادة إرسال حالة اختبار بنتيجة متوقَّعة واضحة. وإعادة الإرسال تختبر ما يفحصه الخادم، ولا تُظهر ما كان المتصفح سيرسله، ولهذا تُفحص SameSite على حدة في ترويسة Set-Cookie.

• احذف X-CSRF-Token وأعِد الإرسال: توقّع رفضاً (مثل 403) وبقاء البريد دون تغيير. فإن نجح، فلا فحص للرمز في الإجراء.
• استبدل بالرمز رمزاً صالحاً من جلسة حساب اختبار ثانٍ وأعِد الإرسال: توقّع الرفض. فإن نجح، فالرمز غير مرتبط بالجلسة.
• أبقِ الرمز الصالح، وغيّر Origin إلى موقع آخر وأعِد الإرسال: الرفض يُظهر أن الخادم يفحص الأصل أيضاً؛ والقبول يعني أن الرمز هو الطبقة الوحيدة، فتسجّله ملاحظةً لا نتيجةً فاشلة.
• الصق ترويسة Set-Cookie من تسجيل الدخول في أداة Cookie Analyzer، وتأكّد أن ملف تعريف ارتباط الجلسة يضبط SameSite صراحةً.
• ابحث عن أي إجراء يمكن بلوغه عبر GET ويغيّر الحالة: فذلك عيب بذاته، لأن SameSite=Lax ترسل ملف تعريف الارتباط عند اتباع رابط.

POST /account/email HTTP/1.1
Host: app.example
Origin: https://app.example
Cookie: sid=9f8aUq0Zr8Ty2Nc6
X-CSRF-Token: 7bQ2mK9rLp4XwZ1
Content-Type: application/x-www-form-urlencoded

email=sara%40app.example

جرّبها: مختبِر REST API جرّبها: مولّد أوامر cURL جرّبها: فاحص ترويسات الطلب

اختبار CSRF قابل للتكرار في كل إصدار

وسّع المثال التطبيقي إلى قائمة فحص. اكتب كل طلب يغيّر الحالة في الميزة؛ وسجّل لكلٍّ: هل يُشترط رمز، وهل يتعذّر توقّعه وهل هو مرتبط بالجلسة، وهل يفحصه الخادم، وهل يُتحقَّق من Origin أو Referer. ويجب أن ينتقل الرمز في جسم الطلب أو في ترويسة، لا في سلسلة الاستعلام (query string) حيث يتسرّب عبر ترويسة Referer وسجلّات الخادم ومحفوظات المتصفح.

انتبه للفحوص التي تجري فقط في JavaScript الصفحة نفسها، إذ لا يمرّ بها الطلب المزوَّر أبداً، وللرموز التي تُعاد دون فحص، ولنقاط النهاية (endpoints) التي تستقبل GET وتغيّر الحالة خفيةً. فمعيار RFC 9110 يعرّف GET طريقةً آمنة (safe method) دلالتها في جوهرها قراءة فقط، لذا فتغيير الحالة خلف GET عيب حتى قبل النظر في CSRF. وسجّل الطلب بالضبط وما غيّرته والاستجابة، ليعيد المطوّر إنتاج النتيجة بخطوة واحدة.

جرّبها: محلّل ترويسات HTTP

أسئلة شائعة

المراجع

• OWASP Cheat Sheet Series: Cross-Site Request Forgery PreventionOWASP Foundationدفاعات CSRF: رموز المزامنة وملفات تعريف الارتباط SameSite وفحص المصدر.
• OWASP Web Security Testing Guide (WSTG)OWASP Foundationالمنهجية المرجعية لاختبار تطبيقات الويب وواجهات API بحثاً عن نقاط الضعف الأمنية، اختباراً تلو الآخر.
• Using HTTP cookies — MDNMDN Web Docs (Mozilla)عمر ملف تعريف الارتباط ونطاقه وسمات Secure/HttpOnly/SameSite وآثارها الأمنية.
• RFC 9110: HTTP SemanticsIETF · 2022معاني أساليب HTTP وحقول الترويسات ورموز الحالة والتفاوض على المحتوى، بغضّ النظر عن إصدار البروتوكول.