مقدمة

في تطبيقات الويب الحديثة، لا يعد الأمان مجرد ميزة إضافية، بل هو أحد أهم العناصر التي تشكل أساس النظام. من بين هذه العناصر، تعد XSS (Cross-Site Scripting) و CSRF (Cross-Site Request Forgery) ثغرات أمنية خطيرة لها تاريخ طويل ولا تزال تكتشف في العديد من تطبيقات الويب. غالبا ما يتم الخلط بينهما، لكن آلية الهجوم واستراتيجيات الدفاع ضدهما مختلفة جذريا.

في هذه المقالة، سنكشف عن الاختلافات الجوهرية بين XSS و CSRF، وكيف يستغل المهاجمون هذه الثغرات، وسنشرح بالتفصيل مع التطور التاريخي استراتيجيات الدفاع الحديثة التي يجب على المطورين تنفيذها.

1. العمق في XSS (Cross-Site Scripting)

XSS هي تقنية هجوم يقوم فيها المهاجم بحقن نصوص برمجية خبيثة (غالبا JavaScript) في صفحة ويب، ويجعل هذه النصوص تعمل في متصفحات المستخدمين الآخرين الذين يزورون تلك الصفحة. يكمن جوهر هذا الهجوم في “تفسير البيانات غير الموثوقة ككود قابل للتنفيذ دون الخضوع لمعالجة مناسبة”.

3 أنواع رئيسية لـ XSS

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

1. Stored XSS (XSS المخزن)

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

• أماكن الحدوث النموذجية: أقسام التعليقات، لوحات الرسائل، ملفات تعريف المستخدمين، ميزات المراجعة، وغيرها.
• التهديد: نطاق التأثير واسع جدا، وقد يقع جميع المستخدمين الذين يفتحون الصفحة ضحية له.

2. Reflected XSS (XSS المنعكس)

يحدث Reflected XSS عندما يتم إرسال نصوص برمجية خبيثة كجزء من الطلب (مثل معلمات URL أو بيانات النماذج) دون حفظها على الخادم، وتكون مضمنة كما هي “منعكسة” في استجابة الخادم.

• أماكن الحدوث النموذجية: صفحات نتائج البحث، عرض رسائل الخطأ، تمرير البيانات بين الخطوات، وغيرها.
• طريقة الهجوم: يكمل المهاجمون الهجوم عن طريق جعل المستخدمين ينقرون على عنوان URL يحتوي على معلمات خبيثة (باستخدام رسائل التصيد الاحتيالي أو وسائل التواصل الاجتماعي).

3. DOM-based XSS

يحدث XSS القائم على DOM عندما تعالج JavaScript على جانب العميل بيانات غير موثوقة عبر نقطة استقبال غير آمنة (sink). قد تكون البيانات مرت عبر الخادم أيضاً؛ فالعامل المحدد هو وقوع المعالجة غير الآمنة على جانب العميل.

• الآلية: يحدث عندما يقرأ JavaScript في التطبيق بيانات من مصادر يمكن للمهاجم التحكم فيها مثل window.location أو document.referrer ويمررها مباشرة إلى نقاط تنفيذ خطيرة (Sinks) مثل innerHTML أو eval().
• التهديد: غالبا ما لا يترك أثرا في سجلات الخادم، مما يجعل من الصعب اكتشافه بواسطة WAF (Web Application Firewall) وغيره.

الأضرار الناتجة عن XSS وأساليب تنفيذ النصوص داخل السياق

بمجرد نجاح XSS، يتم تنفيذ نصوص المهاجم في متصفح المستخدم بنفس الأصل (الصلاحية) مثل موقع الويب نفسه. يؤدي هذا إلى أضرار جسيمة كما يلي:

1. اختطاف الجلسة (Session Hijacking): إذا كانت Cookie المصادقة تفتقر إلى HttpOnly، فقد يسرق المهاجم معرف الجلسة عبر document.cookie. حتى مع HttpOnly، يمكن لـ XSS إرسال طلبات مصادق عليها باسم المستخدم.
2. تنفيذ عمليات غير مصرح بها: تنفيذ أي عملية في التطبيق (مثل تغيير كلمة المرور، تحويل الأموال، إرسال رسائل) في الخلفية بصلاحيات المستخدم.
3. التصيد الاحتيالي (Phishing): رسم نموذج تسجيل دخول مزيف على DOM لسرقة بيانات اعتماد المستخدم مباشرة.
4. توزيع البرامج الضارة: إعادة توجيه متصفح المستخدم إلى مجموعة استغلال (Exploit Kit) وإصابة جهاز الكمبيوتر ببرامج ضارة.

استراتيجيات الدفاع الحديثة ضد XSS

لمنع XSS، لا غنى عن نهج الدفاع المتعمق (Defense in Depth).

1. تهريب المحارف وفقاً للسياق (Output Encoding)

الإجراء الأساسي هو تهريب المحارف أو ترميز المخرجات (Output Encoding) لتحويل البيانات غير الموثوقة إلى نص آمن عند عرضها في صفحة الويب. يجب اختيار المعالجة المناسبة بحسب السياق: نص HTML أو سماته، أو JavaScript، أو CSS، أو URL. هذا ترميز للمخرجات وليس تشفيراً للبيانات. تُجري أطر مثل React وVue وAngular تهريب HTML افتراضياً، لكن ينبغي مراعاة مواضع الاستخدام غير الآمنة.

2. إدخال CSP (Content Security Policy)

CSP هو آلية دفاع قوية جدا ضد XSS، حيث يحدد قائمة بيضاء للموارد التي يسمح المتصفح بتحميلها وتنفيذها باستخدام ترويسة HTTP.

1

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com;

بفضل هذا، حتى لو تمكن المهاجم من حقن نص برمجي مضمن <script>alert(1)</script>، فسيتم حظر تنفيذه بواسطة CSP.

3. استخدام سمة HttpOnly للـ Cookie

من خلال إضافة سمة HttpOnly إلى الـ Cookie التي تخزن معرفات الجلسة وغيرها، لن تتمكن JavaScript (مثل document.cookie) من الوصول إلى تلك الـ Cookie. هذا لا يمنع حدوث XSS بحد ذاته، ولكنه إجراء تخفيف مهم يقلل بشكل كبير من خطر اختطاف الجلسة بسبب XSS.

2. جوهر CSRF (Cross-Site Request Forgery)

CSRF هو هجوم يوجه فيه المهاجم المستخدم إلى موقع فخ، ويجبره على إرسال طلب غير مقصود إلى موقع ويب آخر قام المستخدم بتسجيل الدخول إليه (مصدق عليه) بالفعل.

الفرق الحاسم هو أن XSS “يجعل المتصفح ينفذ نصوصا غير مصرح بها”، بينما CSRF “يستغل السلوك القياسي للمتصفح (الإرسال التلقائي للـ Cookie) لإرسال طلبات غير مصرح بها”.

آلية CSRF: استغلال “الإرسال التلقائي للـ Cookie”

يرفق المتصفح ملفات Cookie تلقائياً عند تحقق شروط إرسالها، وقد يشمل ذلك طلبات تثيرها صور أو نماذج على موقع آخر. لكن SameSite وSecure وDomain وPath وقيود المتصفح قد تمنع الإرسال.

سيناريو الهجوم:

يفترض هذا المثال التعليمي تطبيقاً ضعيف الحماية: تسمح Cookie المصادقة بالإرسال عبر المواقع باستخدام SameSite=None; Secure، ولا يجري التحقق من رمز CSRF أو من Origin. النطاقان bank.example وattacker.invalid محجوزان للأمثلة وينتميان إلى موقعين مختلفين.

1. يسجل المستخدم الدخول إلى موقع البنك (bank.example) ويتلقى Cookie الجلسة.
2. يتصفح المستخدم موقع فخ المهاجم (attacker.invalid) في علامة تبويب أخرى.
3. يحتوي موقع الفخ على نموذج مخفي ونص برمجي للإرسال التلقائي كما يلي:

   1 2 3 4 5

   <form action="https://bank.example/transfer" method="POST" id="csrf-form"> <input type="hidden" name="toAccount" value="ATTACKER_ACCOUNT"> <input type="hidden" name="amount" value="1000000"> </form> <script>document.getElementById('csrf-form').submit();</script>

4. يرسل المتصفح طلب POST إلى bank.example. في هذا الوقت، يتم إرفاق Cookie الجلسة لموقع البنك تلقائيا.
5. نظرا لأن الطلب يحتوي على Cookie الجلسة الشرعية، يعالجه خادم البنك كطلب من مستخدم شرعي، ويتم تنفيذ التحويل غير المصرح به.

التطور التاريخي وأحدث الممارسات للدفاع ضد CSRF

لمنع CSRF، من الضروري التحقق مما إذا كان الطلب “قد تم إرساله من الصفحة الشرعية المقصودة”.

1. رموز CSRF (Anti-CSRF Tokens): دفاع تقليدي وموثوق

أكثر تدابير الدفاع أمانا والمستخدمة على نطاق واسع منذ فترة طويلة هو رمز CSRF (نمط Synchronizer Token Pattern).

• يقوم الخادم بإنشاء رمز عشوائي غير متوقع لكل جلسة، ويحفظه على جانب الخادم (مثل داخل الجلسة).
• يتم تضمين هذا الرمز كحقل مخفي (hidden) في نموذج HTML المرسل إلى العميل.
• عند إرسال النموذج، يقارن الخادم الرمز المرسل مع الرمز المحفوظ على الخادم، ويعالج الطلب فقط إذا تطابقا. حتى لو تمكن المهاجم من إجبار المستخدم على إرسال طلب من موقع الفخ، فإنه لا يستطيع قراءة الصفحة المستهدفة للحصول على الرمز الصحيح (بسبب Same-Origin Policy)، وبالتالي يفشل الهجوم.

2. نمط Double Submit Cookie

إنها تقنية تستخدم غالبا في واجهات برمجة التطبيقات (APIs) التي لا تحتفظ بحالة (الجلسة) على جانب الخادم.

• يولد الخادم رمزا عشوائيا ويرسله إلى العميل كـ Cookie.
• تقرأ JavaScript الخاصة بالعميل قيمة تلك الـ Cookie، وتعينها في ترويسة الطلب (مثال: X-CSRF-Token) وترسلها.
• يتحقق الخادم مما إذا كانت قيمة الرمز في الـ Cookie تتطابق مع قيمة الرمز في الترويسة. تصف الخطوات أعلاه مقارنة بسيطة للقيم. لا يُنصح بالاعتماد عليها وحدها إذا استطاع المهاجم حقن ملفات Cookie. يُفضّل استخدام حماية إطار العمل المدمجة. عند استخدام Double Submit، يجب التحقق من رمز Signed Double Submit موثّق باستخدام HMAC وسر على الخادم، ومرتبط بجلسة المصادقة الحالية. كذلك ينبغي ألا تسمح واجهات API ذات الترويسات المخصصة بوصول CORS مع بيانات اعتماد لأصول غير موثوقة.

3. سمة SameSite للـ Cookie: دفاع قوي من المتصفحات الحديثة

تتحكم سمة SameSite في إرسال Cookie عبر المواقع، وهي طبقة دفاع. ينبغي في التطبيقات العامة دمجها مع رموز CSRF أو التحقق من Origin، بدلاً من اعتبارها بديلاً عنهما.

• SameSite=Strict: لن يتم إرسال الـ Cookie في أي طلب عبر المواقع، بما في ذلك التنقل في المستوى الأعلى مثل النقر فوق الروابط. إنه الخيار الأكثر أمانا، ولكنه قد يؤثر على تجربة المستخدم (UX)، مثل عدم الحفاظ على حالة تسجيل الدخول من الروابط الموجودة على مواقع أخرى.
• SameSite=Lax: لن يتم إرسال الـ Cookie للطلبات عبر المواقع مثل تحميل الصور أو طلبات POST، ولكن سيتم إرسالها للتنقل في المستوى الأعلى من خلال النقر فوق الروابط (طلبات GET). هذا هو السلوك الافتراضي الحالي للعديد من المتصفحات. يمكن لهذا منع معظم هجمات CSRF الناتجة عن إرسال نماذج POST الخبيثة.
• SameSite=None: تزيل قيد SameSite على الإرسال عبر المواقع وتتطلب Secure. تظل شروط إرسال Cookie الأخرى وقيود المتصفح سارية.

يميّز SameSite بين المواقع، لا بين الأصول (origins): قد تُعد النطاقات الفرعية الشقيقة لنطاق واحد قابل للتسجيل موقعاً واحداً. كما لا يحمي Lax نقطة نهاية تغيّر الحالة عبر GET. استخدم أساليب HTTP المناسبة لتغيير الحالة مع تحقق CSRF على الخادم. ولأن سلوك Lax الافتراضي قد يتضمن استثناءات، ينبغي ضبط سمات Cookie المطلوبة صراحةً.

العلاقة المتبادلة بين XSS و CSRF والخلاصة

يوضح المخطط التالي الفرق في مسار الهجوم.

  graph TD
    subgraph XSS Attack
        A["المهاجم"] -- "حقن نص برمجي خبيث" --> B["خادم الويب"]
        B -- "صفحة تحتوي على النص البرمجي" --> C["متصفح الضحية"]
        C -- "سرقة معرف الجلسة (دون HttpOnly)" --> A
    end

    subgraph CSRF Attack
        D["الضحية"] -- "تسجيل الدخول" --> E["خادم الويب"]
        D -- "تصفح" --> F["موقع فخ المهاجم"]
        F -- "طلب إجباري (مع Cookie)" --> E
    end

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

لذلك، لضمان أمان تطبيقات الويب، يلزم بناء أساس قوي من خلال احتواء XSS تماما أولا (عن طريق الهروب المناسب و CSP)، ثم تنفيذ إجراءات مكافحة CSRF (مثل SameSite Cookie ورموز CSRF).

من المهم للمطورين عدم الثقة المفرطة في ميزات الأمان التي توفرها أطر العمل، وفهم الآلية الجوهرية لهذه الثغرات، وتصميم الدفاعات في الطبقات المناسبة.

المراجع

• OWASP: XSS Prevention Cheat Sheet
• OWASP: CSRF Prevention Cheat Sheet