XSS عبر innerHTML وكيفية منعه

يحلّل el.innerHTML = userInput السلسلة النصية على أنها HTML. إذا احتوت userInput على علامات <script> أو سمات معالجات أحداث (onclick وonerror)، فسيفسرها المتصفح وينفّذ التعليمات البرمجية التي يتحكم بها المهاجم على الصفحة.

تعرّض أي شيفرة تدرج بيانات المستخدم في HTML — مثل قوالب الخادم أو العرض من جهة العميل — التطبيق لخطر XSS إذا لم تُهرب البيانات. وتكون تطبيقات الصفحة الواحدة التي تنشئ innerHTML من استجابات API معرضة للخطر بشكل خاص عندما تتضمن تلك الاستجابات محتوى من المستخدم.

يؤدي اسم المستخدم "Bob<img src=x onerror=alert(1)>"، عند تعيينه باستخدام div.innerHTML = `Welcome, ${user}`، إلى تنفيذ alert(1) عندما يفشل img في التحميل. أما الحمولة نفسها كنص عادي (باستخدام textContent) فهي غير ضارة — إذ يرى المتصفح أحرفًا فقط، لا علامات.

يعيّن textContent النص فقط — فتظهر أحرف HTML الخاصة كأحرف حرفية، ولا تُفسَّر أبدًا على أنها علامات. وهذه هي الأداة المناسبة في 90% من الحالات. انتقل إلى innerHTML فقط عندما تحتاج فعليًا إلى عرض ترميز، لا نص.

لإنشاء عناصر تحتوي على بيانات المستخدم، أنشئها باستخدام createElement وtextContent: const li = document.createElement("li"); li.textContent = name; ul.appendChild(li);. والنتيجة مطابقة بنيويًا لـ innerHTML، لكنها آمنة من XSS بحكم تصميمها.

بالنسبة إلى HTML موثوق ينشئه الخادم (مثل ناتج القالب الخاص بك أو النص المنسق المنقّى من محرر موثوق)، لا مشكلة في استخدام innerHTML. لا تطبّقه مباشرةً على البيانات الواردة من مصادر غير موثوقة من دون تنقية.

إذا أرسل المستخدمون نصًا منسقًا (مثل محرر التعليقات أو عرض Markdown)، فنقِّه قبل تعيين innerHTML: el.innerHTML = DOMPurify.sanitize(richHtml). يزيل DOMPurify العلامات والسمات الخطرة مع الإبقاء على التنسيق الآمن مثل <b> و<em> و<a>.

يحلّل el.insertAdjacentHTML("beforeend", html) سلاسل HTML — أي إنه يعرّضك لسطح XSS نفسه الذي يسببه innerHTML. وتنطبق القواعد نفسها: لا تمرر بيانات المستخدم مباشرةً؛ نقِّها أو استخدم أساليب DOM. وينطبق الأمر نفسه على document.write، مع أنه لا ينبغي لأحد استخدامه بعد الآن.

تهرب React وVue وSvelte وAngular النص المضمّن افتراضيًا — إذ إن {name} آمن. لكنها توفر طرقًا لتجاوز ذلك (dangerouslySetInnerHTML في React وv-html في Vue)، وتحمل هذه الطرق خطر XSS نفسه؛ فاستخدمها باعتدال مع التنقية.

حتى قيم السمات قد تكون وسيلة للهجوم: <a href={url}> مع url="javascript:alert(1)" ينفّذ الشيفرة عند النقر. تحقّق من عناوين URL مخططًا تلو الآخر (واسمح فقط بـ http: وhttps: وmailto: وtel:) قبل وضع مدخلات المستخدم في href أو src أو أي سمات أخرى تحمل عناوين URL.

تدعم المتصفحات الحديثة Trusted Types: اضبط CSP باستخدام require-trusted-types-for 'script'، وعندها يرفض innerHTML السلاسل الخام — ولا تمر إلا القيم المغلّفة بواسطة سياسة. وهذا يجعل XSS مستحيلًا بفضل واجهة البرمجة، لا بفضل الانضباط وحده.

لا تكفي أي طبقة واحدة. اجمع بين: التحقق من المدخلات على الخادم، وتهريب المخرجات عند العرض، واستخدام CSP لحظر البرامج النصية المحقونة، واستخدام Trusted Types لرفض السلاسل الخام، وإجراء مراجعة أمنية لأي استخدام لـ innerHTML. يصمد الدفاع متعدد الطبقات أمام وجود خلل في أي طبقة منفردة.

لماذا يُعد el.textContent = userInput آمنًا من XSS، بينما يُعد el.innerHTML = userInput خطيرًا؟

يُعد innerHTML مع مدخلات المستخدم ناقل XSS الكلاسيكي. استخدم textContent للنصوص، وcreateElement+textContent لبناء البنية، واستخدم DOMPurify عند الحاجة إلى HTML منسق. تحقّق من مخططات عناوين URL لقيم السمات. طبّق CSP وTrusted Types لتحييد الأخطاء التي تتسلل عبر مراجعة الشيفرة. تهرّب أُطر العمل الحديثة من المخرجات افتراضيًا — فاجعل مخارج تجاوزها غير الآمنة نادرة وخاضعة للمراجعة.