أمان XSS في مكتبات جافا سكريبت الشهيرة. هل يجب أن أظل قلقاً؟

XSS

نحن نعيش في عصر الأطر وليس اللغات. وهذا يعني ضمناً أن المبرمجين يجب أن يكونوا أقل قلقاً بشأن العديد من جوانب التطوير، بما في ذلك الأمان. فغالبية أطر العمل الخلفية الحالية تطبق وحدات الأمان، والتي يتم اختبارها من قبل شركات خارجية متخصصة ومجتمعات كبيرة. لذلك, انخفاض الوعي الأمني يمكن أن يكون واضحًا، على سبيل المثال بين المبرمجين الشباب، الذين يتحملون المزيد من المسؤولية عن المنتجات، خاصة فيما يتعلق بالعمل الحر.

إحدى الهجمات الشائعة على جانب العميل من التطبيق هي XSS (البرمجة النصية عبر المواقع). يتم تنفيذها عن طريق حقن البرامج النصية القابلة للتشغيل من جانب العميل في تطبيقات الويب [1] وتستخدم أساليب عرض HTML المنفذة أو جافا سكريبت الكود المقيّمات التي تقوم بتنفيذها. تُعد هجمات XSS مربحة نسبيًا حيث يمكن جمع العديد من البيانات المختلفة، بما في ذلك ملفات تعريف الارتباط الخاصة بالجلسة أو بيانات المستخدم، ويمكنها تثبيت تطبيق تتبع مثل برنامج تسجيل المفاتيح، مما يجعلها خطيرة على كل من المستخدمين وأصحاب الأعمال. في بعض الأحيان، يتم تنفيذ أشكال أخرى من الهجوم للسماح بـ XSS على الصفحة، مثل حقن SQL.

مثال على ذلك

نموذج تسجيل الدخول على الصفحة يعرض معلمة اسم تسجيل الدخول المرسلة ضمن طلب GET في إدخال اسم تسجيل الدخول. لا تتم معالجة القيمة لا من جانب الخادم ولا من جانب العميل في التطبيق. عن طريق الطلب: http://localhost:8080/login?name=<script>alert(document.cookies)</script>
يتم تنفيذ التعليمات البرمجية وتعرض البيانات

هذا مثال على هجوم XSS المنعكسحيث يتم حقن البرامج النصية من خلال عنوان URL مُعد خصيصًا يتم إرساله إلى الضحية وينعكس من خلال استجابة الخادم. ومن أشكال الهجمات الشائعة الأخرى المعروفة ما يلي:

• XSS المخزنة يتم تنفيذها مع البيانات المحقونة المخزنة على جانب الخادم، وعادةً ما يتم ذلك من خلال النماذج المتوفرة في التطبيق. يعرض تطبيق العميل التعليمات البرمجية المخزنة، على سبيل المثال، في قاعدة بيانات.
• DOM XSS ينفذ هجوم XSS دون استخدام جانب الخادم. سنركز في الجزء التالي من المقال على هذا النوع من الهجمات.

الثغرات الحالية في مكتبات React وVue

بالنسبة للإصدارين الحاليين React/Vue، تم اكتشاف مشكلتين رئيسيتين لم يتم إصلاحهما رسمياً بعد. الثغرة الأولى لها نفس الطبيعة لكل إطار عمل وترتبط بالطرق التي تسمح بعرض HTML الخام داخل القوالب: v-html و بشكل خطيرSetSetInnerHTML, على الترتيب، بالنسبة إلى Vue و React. تُعلم كل الوثائق [2] القراء أن الاستخدام غير الحكيم قد يعرض المستخدمين لهجوم XSS. في حالة عدم وجود خيارات أخرى لحل المشكلة، تأكد من أن البيانات تمت تصفيته و هرب. على الرغم من خطورتها، يجب ألا تتوقع أن تكون هذه الطرق ثابتة. استخدمها على مسؤوليتك الخاصة.

في الربع الأول من عام 2018، تم اكتشاف خطأ كبير في React، مما يسمح بتنفيذ التعليمات البرمجية مباشرةً عن طريق تعيين خاصية لعنصر العلامة. تمرير أمثلة التعليمات البرمجية داخل السمات، مثل جافا سكريبت:تنبيه(1) وسيؤدي تشغيل رابط تم عرضه إلى تنفيذ الشيفرة البرمجية. لا تزال هذه المشكلة [4] مفتوحة ولم يتم إعداد أي إصلاح لها ودمجها، لذا تأكد من أن شفرتك آمنة. تقترح الأمثلة المقترحة في المناقشة الرسمية بعض الطرق للتغلب على هذه المشكلة.

إذا لم يكن التحديث إلى أحدث الإصدارات ممكنًا، فتأكد من أن المشكلات القديمة لا تسبب لك مشاكل من خلال التأكد من عدم تعرض شفرتك البرمجية

• طفل العقدة الحقن - React, استخدام React.createElement [5]
• العرض من جانب الخادم - React/Vue [6]
• حقن CSS [8]

لا يزال الأمر يتعلق ب Javascript. لا يزال الأمر يتعلق بالواجهة الأمامية

لا تنسى أنه بالإضافة إلى الأطر أو المكتبات نفسها، فإن جافا سكريبت كلغة لها بعض الوظائف الخطيرة، والتي يجب تجنبها أو استخدامها بحذر. وهي مرتبطة عمومًا بالتلاعب بنماذج كائنات DOM أو تنفيذ البرامج النصية. eval() تمثل دوال رائدة من هذا النوع، وهي خطيرة للغاية لأنها تنفذ شيفرة سلسلية معينة مباشرةً [9]. أيضًا، ألقِ نظرة أفضل على شيفرتك عند العثور على إحدى هذه الدوال:

• كتابة المستند
• المستند.writeln
• (العنصر).innerHTML
• (العنصر).outerHTML
• (العنصر).insertAdjacentHTML

وهنا، قد يكون استخدام أدوات التحليل مع مجموعة قواعد مناسبة مفيدًا في العثور على نقاط الضعف هذه. هناك أيضًا الكثير من أدوات تحليل الشيفرة البرمجية المفتوحة أو التجارية التي قد تساعدك في اكتشاف الثغرات الأمنية في الشيفرة البرمجية المطورة.

بغض النظر عن المكتبة/الإطار الذي يتم اختياره، لا يزال علينا أن نتذكر المبادئ الأساسية المتعلقة بتطوير الواجهة الأمامية. أولاً، تأكد دائمًا من أن الشيفرة الخارجية التي تحقن بها تأتي من مصدر موثوق. التدقيق تبعياتك، واخترها بحكمة. فبعضها يمكن أن يحتوي على ثغرات أمنية خطيرة، مما يعرض شفرتك للخطر حتى لو كان كل شيء على ما يرام في الشيفرة نفسها. يمكنك قراءة المزيد عن أمان التبعيات هنا:

https://thecodest.co/blog/security-in-javascript-packages/

إذًا... هل يجب أن تظل قلقًا؟

نعم - وأنا أشجع الجميع بشدة على عدم الوثوق بالمكتبات الخارجية أو بنفسك من حيث الأمان. بغض النظر عن مدى الأمان الذي تتوقع أن يكون برنامجك آمنًا، ابذل دائمًا جهدًا لاختباره قدر الإمكان من حيث أشكال الهجمات الشائعة [10].

1. https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml
2. https://vuejs.org/v2/guide/syntax.html#Raw-HTML
3. https://github.com/facebook/react/issues/12441
4. http://danlec.com/blog/xss-via-a-spoofed-react-element
5. https://medium.com/node-security/the-most-common-xss-vulnerability-in-react-js-applications-2bdffbcc1fa0
6. https://github.com/dotboris/vuejs-serverside-template-xss
7. https://frontarm.com/james-k-nelson/how-can-i-use-css-in-js-securely/
8. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval#Do_not_ever_use_eval!

اقرأ المزيد:

5 أخطاء يجب أن تتجنبها أثناء صيانة مشروع في PHP

تطوير PHP. مكوّن وحدة تحكم Symfony - نصائح وحيل

لماذا نحتاج إلى Symfony Polyfill (... ولماذا لا نحتاج إلى Symfony Polyfill)