🕵️‍♂️ المقدمة

في هذا المقال، سأشارك تجربتي في اكتشاف أكثر من 30 ثغرة من نوع BOLA (Broken Object Level Authorization) و IDOR (Insecure Direct Object Reference) في نطاق فرعي واحد خاص بمنصة للاجتماعات والبث المباشر.

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

الخطوة 1: جمع النقاط النهائية (Endpoints)

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

بدأت بتحليل ملفات JavaScript الخاصة بالنطاق، ولاحظت أن الموقع يُستخدم لإنشاء الفصول الدراسية والبث المباشر.

بعض النقاط التي وجدتها:

{
  path: "/",
  path: "/classrooms/",
  path: "/classrooms/create",
  path: "/classrooms/:id",
  path: "/sessions",
  path: "/sessions/create"
}

بعض هذه النقاط كانت تستجيب بشكل مباشر عبر الـ API مثل:

https://class.test.com/api/sessions/

وهنا لاحظت أول مؤشر على وجود تسريب بيانات محتمل.

الخطوة 2: اختبار الطرق الخطيرة (مثل DELETE)

قمت بتحليل ملفات JavaScript بشكل أعمق للتحقق من طرق HTTP المدعومة مثل GET وPOST وDELETE.

إرسال طلب DELETE:

DELETE https://class.test.com/api/classrooms/:id

المفاجأة؟ تم حذف الفصل الدراسي بنجاح!

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

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

الخطوة 3: استكشاف تسريبات إضافية في البيانات

هدفي التالي كان البحث عن أي تسريبات بيانات تخص المستخدمين أو المدراء.

إنشاء حسابات للاختبار:

• حساب مدير
• حساب مستخدم

إضافة المستخدم إلى فصل:

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

مراجعة السجل:

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

تجربة تغيير الطرق:

قمت بتغيير بعض الطرق إلى DELETE أو PUT ولاحظت إمكانية حذف المستخدم من الفصل أو تعديل بياناته بدون تفويض، مما يُمثل تصعيد صلاحيات واضح.

الخطوة 4: جمع بيانات إضافية من واجهة المدير

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

مثال:

https://test.test.com/api/recordings/<id>

جمعت هذه الروابط واختبرتها من حساب المستخدم، ولاحظت أن بعضها يُعيد بيانات حساسة بالفعل، مما يعني أن الصلاحيات غير مفروضة بشكل سليم.

تقنيات إضافية لتصعيد الصلاحيات

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

✅ الخلاصة

من خلال هذه الخطوات استطعت اكتشاف أكثر من 30 ثغرة BOLA وIDOR داخل نطاق فرعي واحد. تنوعت الثغرات بين:

• تسريب بيانات
• حذف موارد بدون تفويض
• تصعيد صلاحيات

وقد تم الإبلاغ عنها جميعًا عبر برنامج Bug Bounty الخاص بالمنصة.

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

ابقَ آمنًا وواصل الصيد! 🧠🎯