ثغرة BOLA - كيف تؤثر إدارة مصادقة البيانات على أمان الـ API

Vulnerabilities
كيفية اكتشاف ثغرة BOLA والحلول المتبعة لحماية بيانات الـ API الخاصة بالمستخدمين
Mostafa Tamam
April 30, 2023, 6 p.m.
mostafa_tamam
ثغرة BOLA - كيف تؤثر إدارة مصادقة البيانات على أمان الـ API

مقدمة

كما تحدثنا فى الجزء السابق من هذة السلسلة عن ما هو الـ API وكيفية تواصل التطبيقات مع بعضها واهمية وجود عملية اختبار اختراق لـ API بشكل مستمر وما هى أهم التهديدات التى تواجة الـ API, سوف نتطرق فى الحديث فى هذة المقالة عن الثغرة الأولى من ثغرات الـ OWASP API وهى الـ (BOLA) Broken Object Level Authorization سنتعرف عن ما هى هذه الثغرة وكيفية الأكتشاف والأساليب والتقنيات المتبعة لحفظ بيانات المستخدمين.

ما هى ثغرة BOLA ؟

دعنا نبدأ بمثال لتوضيح ما هى هذة الثغرة, إذا عثر المستخدم على Endpoint معينة داخل الـ API والمقصود بالـ Endpoint هنا هو نقطة النهاية التى تجدها فى اخر الـ URL ، على سبيل المثال  رقم مستخدم في عنوان URL للمتصفح ، وغيّر هذا الرقم إلى رقم آخر وأعادت واجهة برمجة التطبيقات API معلومات لا ينبغي للمستخدمين الوصول إليها ، فإننا نتعامل هنا مع كسر فى طبقة التفويض او التحقق authorization من نوع object-level. لذلك تحدث هذه الثغرة الأمنية عندما تمنح واجهة برمجة التطبيقات API المستخدم حق الوصول إلى شيء لا يجب أن يكون لديه حق الوصول إليه عادةً.

تميل واجهات برمجة التطبيقات (API) إلى كشف نقاط النهاية Endpoint التي تتعامل مع الـ object ، مما يؤدي إلى إنشاء مشكلة تحكم في الوصول إلى مستوى هجوم واسع, يجب مراعاة عمليات التحقق من التفويض على object-level في كل وظيفة تصل إلى عرض البيانات باستخدام اى إدخال من المستخدم.
تقرير OWASP API Security Top 10 لعام 2019

كيف تحدث هذة الثغرة ؟

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

هل يشكل تهديد عدم التحقق من هذة الثغرة ؟

إن الشركات التي تقلل من أهمية أمان الـ API تخاطر بتصدر عناوين الصحف باعتبارها الضحية التالية لخرق كبير للبيانات كما حدث مع USPS, وهو أحد أكبر خروقات البيانات في التاريخ بسبب عدم وجود ضوابط للمستخدم حيث تؤدي نقاط ضعف BOLA إلى انتهاكات مدمرة للبيانات وعواقب أخرى.

"اختراق USPS هو مثال كلاسيكي على ثغرة أمنية حيث كان المستخدم "A" قادرًا على المصادقة على واجهة برمجة التطبيقات ثم التمحور والوصول إلى معلومات المستخدم "B" و 60 مليون شخص آخر ".
Dan Barahona, Founder of APIsec

كيفية اختبار اختراق ثغرة BOLA ؟

يمكنك اختبار نقاط ضعف التفويض من خلال فهم كيفية عمل الـ API ثم محاولة الوصول إلى الموارد والـ Endpoint التي لا يحق لك الوصول إليها. من خلال اكتشاف الأنماط داخل المسارات والـ parameters داخل الـ API ، قد تتمكن من التنبؤ بباقى الـ Endpoint المحتملة الأخرى.

اليك بعض الـ Endpoint التى يجب ان تجذب انتباهك:
 

  • GET /api/resource/5
  • GET /user/account/find?user_id=13
  • POST /company/account/Apple/balance
  • POST /admin/pwreset/account/90

في هذه الحالات، يمكنك على الأرجح تخمين ما هى الـ Endpoint المحتملة الأخرى ، مثل ما يلي:

 

  • GET /api/resource/7
  • GET /user/account/find?user_id=23
  • POST /company/account/Google/balance
  • POST /admin/pwreset/account/99

 

إذا تمكنت من الوصول بنجاح إلى هذة المعلومات التي يجب ألا يكون مصرحًا لك بالوصول إليها ، فهذا يعني أنك اكتشفت ثغرة BOLA.

بأمكانك ايضا التغيير فى نص الطلبات وترى ماذا سوف يعود لك الـ API اليك بعض الأمثلة.

بأمكانك ايضا ان تبدا بأختبار اختراق على crAPI وتختبر ثغرة BOLA بأستخدام Burp suite او Postman.

ما الذي يجعل الـ API عرضة للخطر؟

توجد أخطاء عادةً في واجهات برمجة التطبيقات API التي تستخدم ID في الطلب. يمكن أن تستبدله بالـ (UUID) الذى يتميز بأنه فريد من نوعة فى كل طلب، او ملفات تعريف الارتباط Cookies ، ايضا إذا كان تغيير الـ object في الطلب يسمح للمستخدم بالوصول إلى المعلومات التي لم يكن لديه حق الوصول إليها سابقًا ، فهناك دليل قاطع على ثغرة BOLA.

كيفية حماية الـ API من ثغرة BOLA ؟

اليك بعض الحلول التى سوف تمنع الـ API من عرض اى نتائج ليس مصرح للمستخدم الوصول اليها :-

1- تصميم نظام المصادقة و فرض آليات تفويض قوية

 يجب تصميم نظام المصادقة والتحقق من الصلاحيات بشكل صحيح وفقًا لمتطلبات الأمان والخصوصية والأداء حيث يجب فرض آليات تفويض قوية  فهى الخطوة الأولى التي يجب على أي منظمة اتخاذها لمكافحة نقاط ضعف BOLA.

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

2. استخدام (UUID)

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

يقلل استخدام UUIDs من مخاطر العبث الضار ، وهو أحد الأسباب الجذرية لثغرات BOLA.

3- فحص واختبار الـ API بشكل دوري

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

4- تحديث التطبيقات بشكل منتظم

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

5- اتبع قاعدة Zero-Trust

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

خاتمة

الـ "BOLA هو بالفعل رقم 1 في قائمة  OWASP API TOP 10 يقوم مبرمجين الـ API بعمل رائع في التأكد من مصادقة المستخدمين على التطبيقات ، لذلك يريدون التأكد من أن المستخدمين الشرعيين لديهم حق الوصول.

ولكن الشيء الأول الذي غالبًا ما يتم تجاهله هو التفويض authorization ، مما يضمن عدم تمكن المستخدم "A" من الوصول إلى موارد المستخدم "B". وإخفاء الـ Endpoint او الموارد ، ولكن العامل المهم هناك ألا يكون المستخدم "A" قادرًا على الوصول إلى موارد المستخدم "B" أو التفاعل معها أو تعديلها على الإطلاق ".

"Corey Ball Author of "Hacking APIs


والى هنا نكون قد انهينا بأيجاز الثغرة الأولى من سلسلة OWASP API TOP 10 والى لقاء فى مقالة جديدة وتحدى جديد والله الموفق والمستعان.

واختم بقول الشاعر تميم البرغوثى wink

بنفسي فتىً سَهلُ الخلائقِ طيبٌ & يُمازحُ دهرًا عابسًا لا يُمازِحُ

ويُكثرُ قولَ الشعرِ في الحربِ لا الهوى & لأنّ الهوى لو قِيس بالحربِ جارحُ


BOLA broken object level authorization Zero-Trust UUID OWASP API TOP 10 API Root-X Vulnerability Mostafa Tamam