Stored XSS
في هذا القسم ، سنشرح Stored XSS ، ووصف
تأثير هجمات التي تسمى باللغة العربية XSS المخزنة ، ونوضح كيفية
العثور على ثغرات XSS المخزنة.
ما هي ثغرة Stored XSS؟
تنشأ (المعروفة أيضًا باسم XSS من الدرجة الثانية أو XSS الدائمة) عندما يتلقى
التطبيق بيانات من مصدر غير موثوق به ويتضمن تلك البيانات في
استجابات HTTP اللاحقة بطريقة غير آمنة.
لنفترض أن موقع الويب يسمح
للمستخدمين بإرسال تعليقات على منشورات المدونة ، والتي يتم عرضها للمستخدمين
الآخرين. يرسل المستخدمون التعليقات
باستخدام طلب HTTP مثل ما يلي:
POST /post/comment
HTTP/1.1
Host: vulnerable-website.com
Content-Length: 100
postId=3&comment=This+post+was+extremely+helpful.&name=Carlos+Montoya&email=carlos%40normal-user.net
بعد إرسال هذا التعليق ،
سيتلقى أي مستخدم يزور منشور المدونة ما يلي ضمن استجابة التطبيق:
<p>This
post was extremely helpful.</p>
بافتراض أن التطبيق لا يقوم
بأي معالجة أخرى للبيانات ، يمكن للمهاجم إرسال تعليق ضار مثل هذا:
<script>/*
Bad stuff here... */</script>
ضمن طلب المهاجم ، سيتم
ترميز هذا التعليق بعنوان URL على النحو التالي:
comment=%3Cscript%3E%2F*%2BBad%2Bstuff%2Bhere...%2B*%2F%3C%2Fscript%3E
أي مستخدم يزور منشور
المدونة سيتلقى الآن ما يلي ضمن استجابة التطبيق:
<p><script>/*
Bad stuff here... */</script></p>
سيتم بعد ذلك تنفيذ النص
الذي قدمه المهاجم في متصفح المستخدم الضحية ، في سياق جلسته مع التطبيق.
تأثير هجمات Stored XSS
إذا تمكن المهاجم من التحكم
في نص برمجي يتم تنفيذه في متصفح الضحية ، فيمكنه عادةً اختراق هذا المستخدم بشكل
كامل. يمكن للمهاجم تنفيذ أي من
الإجراءات التي تنطبق على تأثير ثغرات XSS المنعكسة .
فيما يتعلق بقابلية
الاستغلال ، يتمثل الاختلاف الرئيسي بين XSS المنعكس والمخزن في أن ثغرة XSS المخزنة تمكن من شن هجمات قائمة بذاتها داخل
التطبيق نفسه. لا يحتاج المهاجم إلى إيجاد
طريقة خارجية لحث المستخدمين الآخرين على تقديم طلب معين يحتوي على استغلالهم. بدلاً من ذلك ، يضع المهاجم ثغراته في التطبيق
نفسه وينتظر المستخدمين ببساطة لمواجهتها.
تعتبر الطبيعة المستقلة
لعمليات استغلال البرمجة النصية عبر المواقع المخزنة ذات صلة بشكل خاص في المواقف
التي تؤثر فيها ثغرة XSS فقط على المستخدمين الذين
قاموا بتسجيل الدخول حاليًا إلى التطبيق. إذا انعكس XSS ، فيجب
أن يتم توقيت الهجوم بشكل عرضي: لن يتم اختراق المستخدم الذي يتم حثه على تقديم
طلب المهاجم في وقت لم يتم تسجيل دخوله. في المقابل ، إذا تم تخزين XSS ،
فسيضمن للمستخدم تسجيل الدخول في الوقت الذي يواجه فيه الاستغلال.
Stored XSS في سياقات مختلفة
هناك العديد من الأنواع
المختلفة من البرامج النصية المخزنة عبر المواقع. يحدد موقع البيانات المخزنة
في استجابة التطبيق نوع الحمولة المطلوبة لاستغلالها وقد يؤثر أيضًا على تأثير
الثغرة الأمنية.
بالإضافة إلى ذلك ، إذا أجرى
التطبيق أي عملية تحقق أو معالجة أخرى على البيانات قبل تخزينها ، أو في النقطة
التي يتم فيها دمج البيانات المخزنة في الاستجابات ، فسيؤثر هذا بشكل عام على نوع
حمولة XSS المطلوبة.
كيفية البحث عن ثغرات XSS المخزنة واختبارها
يمكن العثور على العديد من
ثغرات XSS المخزنة باستخدام أداة فحص ثغرات الويب في Burp
Suite .
قد يكون اختبار ثغرات XSS المخزنة يدويًا أمرًا صعبًا. تحتاج إلى اختبار جميع "نقاط الدخول"
ذات الصلة والتي يمكن من خلالها إدخال البيانات التي يمكن للمهاجمين التحكم فيها
إلى معالجة التطبيق ، وجميع "نقاط الخروج" التي قد تظهر فيها تلك
البيانات في استجابات التطبيق.
ثغرات XSS (Reflected, Stored and DOM based XSS)
تشمل نقاط الدخول إلى معالجة
التطبيق ما يلي:
·
المعامِلات أو البيانات
الأخرى ضمن سلسلة استعلام عنوان URL ونص الرسالة.
·
مسار ملف URL.
·
رؤوس طلبات HTTP التي قد لا تكون قابلة للاستغلال فيما يتعلق بـ XSS المنعكس .
·
أي مسارات خارج النطاق يمكن
للمهاجم من خلالها تسليم البيانات إلى التطبيق. تعتمد المسارات الموجودة
كليًا على الوظائف التي ينفذها التطبيق: سيعالج تطبيق بريد الويب البيانات الواردة
في رسائل البريد الإلكتروني ؛ قد يقوم التطبيق الذي يعرض
موجز Twitter بمعالجة البيانات الموجودة
في تغريدات الطرف الثالث ؛ وسيشمل مجمع الأخبار
البيانات الناشئة على مواقع الويب الأخرى.
نقاط الخروج لهجمات XSS المخزنة هي جميع استجابات HTTP المحتملة التي يتم إرجاعها إلى أي نوع من
مستخدمي التطبيق في أي موقف.
تتمثل الخطوة الأولى في
اختبار ثغرات XSS المخزنة في تحديد الروابط بين
نقاط الدخول والخروج ، حيث تنبعث البيانات المقدمة إلى نقطة الدخول من نقطة الخروج. الأسباب التي تجعل هذا الأمر صعبًا هي:
·
البيانات المقدمة إلى أي
نقطة دخول يمكن من حيث المبدأ أن تنبعث من أي نقطة خروج. على سبيل المثال ، يمكن أن
تظهر أسماء العرض التي يوفرها المستخدم داخل سجل تدقيق غير معروف يكون مرئيًا فقط
لبعض مستخدمي التطبيق.
·
غالبًا ما تكون البيانات
المخزنة حاليًا بواسطة التطبيق عرضة للكتابة فوقها بسبب الإجراءات الأخرى التي يتم
تنفيذها داخل التطبيق. على سبيل المثال ، قد تعرض
وظيفة البحث قائمة بعمليات البحث الأخيرة ، والتي يتم استبدالها بسرعة عندما يجري
المستخدمون عمليات بحث أخرى.
لتحديد الروابط بين نقاط
الدخول والخروج بشكل شامل ، قد يتضمن اختبار كل تبديل على حدة ، وتقديم قيمة محددة
في نقطة الدخول ، والتنقل مباشرة إلى نقطة الخروج ، وتحديد ما إذا كانت القيمة تظهر
هناك. ومع ذلك ، فإن هذا الأسلوب
غير عملي في تطبيق يحتوي على أكثر من بضع صفحات.
بدلاً من ذلك ، يتمثل النهج
الأكثر واقعية في العمل بشكل منهجي من خلال نقاط إدخال البيانات ، وتقديم قيمة
محددة في كل واحدة ، ومراقبة استجابات التطبيق لاكتشاف الحالات التي تظهر فيها
القيمة المقدمة. يمكن إيلاء اهتمام خاص
لوظائف التطبيق ذات الصلة ، مثل التعليقات على منشورات المدونة. عندما يتم ملاحظة القيمة المرسلة في استجابة ،
تحتاج إلى تحديد ما إذا كانت البيانات مخزنة بالفعل عبر طلبات مختلفة ، بدلاً من
انعكاسها ببساطة في الاستجابة الفورية.
عندما تحدد الروابط بين نقاط
الدخول والخروج في معالجة التطبيق ، يجب اختبار كل رابط على وجه التحديد لاكتشاف
ما إذا كانت ثغرة XSS المخزنة موجودة. يتضمن ذلك تحديد السياق داخل الاستجابة حيث
تظهر البيانات المخزنة واختبار حمولات XSS المرشح المناسبة التي تنطبق
على هذا السياق. في هذه المرحلة ، تكون منهجية الاختبار هي نفسها المستخدمة في العثور
على ثغرات ما تسمى باللغة العربية XSS المنعكسة .
0 Comments:
إرسال تعليق