Post

Explain XSS (Cross‑Site Scripting)

Posted
cross site scripting Concept
cross site scripting Concept
By Omar Zidan
2 min read
Explain XSS (Cross‑Site Scripting)

إيه هو XSS؟

XSS أو Cross‑Site Scripting هو هجوم بيسمح للمهاجم إنه يحقن (inject) كود جافاسكربت داخل صفحات الموقع، والكود ده بيتنفّذ في متصفح الضحية. النتيجة ممكن تبقى من عرض رسالة بسيطة لتغيير المحتوى لحد سرقة بيانات الجلسة أو تنفيذ أوامر نيابة عن المستخدم.

الهدف من الشرح ده: نفهم المشكلة ونتعلم نمنعها — مش لاستخدامها بصورة ضارة.

أنواع XSS الأساسية

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

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

  2. Stored XSS (المخزن / الدائم)

    • بقى أخطر لأن الـpayload بيتخزن في قاعدة بيانات (تعليقات، بروفايلات، رسائل) ويتعرض لكل اللي يزوروا الصفحة.

  3. DOM‑based XSS

    • المشكلة هنا في طرف العميل (المتصفح)؛ سكربت في الصفحة بياخد قيمة من الـURL أو الـDOM ويعدّل الصفحة باستخدام innerHTML من غير تعقيم — ومش بيمرّ بالسيرفر.

مثال توضيحي

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<!-- reflected-example.html -->
<!doctype html>
<html>
  <body>
    <h1>أهلاً بك يا عمر!</h1>
    <p>الاسم: <span id="name"></span></p>

    <script>
      const params = new URLSearchParams(window.location.search);
      const name = params.get('name') || 'ضيف';
      // لو استعملنا innerHTML بدون تعقيم، ممكن يحصل DOM XSS
      document.getElementById('name').innerHTML = name;
    </script>
  </body>
</html>

لو دخلت قيمة فيها <script>alert('XSS')</script> هتتنفّذ — عشان كده لازم نمنع العرض غير المعقّم.

ملاحظة أمنية: استخدم textContent بدل innerHTML لو عايز تعرض النص من غير تنفيذ HTML.

ليه الموضوع خطير؟

  • سرقة ملفات تعريف الجلسة (cookies) أو بيانات المستخدم.
  • تعديل واجهة المستخدم لخداع الضحية أو سرقة بيانات من فورمات.
  • تنفيذ طلبات نيابة عن الضحية أو تحويل المستخدمين لمواقع خبيثة.
  • تدمير سمعة الموقع وفقدان ثقة المستخدمين.

إزاي نمنع XSS — خطوات عملية للمطوّرين

  1. الـ Output Encoding / Escaping

    • خليك بتعمل escaping لأي مدخل قبل ما تعرضه، وباختيار طريقة الـ escaping حسب السياق (HTML, attribute, JS, URL).
    • استخدم templating frameworks اللي بتعمل escaping تلقائي لو موجود.

  2. استعمل DOM APIs آمنة

    • بدل innerHTML استخدم textContent, createTextNode, أو setAttribute للعناصر.

  3. لو محتاج تعرض HTML من المستخدم — استعمل Sanitizer معروف

    • استخدم مكتبات ثابتة زي DOMPurify لتعقيم HTML قبل العرض. ماتحاولش تكتب sanitizer بنفسك من غير خِبرة.

  4. فعل Content Security Policy (CSP)

    • CSP قوي ممكن يمنع تنفيذ سكربتات خارجية أو unsafe-inline. مش حل كامل لكنه خط دفاع مهم.

  5. اجعل الكوكيز حساسة للسرية

    • خلي كوكي الجلسة HttpOnly علشان JS ما يقدرش يقراه، وخليه Secure علشان يُرسَل بس على HTTPS.

  6. Validate inputs على السيرفر

    • التحقق لازم يكون دائمًا على السيرفر — ماتعتمدش على الفلترة على الكلاينت بس.

  7. Principle of Least Privilege

    • خفّض صلاحيات أي محتوى خارجي وماتحمّلش سكربتات من مصادر مش موثوقة.

  8. اختبار أمان أخلاقي

    • متختبرش ولا تهاجم مواقع مش عندك تصريح للاختبار عليها. استخدم بيئات اختبار أو staging.

Checklist سريعة (انسخها واحتفظ بيها)

  • اعمل escaping لكل مدخل عند العرض (حسب السياق).
  • استعمل textContent بدل innerHTML متى ما تقدر.
  • لو بتعرض HTML من المستخدم — عقمه بـ DOMPurify أو مكتبة مشابهة.
  • فعل CSP وامتنع عن unsafe-inline قدر الإمكان.
  • خلي كوكيز الجلسة HttpOnly وSecure.
  • افحص صفحات التعليقات والبروفايلات ومنع تخزين HTML غير معقّم.
  • اختبر وظائف البحث والـ forms على وجود حقن XSS.

خاتمة

XSS من أهم الثغرات اللي لازم كل مطور ويب يعرف يتعامل معاها. الحماية مش معقدة: تعامل مع أي مدخل كأني خطر، اعمل escaping مناسب، واستعمل أدوات معقمة وممارسات أمنة.

security, web, xss
XSS web-security OWASP DOM CSP
This post is licensed under CC BY 4.0 by the author.