امتداد Burp لخداع ذاكرة التخزين المؤقت للويب

امتداد Burp لاختبار التطبيقات للضعف أمام هجوم خداع ذاكرة التخزين المؤقت للويب.

بمجرد تحميل الامتداد، يمكن الوصول إليه في علامة التبويب Target - Sitemap والنقر بالزر الأيمن على المورد الذي يجب اختباره. سيظهر عنصر قائمة سياقي يسمى "Web Cache Deception Test" ويمكن استخدامه لإجراء الاختبار. إذا كان المورد ضعيفًا، يتم إنشاء مشكلة تفصيل الضعف.

عنصر القائمة السياقي متاح أيضًا للطلبات في علامة التبويب Proxy - Http History.

التثبيت

• قم بتنزيل ملف WebCacheDeceptionScanner.jar.
• في Burp Suite، افتح علامة التبويب Extender. في علامة التبويب Extensions، انقر على زر Add.
• اختر ملف jar الذي تم تنزيله -> Next.
• تحقق من التثبيت لعدم وجود رسائل خطأ.

الثغرة

في فبراير 2017، كشف الباحث الأمني Omer Gil عن ناقل هجوم جديد أطلق عليه "خداع ذاكرة التخزين المؤقت للويب" (https://omergil.blogspot.co.il/2017/02/web-cache-deception-attack.html).

هجوم خداع ذاكرة التخزين المؤقت للويب قد يكون مدمرًا في عواقبه، لكنه بسيط جدًا في التنفيذ:

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

** بالطبع، هذا الهجوم منطقي فقط عندما يعيد المورد الضعيف المتاح للمهاجم بيانات حساسة.

يعتمد الهجوم على مجموعة محددة جدًا من الظروف لجعل التطبيق ضعيفًا: 1. التطبيق يقرأ فقط الجزء الأول من URL لتحديد المورد الذي سيتم إرجاعه.
إذا طلبت الضحية:

https://www.example.com/my_profile

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

https://www.example.com/my_profile_test

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

https://www.example.com/my_profile/test

2. مكدس التطبيق يخزن الموارد مؤقتًا وفقًا لامتدادات ملفاتها، وليس وفقًا لقيم رأس التخزين المؤقت. إذا تم تكوين مكدس التطبيق لتخزين ملفات الصور مؤقتًا. سيخزن مؤقتًا جميع الموارد ذات الامتدادات .jpg .png أو .gif. هذا يعني أنه على سبيل المثال الصورة في

https://www.example.com/images/dog.jpg

ستُسترجع من خادم التطبيق في المرة الأولى التي تُطلب فيها الصورة. يتم استرداد جميع الطلبات اللاحقة للصورة من ذاكرة التخزين المؤقت، مع الرد بنفس المورد الذي تم تخزينه مؤقتًا في البداية (طالما تم تعيين مهلة التخزين المؤقت).

الهجوم

يمكن استغلال هذه الشروط المسبقة لهجوم خداع ذاكرة التخزين المؤقت للويب بالطريقة التالية:  

الخطوة 1: يقوم المهاجم بإغراء الضحية لفتح رابط تم إنشاؤه بشكل ضار:

  https://www.example.com/my_profile/test.jpg  

• يتجاهل التطبيق الجزء 'test.jpg' من URL، ويتم تحميل صفحة ملف الضحية.
• يحدد آلية التخزين المؤقت أن المورد هو صورة، ويقوم بتخزينه مؤقتًا.  

الخطوة 2: يرسل المهاجم طلب GET للصفحة المخزنة مؤقتًا:

https://www.example.com/my_profile/test.jpg  

• يتم إرجاع المورد المخزن مؤقتًا، وهو في الواقع صفحة ملف الضحية، إلى المهاجم (ولأي شخص آخر يطلبه).

عقلي انفجر كم هو سهل ذلك؟

سجل التغييرات

1.1

• تم التغيير بحيث يتم تضمين فحص هذه المشكلة عند إجراء فحص نشط.
• تم تحديث الفحص ليشمل الدروس المستفادة من بيئات العالم الحقيقي.
• الإبلاغ الآن يتم فقط عن طريق الإضافة

إصدار 1.0