الحماية اليدوية من هجمات BOLA¶
الهجمات السلوكية مثل خلل التحقق من صلاحيات الوصول للكائنات (BOLA) تستغل ثغرة بنفس الاسم. تمكن هذه الثغرة المهاجم من الوصول إلى كائن عن طريق معرفه من خلال طلب API وإما قراءة بياناته أو تعديلها متجاوزًا آلية التحقق من الهوية. يوضح هذا المقال تدابير الحماية من BOLA التي توفرها مشغلات WAAP.
تدابير حماية BOLA الأخرى
كبديل أو إضافة، يمكنك تهيئة الحماية الآلية من BOLA لنقاط النهاية التي يعثر عليها اكتشاف API.
التهيئة¶
بشكل افتراضي، تكتشف Wallarm تلقائيًا الثغرات من نوع BOLA (المعروفة أيضًا باسم IDOR) فقط لكنها لا تكتشف محاولات استغلالها.
لكي يتعرف عقدة Wallarm على هجمات BOLA:
-
افتح واجهة Wallarm → مشغلات وتابع إلى إعداد مشغل BOLA.
-
حدد شروط تعريف الطلبات كهجوم BOLA:
- عدد الطلبات من نفس عنوان IP خلال فترة زمنية معينة.
-
URIالذي يحتاج إلى الحماية من هجمات BOLA والذي يتلقى عدد الطلبات المحدد. يجب أن تكون القيمة عبارة عن نقطة نهاية API تشير إلى كائن بمعرفه لأن هذا النوع من نقاط النهاية معرضة بشكل محتمل لهجمات BOLA.
لتحديد معلمة PATH التي تحدد كائن، استخدم الرمز
*
، مثلًا:يمكن تهيئة URI عبر منشئ URI أو نموذج التحرير المتقدم في نافذة إنشاء المشغل.
-
(اختياري) التطبيق الذي يحتاج إلى الحماية من هجمات BOLA والذي يتلقى عدد الطلبات المحدد.
إذا كنت تستخدم نفس الاسم لنطاقات متعددة، يُوصى باستخدام هذا الفلتر للإشارة إلى التطبيق الذي يُعين له نطاق في فلتر URI.
-
(اختياري) عنوان أو عناوين IP التي تنشأ منها الطلبات.
-
اختر ردود فعل المشغل:
- وسم كـ BOLA. الطلبات التي تتجاوز العتبة مُوسمة كهجوم BOLA وتُعرض في قسم الهجمات في واجهة Wallarm. عقدة Wallarm لا تحظر هذه الطلبات الخبيثة.
-
حظر عناوين IP التي تنشأ عنها الطلبات الخبيثة وفترة الحظر.
ستحظر عقدة Wallarm كلاً من الطلبات المشروعة والخبيثة (بما في ذلك هجمات BOLA) الصادرة عن عناوين IP المحظورة.
-
إدراج عناوين IP في القائمة الرمادية التي تنشأ عنها الطلبات الخبيثة وفترة الحظر.
ستحظر عقدة Wallarm الطلبات الصادرة عن عناوين IP الموجودة في القائمة الرمادية فقط إذا كانت تتضمن علامات التحقق من الإدخال، علامات
vpatch
أو هجمات مخصصة.هجمات BOLA الصادرة عن عناوين IP في القائمة الرمادية
هجمات BOLA الصادرة عن عناوين IP في القائمة الرمادية لا يتم حظرها.
-
احفظ المشغل وانتظر اكتمال مزامنة السحابة والعقدة (عادةً ما يستغرق ذلك من 2 إلى 4 دقائق).
الاختبار¶
-
أرسل عدد الطلبات الذي يتجاوز العتبة المُهيأة إلى URI المحمي. على سبيل المثال، 50 طلبًا بقيم
{shop_id}
مختلفة إلى النقطة النهائيةhttps://example.com/shops/{shop_id}/financial_info
: -
إذا كانت ردة فعل المشغل حظر عنوان IP، افتح واجهة Wallarm → قوائم IP → القائمة السوداء وتحقق من أن عنوان IP المصدر محظور.
إذا كانت ردة فعل المشغل إدراج عنوان IP في القائمة الرمادية، تحقق من قسم قوائم IP → القائمة الرمادية في واجهة Wallarm.
-
افتح قسم الهجمات وتحقق من أن الطلبات معروضة في القائمة كهجوم BOLA.
يُقابل عدد الطلبات المعروضة عدد الطلبات المُرسلة بعد تجاوز عتبة المشغل (مزيد من التفاصيل حول اكتشاف الهجمات السلوكية). إذا كان هذا العدد أكبر من 5، يُطبق أخذ عينات الطلبات وتُعرض تفاصيل الطلب فقط لأول 5 ضربات (مزيد من التفاصيل حول أخذ عينات الطلبات).
للبحث عن هجمات BOLA، يمكنك استخدام علامة البحث
bola
. يتم وصف جميع الفلاتر في التعليمات حول استخدام البحث.
أولويات معالجة المشغلات¶
When there are several triggers with identical conditions (for example, Brute force, Forced browsing, BOLA) and some of them have nesting level URI, requests to lower nesting level URI will be counted only in the trigger with the filter by the lower nesting level URI.
Triggers without URI filter are considered to be the higher nesting level.
Example:
-
The first trigger with some condition has no filter by the URI (requests to any application or its part are counted by this trigger).
-
The second trigger with the same condition has the filter by the URI
example.com/api
.
Requests to example.com/api
are counted only by the second trigger with the filter by example.com/api
.
المتطلبات والقيود¶
المتطلبات
لحماية الموارد من هجمات BOLA، تُطلب عناوين IP الحقيقية للعملاء. إذا تم نشر عقدة التصفية خلف خادم وكيل أو موزع الحمل، قم بتهيئة عرض عناوين IP الحقيقية للعملاء.
القيود
عند البحث عن علامات هجمات BOLA، تقوم عقد Wallarm بتحليل طلبات HTTP التي لا تحتوي على علامات أنواع الهجمات الأخرى.