Broken Object Level Authorization in the Wild: An Empirical Taxonomy from 100+ Bug Bounty Disclosures
تقدم هذه الورقة تحليلاً تجريبياً واسع النطاق لـ 107 تقارير من تقارير مكافآت الثغرات المصنفة، كاشفةً أن ثغرة "تجاوز صلاحيات الوصول إلى الكائنات على مستوى الإجراء" (Action-Level Object BOLA) هي فئة ثغرات مهيمنة ولكنها غير ممثلة بشكل كافٍ، ومثبتةً أن الاعتماد على وسوم المنصات يبالغ بشكل كبير في تقدح مدى انتشار ثغرة "كسر صلاحيات الوصول إلى مستوى الكائن" (Broken Object Level Authorization).
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
تخيل أنك تسير عبر مجمع سكني ضخم ومتطور تقنياً. لديك بطاقة مفتاح تسمح لك بدخول المبنى (المصادقة)، ولكن الأمن الحقيقي يُفترض أن يكون في التحقق من أي شقة محددة يُسمح لك بدخولها.
كسر تفويض مستوى الكائن (BOLA) هو ما يحدث عندما ينسى حارس الأمن في المبنى التحقق من بطاقة مفتاحك مقابل رقم الشقة التي تحاول فتحها. قد تكون مقيماً صالحاً، لكنك تحاول فتح الشقة 402، فيقول لك الحارس ببساطة: "بالتأكيد، تفضل"، دون التحقق مما إذا كانت الشقة 402 تخصك أم لا.
هذه الورقة البحثية هي تحقيق واسع النطاق في 107 تقارير أمنية واقعية من برنامج مكافآت الثغرات (حيث يتقاضى المخترقون مكافآت مقابل العث lập ثغرات). أراد الباحثون تجاوز النصائح الأمنية "النظرية" والنظر إلى ما يحدث فعلياً في العالم الحقيقي.
إليك تفصيل نتائجهم، باستخدام تشبيهات بسيطة:
1. مشكلة "ضجيج الملصقات" (الإنذارات الزائفة)
بدأ الباحثون بالنظر في 200 تقرير تم تصنيفها كـ "IDOR" (اسم شائع لهذا النوع من الثغرات) على منصة HackerOne.
- النتيجة: 42% فقط من تلك التقارير كانت حقيقية بالفعل.
- التشبيه: تخيل نظام إنذار حريق يعمل 200 مرة. وجد الباحثون أنه في 39% من الحالات، لم يكن هناك حريق على الإطلاق، بل كان مجرد شخص يحرق الخبز، أو حماماً بخارياً، أو مستشعراً معطلاً.
- الخلاصة: مجرد كون النظام مصنفاً كـ "IDOR" لا يعني بالضرورة وجود هذه الثغرة المحددة والخطيرة لـ "كسر الكائن". فرق الأمن غالباً ما تبالغ في تقدير المخاطر لأنها تثق في التصنيفات أكثر مما ينبغي.
2. الشريران الرئيسيان (التصنيف)
قام الباحثون بتصنيف الثغرات الحقيقية إلى ست فئات. وكان هناك نوعان منهما هما الأكثر بروزاً، حيث شكلا ما يقرب من 80% من جميع الحالات:
الشرير (أ): "الإشارة المباشرة للكائن" (خدعة دفتر الهاتف)
- ما هي: ترى رابطاً مثل
website.com/invoice/101. تقوم بتغيير الرقم إلى102وفجأة ترى فاتورة شخص آخر. - التشبيه: الأمر يشبه السير أمام صف من صناديق البريد. أنت تعرف أن صندوقك هو رقم 101. تجرب رقم 102، فتجد القفل مكسوراً، فتفتح الصندوق وتقرأ بريد جارك.
- التكرار: حدث هذا في 37% من الحالات.
- ما هي: ترى رابطاً مثل
الشرير (ب): "كائن مستوى الإجراء" (المخرب)
- ما هي: هذه هي المفاجأة الكبرى. الأمر لا يتعلق فقط بـ قراءة بيانات شخص آخر؛ بل يتعلق بـ تغيير أو حذف تلك البيانات.
- التشبيه: تذهب إلى صندوق بريد جارك (الذي لا يُفترض بك لمسه)، وبدلاً من مجرد قراءة البريد، تقوم بخلع صندوق البريد عن الجدار، أو حذف رسائل بريده الإلكتروني، أو تحويل أمواله.
- التكرار: حدث هذا في 42% من الحالات.
- لماذا يهم هذا: معظم الأدلة الأمنية تركز على "قراءة" البيانات. تقول هذه الورقة: "مهلاً، المجرمون في الواقع يقومون بتدمير وتغيير البيانات أكثر مما يكتفون بمجرد التجسس".
3. الأشرار المتسللون الآخرون
الـ 20% المتبقية من الثغرات كانت أكثر تعقيداً:
- عزل المستأجرين: أنت في مبنى مكاتب مشترك. تحاول فتح باب مكتب شركة أخرى، وتفشل عملية القفل.
- سياق سير العمل: تم فصلك من شركة، لكن النظام لا يزال يسمح لك بالوصول إلى الملفات "المؤرشفة" لمشروع كنت تعمل عليه لأن النظام نسي تحديث حالتك.
- الكشف المتسلسل: لا يمكنك تخمين المعرف (ID)، لكنك تجد قائمة بالمعرفات في جزء آخر من التطبيق (مثل إيصال)، وتستخدم هذه القائمة لاختراق حسابات أشخاص آخرين.
- إعادة ربط الكائن: تخدع النظام لجعله يعتقد أنك تملك الكائن عن طريق تغيير حقل مخفي في الطلب (مثل تغيير اسم "المالك" على مستند).
4. المفاجأة "الرأسية" (رحلة المصعد)
عادةً ما نفكر في هذه الهجمات على أنها "أفقية" (مستخدم (أ) يسرق من مستخدم (ب)).
- النتيجة: في 12% من الحالات، تمكن مستخدم عادي من الوصول إلى أشياء أو حذف أشياء تخص مسؤول النظام (Administrator).
- التشبيه: مستأجر عادي في المجمع السكني يتمكن من الدخول إلى المكتب الخاص بمدير المبنى وحذف المفاتيح الرئيسية.
- الخلاصة: هذه مخاطرة كبيرة يتجاهلها معظم قوائم التدقيق الأمنية لأنهم يفترضون أن "المسؤولين في أمان".
5. المعرفات "السحرية" لا تعمل
يعتقد المطورون غالباً أنهم إذا لم يستخدموا أرقاماً بسيطة مثل 1، 2، 3، ولكن استخدموا بدلاً منها أكواداً طويلة وعشوائية (UUIDs) أو سلاسل نصية مشفرة، فإنهم سيكونون في أمان.
- النتيجة: 39% من الهجمات الناجحة استخدمت هذه المعرفات "المعقدة".
- التشبيه: وجد الأشرار طريقة لفك تشفير "الرمز السري" على صندوق البريد، وأدركوا أنه مجرد رقم مخفي، ثم قاموا ببساطة بزيادة الرقم للوصول إلى صندوق البريد التالي.
- الخلاصة: إخفاء المعرف لا يحل المشكلة. لا يزال على الخادم التحقق مما إذا كنت تملك الكائن، بغض النظر عن شكل المعرف.
6. ثغرة "GraphQL"
وجدت الورقة أن العديد من التطبيقات الحديثة تستخدم نظاماً يسمى GraphQL. تستخدم هذه الأنظمة "معرفات عالمية" (مثل gid://hackerone/Report/123).
- النتيجة: اكتشف المهاجمون أنه إذا قاموا بفك تشفير هذه المعرفات، فإنها تكشف عن الأرقام المتسلسلة الكامنة تحتها، مما يسمح لهم بتخمين المعرف التالي بسهولة.
- الخلاصة: مجرد كون المعرف عبارة عن سلسلة معقدة من الحروف لا يعني أنه عشوائي.
ملخص للشخص العادي
تخبرنا هذه الورقة أننا:
- لا تثق في التصنيفات: مجرد كون النظام مصنفاً بوجود ثغرة معينة لا يعني أنه مكسور فعلياً بهذه الطريقة المحددة.
- الأشرار تدميرين: هم لا يسرقون البيانات فحسب؛ بل يقومون بحذفها وتغييرها أكثر مما كنا نظن.
- الأكواد السرية ليست كافية: استخدام معرفات معقدة لا يوقف المخترقين إذا كان الخادم لا يتحقق من مالك البيانات.
- المستخدمون العاديون يمكنهم إلحاق الضرر بالمسؤولين: حساب مستخدم عادي يمكنه أحياناً اختراق أشياء "المدير".
تخلص الورقة إلى أن اختبار الأمن يجب أن يتغير. نحن بحاجة للتوقف عن مجرد التحقق مما إذا كان بإمكانك قراءة بيانات شخص آخر، والبدء في التحقق مما إذا كان بإمكانك حذف أو تغيير تلك البيانات، كما نحتاج لاختبار ما إذا كان المستخدمون العاديون يمكنهم -سواء بقصد أو بدون قصد- اختراق أشياء المسؤولين.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.