البرمجة النصية عبر المواقع (XSS)

لماذا يهم

بالنسبة إلى المنتج، يحوّل XSS حقلاً نصياً لا ضرر منه إلى نقطة دخول: يمكن قراءة ملف تعريف ارتباط الجلسة إن كان بلا HttpOnly، وإرسال النماذج باسم الضحية، ورسم مربع تسجيل دخول مزيف فوق الصفحة الحقيقية، وXSS المخزَّن في شاشة إدارية يسلّم المهاجم أعلى المستخدمين صلاحية. وبالنسبة إلى المختبِر، هو من العيوب الأمنية القليلة التي يستطيع الاختبار الوظيفي العادي كشفها، لأن كل ميزة تعرض مدخلات المستخدم مرشّحة له.

وهو أيضاً عيب تكشفه بلا أدوات هجوم وبلا ضرر: علامة مميّزة تكتبها في حقل ونظرة إلى مصدر الصفحة تجيبان عن السؤال «هل تُعامَل هذه القيمة نصاً أم شيفرة HTML؟». ومعرفة الأنواع الثلاثة تخبرك أين تكتب العلامة وأين تبحث عنها.

XSS المنعكس والمخزَّن والمعتمد على DOM

لكل XSS الشكل نفسه: قيمة غير موثوقة تدخل من مصدر (source) وتصل إلى مَصبّ (sink) يفسّرها شيفرةً. وتختلف الأنواع في مكان انتظار القيمة ومن يحوّلها إلى شيفرة HTML، ويختبرها دليل OWASP لاختبار أمان الويب (WSTG) كلاً على حدة لأن الخطوات والأشخاص المعرّضين يختلفون.

XSS المنعكس (reflected): تنتقل القيمة في الطلب، عادةً في معامل استعلام أو حقل نموذج، وتعيدها الاستجابة فوراً، كما في «لا نتائج لـ…» في صفحة بحث. لا يراها إلا من أرسل الطلب، لذا يحتاج المهاجم إلى أن يجعل الضحية يرسل الطلب، عادةً بفتح رابط مُعدّ. XSS المخزَّن (stored): تُحفظ القيمة (مراجعة، تذكرة، حقل في الملف الشخصي، اسم ملف) وتُعرض لاحقاً لمستخدمين آخرين، ومنهم الموظفون. لا حاجة إلى رابط، وكل من يشاهدها معرّض، ولهذا هو الأشد خطورة عادةً. XSS المعتمد على DOM (DOM-based): استجابة الخادم نظيفة، لكن JavaScript الصفحة نفسها تقرأ مصدراً مثل location.search أو location.hash أو document.referrer أو حدث postMessage وتكتبه في مصبّ مثل innerHTML أو document.write أو eval. والجزء الذي يلي # في عنوان URL لا يُرسل إلى الخادم أبداً، لذا قد لا يترك هذا النوع أثراً في سجلات الخادم، ولا يصلحه أي ترميز في جهة الخادم.

Reflected  - travels in the request, echoed at once
  GET /search?q=qa7<b>x</b>qa7
  <h2>0 results for qa7<b>x</b>qa7</h2>

Stored     - saved now, rendered to someone else later
  POST /reviews        title=qa7<b>x</b>qa7
  GET  /agent/reviews  (agent B, next day)
  <td>qa7<b>x</b>qa7</td>

DOM-based  - server response clean, the page script writes it
  https://shop.example/help#qa7<b>x</b>qa7   (the part after # never reaches the server)
  status.innerHTML = 'Showing: ' + decodeURIComponent(location.hash.slice(1));

قيم فحص آمنة: هل القيمة نص أم شيفرة HTML؟

لست بحاجة إلى تشغيل سكربت لإثبات XSS. فالعيب هو «تُكتب مدخلات المستخدم في الصفحة دون ترميز»، وقيمة فحص آمنة (probe) ظاهرة وغير ضارة تثبته. ركّب قيمة الفحص من علامة مميّزة مثل qa7 مع الأحرف المؤثرة في HTML: < و> و" و' و&. وتتيح لك العلامة البحث في الصفحة المعروضة وفي مصدر HTML (أمر عرض مصدر الصفحة View Page Source، أو Ctrl+U) عن كل موضع وصلت إليه القيمة، بما فيها مواضع لم تتوقعها: <title>، وسمة (attribute)، ورسالة بريد، وتصدير CSV، ورسالة خطأ.

اقرأ النتيجة في المصدر لا على الشاشة فقط. فـqa7<b>x</b>qa7 تعني أن القيمة رُمّزت بكيانات HTML وهي آمنة في ذلك الموضع؛ وqa7<b>x</b>qa7 بين الوسوم تعني أن شيفرة HTML قُبلت؛ وفي السمة تحقق هل أغلقت علامةُ الاقتباس التي كتبتها السمةَ. أما لوحة Elements فتعرض DOM لا المصدر: فيها تظهر القيمة الآمنة عقدةً نصية واحدة، بينما تظهر شيفرة HTML المقبولة عنصرَ b منفصلاً. ولا تستخدم قيمة فحص تنفيذية (executing probe)، وهي قيمة لا تفعل شيئاً سوى إظهار العلامة، إلا حين يحتاج الفريق إلى إثبات أن السكربت يعمل، وفي بيئة اختبار فقط، وبحساباتك أنت وبإذن مكتوب. وأزل القيم المخزَّنة بعد ذلك: فهي تبقى في قاعدة البيانات وتفاجئ زملاءك بعد أسابيع.

• أدخل قيمة الفحص في كل مكان يمكن للمستخدم الكتابة أو الرفع فيه: النماذج، ومعاملات URL، وأسماء الملفات، والملفات المستوردة، وحقول API تعرضها صفحة لاحقاً، وترويسات الطلب التي يعكسها التطبيق مثل User-Agent أو Referer.
• انظر إلى كل مخرج لا إلى المجاور للمدخل فقط: القوائم، وصفحات التفاصيل، وقوائم انتظار الإدارة، والإشعارات، والمعاينات، والنسخ المطبوعة أو PDF، وJSON الذي تضمّنه الصفحة في كتلة <script>.
• في XSS المعتمد على DOM ضع قيمة الفحص في الجزء (fragment) بعد # وفي المعاملات التي تقرؤها JavaScript الصفحة، وراقب DOM في أدوات المطور لا استجابة الخادم.
• لا تفحص أبداً نظاماً لا تملكه أو ليس لديك إذن مكتوب باختباره: فالفحص دون تصريح قد يخالف القانون حتى بلا سكربت، وقيمة الفحص المخزَّنة في الإنتاج يراها مستخدمون حقيقيون.

Probe                                 What a hit means
qa7<b>x</b>qa7                        "x" in bold: HTML text context is not encoded
qa7"'>x                               your quote closes the attribute in the source
qa7<script>alert('qa7')</script>      a script parsed from the response executes
qa7<img src=x onerror=alert('qa7')>   runs via innerHTML too, where <script> does not

Executing probes: test environment, own accounts, written permission, then remove.

جرّبها: مولّد مجموعات الأحرف الخاصة جرّبها: مرمّز URL

الدفاعات: ترميز المخرجات حسب السياق، والتنقية، وCSP

الدفاع الأساسي هو ترميز المخرجات (output encoding) بما يطابق السياق، وقد تعرّفت إليه في درس «التحقق من المدخلات وترميز المخرجات». والمهم في اختبار XSS هو المواضع التي يفشل فيها عادةً. أولاً، السياق الخاطئ: فكيانات HTML لا تحمي قيمة داخل كتلة <script> أو سمة معالج حدث مثل onclick أو داخل style، وتسمّي ورقة OWASP لمنع XSS (Cross Site Scripting Prevention Cheat Sheet) هذه المواضعَ سياقاتٍ خطرة (dangerous contexts) قد لا يمنع فيها الترميز وحده XSS، وتوصي بتمرير قيم المستخدم بوصفها بيانات لا بكتابتها داخل الشيفرة؛ والرابط الذي يقدّمه المستخدم في href يحتاج أيضاً إلى فحص مخطّطه (scheme) بقائمة سماح مثل https: فيُرفض javascript:، لأن الترميز يترك المخطّط كما هو. ثانياً، تجاوز الإعدادات الافتراضية: فمحركات القوالب وأطر العمل ترمّز نص HTML تلقائياً، لذا تختبئ العيوب في منافذ التجاوز فيها مثل dangerouslySetInnerHTML أو v-html أو الإسناد المباشر إلى innerHTML. ثالثاً، جهة المتصفح: ففي XSS المعتمد على DOM لا يشارك أي ترميز في الخادم، والإصلاح مصبّ آمن مثل textContent بدلاً من innerHTML.

يساعد التحقق من المدخلات (input validation) حيث يكون التنسيق صارماً (تاريخ، كمية) لكنه لا يغني عن الترميز: فالاسم O’Brien ورسالة تحتوي <3 ومنتج اسمه A&B كلها مشروعة. وحين يكون HTML نفسه ميزة، كما في تعليق بنص منسّق، يدمّره الترميز، ويكون الدفاع مُنقِّياً (sanitizer) بقائمة سماح يُبقي <b> و<a href> ويحذف السكربتات ومعالجات الأحداث.

سياسة أمان المحتوى (Content Security Policy، CSP) هي الطبقة الثانية. تخبر ترويسة الاستجابة Content-Security-Policy المتصفحَ أيّ السكربتات يجوز تشغيلها: فـscript-src 'self' تسمح بالسكربتات من أصل الموقع نفسه فقط، و'nonce-…' أو التجزئة (hash) تسمح بسكربتات مضمّنة بعينها، و'unsafe-inline' تسمح بتشغيل كل سكربت مضمّن وكل معالج حدث، فتعطّل هذه الحماية (وتتجاهلها المتصفحات الحالية إذا ذُكرت معها قيمة nonce أو تجزئة). ومع سياسة صارمة يُحظر <script> المحقون أو معالج onerror ويُسجَّل في وحدة التحكم، وهذا يحدّ من ضرر عيب الترميز دون أن يصلحه. اقرأ السياسة بأداة Security Header Analyzer أو HTTP Headers Parser وافحص script-src، أو default-src عند غيابها. وContent-Security-Policy-Report-Only تبلّغ عن المخالفات ولا تحظر شيئاً؛ وتستخدمها الفرق لتجربة سياسة قبل فرضها.

Where the value lands       Defect seen in the source         Defence
HTML text    <td>...</td>   <td>qa7<b>x</b>qa7</td>           HTML entity encoding
Attribute    value="..."    value="qa7"'>x"                   entities, quoted attribute
Link         href="..."     href="javascript:..."             allow-list the scheme
DOM sink     innerHTML      <b> rendered from location.hash   el.textContent = value
Rich text    comment        an onerror= attribute survives    allow-list sanitiser

Strict:  Content-Security-Policy: script-src 'self' 'nonce-R4nd0m'; object-src 'none'
Weak:    Content-Security-Policy: script-src 'self' 'unsafe-inline' *

جرّبها: مرمّز كيانات HTML جرّبها: محلّل ترويسات الأمان جرّبها: محلّل ترويسات HTTP

مثال تطبيقي: مراجعة تصل إلى مكتب الدعم

متجر يتيح للعملاء مراجعة المنتجات ويعرض المراجعات الجديدة لموظفي الدعم في قائمة انتظار. تختبر في بيئة Staging بحسابين، العميل A والموظف B، بإذن مكتوب من الفريق للفحوص الأمنية. بصفتك A ترسل مراجعة عنوانها qa7<b>x</b>qa7 ونصها qa7"'>x. تعرض صفحة المنتج العنوان حرفياً ومصدرها يحوي qa7<b>x</b>qa7: مرمَّز. وبصفتك B تعرض قائمة الانتظار x بخط عريض ومصدرها يحوي <td>qa7<b>x</b>qa7</td>: XSS مخزَّن يصل إلى الموظفين. ويظهر نص المراجعة كما كُتب في الصفحتين. وتجيب صفحة البحث عن /search?q=qa7%3Cb%3Ex%3C%2Fb%3Eqa7 بـ«لا نتائج لـqa7x» وx بخط عريض: XSS منعكس. وتحمل كل استجابة Content-Security-Policy: script-src 'self' 'unsafe-inline'، فلن تمنع السياسة سكربتاً حقيقياً في أيّ من الموضعين.

• الملاحظة ⁦1⁩، حرج (Critical): عناوين المراجعات تُعرض بوصفها HTML في قائمة انتظار الموظفين. الدليل: المدخل، وسطر المصدر، وكلا الدورين، ولقطة شاشة.
• الملاحظة ⁦2⁩، رئيسي (Major): مصطلح البحث يُعاد بوصفه HTML في صفحة النتائج. الدليل: عنوان URL بالضبط وسطر المصدر.
• الملاحظة ⁦3⁩، ثانوي (Minor، تحصين): تسمح CSP بسكربتات 'unsafe-inline' فلن تحدّ من الملاحظتين ⁦1⁩ و⁦2⁩.
• اختبار التأكيد بعد الإصلاح: كرّر قيم الفحص وتوقّع الصيغة المرمَّزة في المصدر، وتحقق من أن عنواناً مشروعاً مثل Fast & cheap ما زال يُعرض كما كُتب لا بصيغة Fast & cheap.

أسئلة شائعة

المراجع

• OWASP Cheat Sheet Series: Cross Site Scripting PreventionOWASP Foundationمنع XSS: الترميز عند الإخراج بحسب كل سياق، وتعقيم HTML الذي يكتبه المستخدم، ومواضع الإدراج الآمنة في DOM وحمايات الأطر، مع اعتبار CSP طبقة دفاع إضافية فقط.
• Cross Site Scripting (XSS)OWASP Foundationما هو هجوم XSS وأنواعه المنعكس والمخزّن وعبر DOM وكيف يمنعه الترميز.
• OWASP Web Security Testing Guide (WSTG)OWASP Foundationالمنهجية المرجعية لاختبار تطبيقات الويب وواجهات API بحثاً عن نقاط الضعف الأمنية، اختباراً تلو الآخر.
• Content-Security-Policy — MDNMDN Web Docs (Mozilla)توجيهات ترويسة CSP التي تقيّد المصادر التي يمكن تحميل السكربتات والأنماط والموارد الأخرى منها.