هجمات XSS في React: dangerouslySetInnerHTML والبرامج النصية التابعة لجهات خارجية

يُجري React تلقائيًا ترميزًا آمنًا لجميع القيم المعروضة عبر JSX قبل إدراجها في DOM. عند كتابة {userInput} في JSX، يستدعي React ما يعادل إسناد textContent — فتُعامَل القيمة كنص، ولا تُعامَل مطلقًا كـ HTML. ويمنع ذلك افتراضيًا معظم هجمات XSS في تطبيقات React.

يمثّل dangerouslySetInnerHTML={{ __html: htmlString }} آلية React لتجاوز الحماية، إذ يتخطى الترميز التلقائي. والاسم مصمم عمدًا ليكون تحذيريًا: فهو يخبركم بأنكم تتحملون مسؤولية سلامة سلسلة HTML. يضبط React الخاصية innerHTML مباشرةً، مما يؤدي إلى تنفيذ أي HTML، بما في ذلك البرامج النصية ومعالجات الأحداث.

تحتاجون فعلًا إلى dangerouslySetInnerHTML عند عرض HTML مصدره محرر نص منسق مثل TipTap أو Quill، أو نظام CMS يخزّن HTML، أو محوّل من Markdown إلى HTML. تنتج هذه المصادر ترميز HTML حقيقيًا يجب عرضه كـ HTML، لا كنص مُرمَّز.

إذا احتوت سلسلة HTML على <script>stealCookies()</script> أو <img src=x onerror="stealData()">، فإن ضبطها كقيمة لـ innerHTML ينفّذ رمز المهاجم. ويُعدّ تمرير أي محتوى يقدمه المستخدم مباشرةً إلى dangerouslySetInnerHTML من دون تنقية ثغرة XSS خطيرة.

DOMPurify هي أداة تنقية HTML القياسية في المجال للمتصفحات. فهي تحلّل سلسلة HTML في سياق معزول، وتزيل العناصر والسمات الخطرة، مثل وسوم script ومعالجات الأحداث وروابط javascript:، ثم تعيد سلسلة HTML آمنة. الاستخدام: DOMPurify.sanitize(dirtyHtml) قبل تمريرها إلى dangerouslySetInnerHTML.

تعمل البرامج النصية التابعة لجهات خارجية، مثل أدوات التحليلات وعناصر الدردشة وشبكات الإعلانات، بالصلاحيات نفسها التي تستخدمها JavaScript الخاصة بتطبيقكم. ويمكن لبرنامج نصي تابع لجهة خارجية تم اختراقه أو كان خبيثًا أن يقرأ document.cookie، ويصل إلى localStorage، ويقرأ مدخلات النماذج، ويرسل طلبات إلى خوادم خارجية — وكل ذلك من دون أي مؤشر للمستخدم.

سياسة أمان المحتوى هي ترويسة HTTP تحدد البرامج النصية المسموح بتنفيذها. وحتى إذا حُقنت حمولة XSS في DOM، فيمكن لسياسة CSP مُعدّة إعدادًا صحيحًا حظر تنفيذها من خلال تقييد البرامج النصية المضمّنة والسماح فقط بمصادر البرامج النصية المدرجة في القائمة المسموح بها. وتُعدّ CSP خط الدفاع الثاني بعد تنقية المدخلات.

تُعدّ حزم npm مسارًا حقيقيًا لهجمات XSS. فقد تتضمن تبعية ما رمزًا خبيثًا يسرّب متغيرات البيئة أو بيانات المستخدمين. وقد أظهر حادث node-ipc عام 2022 واختراق ua-parser-js عام 2021 أن الحزم واسعة الاستخدام يمكن الاستيلاء عليها وزرع برمجيات خبيثة فيها. دقّقوا في التبعيات باستخدام npm audit واستخدموا ملفات القفل.

يتيح هجوم XSS الناجح للمهاجم سرقة رمز JWT الخاص بالمستخدم من sessionStorage وإرساله إلى خادم يتحكم فيه المهاجم، وتنفيذ إجراءات بصفة المستخدم المصادق عليه، مثل استدعاءات API باستخدام جلسة المستخدم، وتعديل DOM لعرض محتوى تصيّدي، أو تسجيل كل ضغطة مفتاح يجريها المستخدم في التطبيق.

تتطلب واجهة Trusted Types API في المتصفح أن تستقبل جميع نقاط DOM التي تستقبل المحتوى، مثل innerHTML وeval وscript.src، كائنات ذات أنواع خاصة بدلًا من سلاسل نصية خام. ويمنع ذلك وصول حمولات XSS المعتمدة على السلاسل النصية إلى DOM على مستوى المنصة. ويعمل React على توفير التوافق مع Trusted Types، كما يمكن لـ CSP فرض استخدامها.

النمط الآمن لعرض HTML القادم من CMS هو: جلب HTML، وتمريره عبر DOMPurify.sanitize() باستخدام قائمة مسموح بها من الوسوم والسمات الآمنة، ثم عرضه باستخدام dangerouslySetInnerHTML={{ __html: cleanHtml }}. لا تتخطوا خطوة التنقية مطلقًا، حتى إذا كنتم تثقون بـ CMS، لأن قاعدة بيانات CMS نفسها قد تكون مخترقة.

ماذا تفعل DOMPurify عند استدعاء DOMPurify.sanitize(htmlString)؟

يُجري React ترميزًا آمنًا تلقائيًا لقيم JSX، مما يمنع معظم هجمات XSS. يتخطى dangerouslySetInnerHTML هذا الترميز لعرض HTML المشروع — لذا يجب دائمًا تنقية المدخلات باستخدام DOMPurify أولًا. وتُعدّ البرامج النصية التابعة لجهات خارجية وحزم npm المخترقة مسارات لهجمات XSS عبر سلسلة التوريد. وتوفر سياسة أمان المحتوى طبقة دفاع ثانية. ويتيح XSS الناجح سرقة الرموز وانتحال الهوية والتصيّد.