شرح XSS: أنواعه، مخاطره، وطرق الحماية العملية

إيه هي XSS ببساطة؟ ​

XSS أو Cross Site Scripting هي ثغرة بتخلّي حد يحقن سكريبت (غالبًا JavaScript) في صفحات موقعك، ولما الزائر يفتح الصفحة السكريبت ده بيتنفّذ على متصفحه. يعني موقعك بيتحوّل لأداة يهاجم بيها الزوّار بدل ما يكون ضحية لوحده.

مين اللي بيتأثر في هجمة XSS؟ ​

• الزائر: اللي السكريبت بيتنفّذ على متصفحه وبيسرق داتا زي الكوكيز أو بيخطف الجلسة.
• الموقع: الموقع بيتبوّأ سمعة وحسب ومحركات البحث ممكن تحذفه أو تحطه في الـblacklist.
• صاحب الموقع: لازم يتحمّل مسؤولية إصلاح الثغرة وحماية المستخدمين.

إزاي XSS بتشتغل على مستوى بسيط؟ ​

المخترق يبعَت قيمة فيها سكريبت بدل ما يبعت نص عادي - لو موقعك عرض القيمة دي من غير تعقيم (escape) أو فلترة، المتصفح هيشغّلها. مهم: هنا مش هانعرض بايلودات أو أمثلة اختراق - أمثلة حماية آمنة عشان المطورين يطبقوها.

أنواع XSS باختصار (مش تفاصيل هجومية) ​

• Stored XSS (Persistent): السكريبت بيتخزّن في الداتابيز أو التعليقات وبعدين بيتنفّذ لكل اللي يفتح الصفحة.
• Reflected XSS (Non-persistent): السكريبت بيروح ويرجع فورًا كجزء من الرابط أو الطلب، وغالبًا يتوزّع عن طريق رابط مغلوط.
• DOM-based XSS: المشكلة هنا في التعامل مع الـDOM على جهة العميل (الـbrowser) - الكود الجاڤا سكريبت نفسه بيتعامل مع قيم من الـURL أو الصفحة بطريقة خالية من الحماية.

ليه XSS خطر؟ ​

• يسرق كوكيز الجلسة (لو مش محميين بـHttpOnly).
• يعمل phishing داخل صفحتك عن طريق تغيير الـDOM أو إضافة فورمات مزيفة.
• يسجّل ضحايا (keylogging) أو يبعَت بياناتهم لسيرفر المهاجم.

ازاي تحمي موقعك من XSS - خطوات عملية ومباشرة ​

منع التنفيذ عن طريق التهيئة الصحيحة (Output Encoding)​

أهم قاعدة: كل قيمة جاية من المستخدم لازم تتعقم قبل ما تعرضها. لو بتستخدم PHP مثلاً:

<?php
// قيمة جاية من الداتابيز أو من فورم
$comment = $row['comment'];
// عرض آمن
echo htmlspecialchars($comment, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
?>

ده بيمنع أي HTML أو سكريبت من التنفيذ لأننا بنحوّل الأحرف الخاصة لصيغ آمنة.

في الجافاسكريبت استخدم innerText مش innerHTML لما تقدر​

لو بتحط نص من اليوزر على الصفحة:

// غير آمن:
// someElement.innerHTML = userInput;

// آمن:
someElement.innerText = userInput;

innerText بتعامل النص كنص بسيط مش كـHTML فمتخليش المتصفح يشغّل اي حاجة جواها.

حط سياسات أمان صارمة (Content Security Policy)​

CSP بتقلّل المخاطر حتى لو في قيمة محقونة. مثال هيدر بسيط:

Content-Security-Policy: default-src 'self'; script-src 'self' https://apis.example.com; object-src 'none'; frame-ancestors 'none';

ده يمنع تشغيل سكريبتات من مصادر غير موثوقة وبيقلل فرص الـinline scripts.

خلي الكوكيز بتاعت الـSession محمية​

Set-Cookie: sessionid=abc123; HttpOnly; Secure; SameSite=Strict

HttpOnly يمنع الجافاسكريبت من قراءة الكوكيز، وSecure يخليها تمشي بس على HTTPS، وSameSite يساعد في تقليل هجمات CSRF.

فلترة المدخلات وتطبيق مبدأ الأقل صلاحية​

• اعمل validation بالـserver (مش بس بالـclient).
• لو الحقل لازم يكون رقم، استقبل أرقام بس.
• خليك محافظ في أي مكان بتسمح بإدخال HTML (مثلاً محرّر نص غني) - استخدم مكتبات تنظيف مثل DOMPurify لو فعلاً عايز تسمح ببعض الـHTML الآمن.

رصد وتنبيه ولوجات​

راقب أي محاولات مش طبيعية، وسجّل محاولات الوصول والـinputs الغريبة علشان تقدر ترد بسرعة.

أمثلة كود لتنضيف HTML آمن على جهة العميل (DOMPurify)​

لو محتاج تسمح ببعض HTML الآمن للمستخدمين (زي محتوى من محرّر WYSIWYG)، استخدم مكتبة موثوقة بدل كتابة فلترة بنفسك:

<script src="https://unpkg.com/dompurify@latest/dist/purify.min.js"></script>
<script>
  const dirty = '<img src=x onerror=alert(1)> <b>نص آمن</b>';
  const clean = DOMPurify.sanitize(dirty);
  document.getElementById('content').innerHTML = clean;
</script>

DOMPurify بتنضف الـHTML وتحط قواعد تمنع الأحداث الخبيثة.

خلاصة سريعة - إيه تعمل دلوقتي؟ ​

1. اعمل output encoding لكل القيم.
2. استعمل innerText بدل innerHTML وقت ما تقدر.
3. فعّل CSP، وحط كوكيز بـHttpOnly وSecure.
4. نفّذ فلترة على الـserver (validation) ومحدّش يثق بالـclient.
5. استخدم مكتبات معروفة (زي DOMPurify) لو هتسمح بـHTML.
6. راقب اللوجات وفعل تنبيهات لحركة مش متوقعة.