مقالة كاملة عن Cross-site scripting

في هذا القسم ، سنشرح ماهية Cross-site scripting، وسنصف الأنواع المختلفة من الثغرات الأمنية في #Cross_site_scripting ، ونوضح كيفية البحث عن Cross-site scriptingومنعها.

ما هي (XSS)؟

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

كيف يعمل XSS# ؟

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

ما هي أنواع هجمات XSS؟

هناك ثلاثة أنواع رئيسية من هجمات XSS. وهذه هي:

• Reflected XSS# : حيث يأتي البرنامج النصي الضار من طلب HTTP الحالي.

• Stored XSS# : حيث يأتي البرنامج النصي الخبيث من قاعدة بيانات الموقع.

• #DOM-based XSS : حيث توجد الثغرة الأمنية في التعليمات البرمجية من جانب العميل بدلاً من التعليمات البرمجية من جانب الخادم.

Reflected cross-site scripting XSS

هو أبسط أنواع cross-site scripting. ينشأ عندما يتلقى التطبيق البيانات في طلب HTTP ويتضمن تلك البيانات في الاستجابة الفورية بطريقة غير آمنة.

فيما يلي مثال بسيط :

https://insecure-website.com/status?message=All+is+well.

<p>Status: All is well.</p>

لا يقوم التطبيق بأي معالجة أخرى للبيانات ، لذلك يمكن للمهاجم بسهولة إنشاء هجوم مثل هذا:

https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>

<p>Status: <script>/* Bad stuff here... */</script></p>

إذا قام المستخدم بزيارة عنوان URL الذي أنشأه المهاجم ، فسيتم تنفيذ البرنامج النصي للمهاجم في متصفح المستخدم ، في سياق جلسة هذا المستخدم مع التطبيق. في هذه المرحلة ، يمكن للبرنامج النصي تنفيذ أي إجراء ، واسترداد أي بيانات ، يمكن للمستخدم الوصول إليها.

Stored cross-site scripting

ينشأ عندما يتلقى التطبيق بيانات من مصدر غير موثوق به ويتضمن تلك البيانات في استجابات HTTP اللاحقة بطريقة غير آمنة.

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

فيما يلي مثال بسيط للثغرة يتيح تطبيق لوحة الرسائل للمستخدمين إرسال الرسائل ، والتي يتم عرضها للمستخدمين الآخرين:

<p>Hello, this is my message!</p>

لا يقوم التطبيق بأي معالجة أخرى للبيانات ، لذلك يمكن للمهاجم بسهولة إرسال رسالة تهاجم المستخدمين الآخرين:

<p><script>/* Bad stuff here... */</script></p>

DOM-based cross-site scripting

ينشأ عندما يحتوي تطبيق ما على بعض من اكواد JavaScript من جانب العميل الذي يعالج البيانات من مصدر غير موثوق به بطريقة غير آمنة ، عادةً عن طريق إعادة البيانات إلى DOM.

في المثال التالي ، يستخدم أحد التطبيقات بعض JavaScript لقراءة القيمة من حقل الإدخال وكتابة هذه القيمة إلى عنصر داخل HTML:

var search = document.getElementById('search').value;
var results = document.getElementById('results');
results.innerHTML = 'You searched for: ' + search;

إذا تمكن المهاجم من التحكم في قيمة حقل الإدخال ، فيمكنه بسهولة إنشاء قيمة ضارة تؤدي إلى تنفيذ البرنامج النصي الخاص به:

You searched for: <img src=1 onerror='/* Bad stuff here... */'>

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

ما الذي يمكن استخدام XSS لأجله في حال اكتشاف ثغرة ؟

عادةً ما يكون المهاجم الذي يستغل ثغرة أمنية في البرمجة عبر المواقع قادرًا على:

1. ينتحل شخصية المستخدم الضحية أو يتنكر فيه.

2. تننيفذ أي إجراء يستطيع المستخدم القيام به.

3. قراءة أي بيانات يستطيع المستخدم الوصول إليها.

4. الحصول على بيانات اعتماد تسجيل دخول المستخدم.

5. إجراء تشويه افتراضي لموقع الويب.

6. إدخال وظائف طروادة في موقع الويب.

تأثير ثغرات XSS

يعتمد التأثير الفعلي لهجوم XSS بشكل عام على طبيعة التطبيق ووظائفه وبياناته وحالة المستخدم المعرض للخطر. فمثلا:

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

في تطبيق يحتوي على بيانات حساسة ، مثل المعاملات المصرفية أو رسائل البريد الإلكتروني أو سجلات الرعاية الصحية ، يكون التأثير خطيرًا في العادة.

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

كيفية البحث عن ثغرات XSS واختبارها

يمكن العثور على الغالبية العظمى من ثغرات XSS بسرعة وموثوقية باستخدام أداة فحص الثغرات الأمنية في Burp Suite.

يتضمن الاختبار اليدوي لـ XSS المنعكس والمخزن عادةً تقديم بعض المدخلات الفريدة البسيطة (مثل سلسلة أبجدية رقمية قصيرة) في كل نقطة دخول في التطبيق ؛ تحديد كل موقع حيث يتم إرجاع المدخلات المقدمة في استجابات HTTP ؛ واختبار كل موقع على حدة لتحديد ما إذا كان يمكن استخدام المدخلات المصممة بشكل مناسب لتنفيذ JavaScript عشوائي.

يتضمن الاختبار اليدوي لـ XSS المستندة إلى DOM والناشئة عن معلمات URL عملية مماثلة: وضع بعض المدخلات الفريدة البسيطة في المعلمة ، واستخدام أدوات مطور المتصفح للبحث في DOM عن هذا الإدخال ، واختبار كل موقع لتحديد ما إذا كان قابلاً للاستغلال. ومع ذلك ، يصعب اكتشاف أنواع أخرى من DOM XSS. للعثور على الثغرات الأمنية المستندة إلى DOM في الإدخال غير المستند إلى عنوان URL (مثل document.cookie) أو الأحواض غير المستندة إلى HTML (مثل setTimeout) ، لا يوجد بديل لمراجعة كود JavaScript ، والذي قد يستغرق وقتًا طويلاً للغاية. فيجمع ماسح ثغرات الويب في Burp Suite بين التحليل الثابت والديناميكي لـ JavaScript لأتمتة اكتشاف الثغرات المستندة إلى DOM.

كيفية منع هجمات XSS

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

بشكل عام ، من المرجح أن يتضمن منع ثغرات XSS بشكل فعال مجموعة من الإجراءات التالية:

1. تصفية المدخلات عند الوصول. في النقطة التي يتم فيها تلقي مدخلات المستخدم ، قم بالتصفية بأكبر قدر ممكن من الدقة بناءً على ما هو متوقع أو إدخال صالح.

2. تشفير البيانات على الإخراج. عند النقطة التي يتم فيها إخراج البيانات التي يتحكم فيها المستخدم في استجابات HTTP ، قم بتشفير الإخراج لمنع تفسيره على أنه محتوى نشط. اعتمادًا على سياق الإخراج ، قد يتطلب ذلك تطبيق مجموعات من ترميز HTML و URL و JavaScript و CSS.

3. استخدم رؤوس الاستجابة المناسبة. لمنع XSS في استجابات HTTP التي لا يقصد بها احتواء أي HTML أو JavaScript ، يمكنك استخدام رؤوس Content-Type و X-Content-Type-Options للتأكد من أن المستعرضات تفسر الاستجابات بالطريقة التي تريدها.