هجوم تزوير الطلبات عبر المواقع CSRF: ما هو وكيف تحمي تطبيقك منه؟

ما هو هجوم CSRF؟

يُعد هجوم Cross-Site Request Forgery، ويُختصر إلى CSRF، من الهجمات الشائعة على تطبيقات الويب. يحدث هذا النوع عندما ينجح موقع خبيث أو برنامج ضار في دفع متصفح المستخدم إلى تنفيذ إجراء غير مرغوب فيه داخل موقع موثوق، وذلك بينما يكون المستخدم مسجّل الدخول بالفعل.

تكمن خطورة هذا الهجوم في أن الموقع المستهدف يعتقد أن الطلب صادر بإرادة المستخدم، لأن المتصفح يرسل بيانات الجلسة تلقائيًا، مثل Session Cookies. وبهذا يمكن للمهاجم استغلال صلاحيات الضحية لتنفيذ عمليات حساسة مثل تغيير كلمة المرور أو تحويل الأموال أو تعديل البريد الإلكتروني.

على سبيل المثال، قد تكون مستخدمة مثل “جين” قد سجّلت الدخول إلى حسابها البنكي عبر الإنترنت، ثم فتحت رسالة بريد إلكتروني تحتوي على رابط تصيّد. عند النقر على الرابط، قد يُرسل المتصفح طلبًا إلى موقع البنك لتحويل مبلغ إلى حساب يتحكم فيه المهاجم. وبما أن جلسة “جين” ما تزال فعّالة، فقد يتعامل البنك مع الطلب على أنه طلب شرعي.

فهم أساسيات HTTP وملفات تعريف الارتباط

طلب HTTP GET

يُستخدم طلب GET لجلب البيانات من الخادم. فعند كتابة عنوان موقع في المتصفح، يتم غالبًا إرسال طلب GET لتحميل الصفحة أو الموارد المرتبطة بها.

طلب HTTP POST

يُستخدم طلب POST لإرسال البيانات إلى الخادم، مثل إرسال نموذج تسجيل أو تحديث بيانات حساب.

ومن المهم الانتباه إلى أن بعض طلبات GET وPOST قد تُنفذ تلقائيًا دون تفاعل مباشر من المستخدم، مثل تحميل الصور عبر الخاصية img src أو جلب اقتراحات البحث في الخلفية.

ما دور Session Cookies؟

بروتوكول HTTP لا يحتفظ بحالة المستخدم بشكل افتراضي، لذلك تعتمد المواقع على Session Cookies للحفاظ على الجلسة. يحتوي هذا النوع من الملفات على معرّف فريد يمكّن الخادم من التعرّف إلى المستخدم في كل طلب لاحق.

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

كيف يعمل هجوم CSRF؟

لكي ينجح هجوم CSRF، غالبًا ما تتوافر الشروط التالية:

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

يمكن أن يؤثر هذا الهجوم في تطبيقات الويب التي تعتمد على Cookies أو مصادقة المتصفح أو الشهادات الرقمية على جهة العميل. وبعبارة أوضح، أي نظام يضيف بيانات اعتماد المستخدم تلقائيًا إلى الطلبات قد يكون عرضة لهذا النوع من الاستغلال.

هل يعتمد الهجوم على GET أم POST؟

يمكن تنفيذ هجوم CSRF باستخدام طلب GET أو POST. ومع أن تزوير طلبات POST أكثر تعقيدًا نسبيًا، فإنه يظل ممكنًا. النقطة المشتركة في الحالتين هي خداع الضحية لدفع متصفحها إلى تحميل الطلب أو إرساله إلى التطبيق المستهدف.

وقد يحدث ذلك بوسائل متعددة، منها:

• رابط تصيّد مخفي أو مختصر.
• صفحة ويب خبيثة تُحمّل موردًا تلقائيًا.
• ثغرة مخزنة داخل التطبيق نفسه شبيهة بمفهوم XSS في بعض السيناريوهات.

ما هو Stored CSRF؟

يظهر Stored CSRF عندما يتمكن المهاجم من حفظ الحمولة الهجومية داخل حقل يقبل شيفرات HTML، مثل وسم IMG أو IFRAME. وعند زيارة المستخدمين لتلك الصفحة، قد تُنفذ الطلبات الخبيثة تلقائيًا دون علمهم.

وقد يأتي الهجوم في هيئة رابط عادي داخل الصفحة مثل:

<a href="malicious link">Unsubscribe here</a>

أو يُخفى داخل صورة غير مرئية مثل:

<img src="malicious link" width="0" height="0" border="0">

مثال عملي يوضح هجوم CSRF

لنفترض أن موقع البنك bank.com يعالج التحويلات المالية باستخدام طلبات GET تتضمن اسم المستلم والمبلغ. إذا أراد المستخدم “جيم” إرسال 10 دولارات إلى “بوب”، فقد يكون الطلب بالشكل التالي:

http://bank.com/transfer?recipient=Bob&amount=10

في هذا السيناريو، يتضمن الطلب أيضًا ملف جلسة يعرّف صاحب الحساب، حتى يعرف البنك من أي رصيد سيُخصم المبلغ.

الآن، إذا أقنع المهاجم “جيم” بالنقر على رابط مُخفى أو مختصر، فقد يكون الرابط الحقيقي كما يلي:

http://bank.com/transfer?recipient=Hacker&amount=100000

وبما أن “جيم” مسجّل الدخول بالفعل، سيرسل المتصفح ملف الجلسة تلقائيًا مع الطلب، وسيتعامل البنك مع العملية على أنها تعليمات صادرة من صاحب الحساب نفسه.

كيف تمنع هجمات CSRF؟

1) اختر الأطر البرمجية بعناية

بعض الأطر الحديثة توفر وسائل حماية مدمجة ضد CSRF، مثل .NET وغيرها من الأطر الشائعة. لكن وجود الحماية وحده لا يكفي؛ إذ يجب ضبط الإعدادات بشكل صحيح والتأكد من تفعيل الآليات المناسبة في النماذج والواجهات الحساسة.

إذا كان الإطار المستخدم لا يقدم حماية أصلية، فمن الضروري إضافة وسائل دفاع مخصصة، وعلى رأسها Anti-CSRF Tokens.

2) استخدم Anti-CSRF Tokens

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

أفضل الممارسات عند استخدام هذه الرموز تشمل:

• أن يكون الرمز عشوائيًا وغير قابل للتوقع.
• أن تكون مدة صلاحيته قصيرة.
• ألا يُعاد استخدامه بشكل غير آمن.
• أن يُرسل غالبًا في حقل مخفي داخل النموذج أو في ترويسة مخصصة.
• ألا يُوضع داخل طلب GET حتى لا يظهر في URL أو يتسرب عبر ترويسة Referrer.

كما يُفضّل التحقق من الرمز بطريقة آمنة، مثل المقارنة الآمنة أو مقارنة القيم بعد معالجتها بأسلوب يمنع الاستدلال على بنيتها.

3) فعّل الخاصية SameSite في ملفات الارتباط

تسمح الخاصية SameSite بتقييد إرسال ملفات الارتباط بحيث لا تُرسل إلا في الطلبات القادمة من نفس النطاق أو وفق سياسة محددة. هذا يعني أن الطلبات العابرة للمواقع لن تتمكن غالبًا من تمرير ملف الجلسة كما يحدث في سيناريوهات CSRF.

على سبيل المثال، إذا أراد الموقع www.bank.com إرسال طلب إلى www.bank.com/updatepassword، فذلك مسموح. لكن إذا حاول موقع خبيث مثل www.maliciousdomain.com إرسال طلب إلى www.bank.com/updatepassword، فلن يتمكن عادة من تمرير ملف الجلسة بالطريقة نفسها عند ضبط SameSite بصورة صحيحة.

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

4) طبّق مبدأ الدفاع متعدد الطبقات

الحماية القوية لا تعتمد على إجراء واحد فقط. من الأفضل الجمع بين عدة ضوابط أمنية بحيث تعزز كل واحدة الأخرى. من الأمثلة المفيدة:

• التحقق من مصدر الطلب عبر الترويسات القياسية للتأكد من أن جهة الإرسال والوجهة متطابقتان.
• استخدام ترويسة طلب مخصصة Custom Request Header بحيث يرفض الخادم الطلبات التي لا تتضمنها.
• اعتماد أسلوب Double Submit Cookies بإضافة قيمة عشوائية ثانية يجب أن تتطابق مع قيمة أخرى متوقعة على الخادم.

5) أشرك المستخدم في العمليات الحساسة

عند التعامل مع إجراءات عالية الخطورة، مثل تحويل الأموال أو تغيير كلمة المرور، يُنصح بإضافة طبقة تحقق إضافية تتطلب تفاعلًا مباشرًا من المستخدم، مثل:

• CAPTCHA
• رموز استخدام لمرة واحدة
• إعادة تسجيل الدخول
• تأكيد العملية عبر عامل مصادقة إضافي

هذا النوع من الإجراءات يقلل احتمال نجاح الطلبات المزوّرة حتى لو تمكّن المهاجم من إرسالها.

إجراءات يظن البعض أنها مفيدة لكنها غير كافية

الاعتماد على المعاملات متعددة الخطوات

زيادة عدد الخطوات لا تمنع الهجوم إذا كان المهاجم قادرًا على توقّع كل مرحلة أو إعادة بنائها برمجيًا.

استخدام HTTPS فقط

تأمين الاتصال عبر HTTPS مهم جدًا لحماية البيانات أثناء النقل، لكنه لا يمنع هجمات CSRF بحد ذاته.

إعادة كتابة URL

قد يظن البعض أن وضع معرّف الجلسة داخل الرابط حل مفيد، لكنه يفتح الباب لمخاطر أخرى، مثل كشف المعرّف في السجل أو الروابط أو الإحالات. لذلك فهو استبدال لمشكلة بأخرى.

الاعتماد على ملف ارتباط سري فقط

حتى لو كان ملف الارتباط سريًا، فإن المتصفح يرسله تلقائيًا مع الطلب. لذلك يمكن للمهاجم الاستفادة منه ما دام التطبيق لا يملك آلية تحقق إضافية.

قبول طلبات POST فقط

حظر GET للعمليات الحساسة خطوة جيدة من ناحية التصميم، لكنها لا تمنع CSRF وحدها، لأن الطلبات المزوّرة من نوع POST ما تزال ممكنة.

أسماء أخرى لهجوم CSRF

قد يظهر هذا الهجوم بأسماء متعددة في المراجع الأمنية، منها:

• XSRF
• Sea Surf
• Session Riding
• Cross-Site Reference Forgery
• Hostile Linking
• One-Click Attack

أفضل الممارسات لتقوية أمان تطبيقات الويب

1. عدم تنفيذ العمليات الحساسة عبر طلبات GET.
2. تفعيل CSRF Tokens في جميع النماذج والواجهات الحرجة.
3. ضبط SameSite وSecure وHttpOnly لملفات الارتباط بحسب الحاجة.
4. التحقق من المصدر والوجهة عبر الترويسات المناسبة.
5. إضافة تحقق إضافي للعمليات المالية أو الإدارية الحساسة.
6. اختبار التطبيق دوريًا لاكتشاف مسارات يمكن استغلالها عبر الطلبات المزوّرة.

الخلاصة التقنية

هجوم CSRF لا يستهدف كسر كلمة المرور أو سرقة الجلسة مباشرة، بل يستغل ثقة التطبيق في متصفح المستخدم بعد المصادقة. لذلك فإن الحماية الفعالة تعتمد على منع الطلبات غير الموثوقة من أن تبدو شرعية، عبر الجمع بين Anti-CSRF Tokens وخصائص SameSite والتحقق من المصدر وإضافة تفاعل بشري عند الإجراءات الحساسة. من الناحية العملية، أقوى دفاع ضد CSRF هو التصميم الأمني المسبق، لا المعالجة المتأخرة بعد ظهور الثغرة.