بداية ثغره IDOR وشرح الثغره
ثغره IDOR وهذا الأسم هو اختصار لـ Insecure Direct Object Reference
وهذا الخطأ الذي يقع فيه المبرمج والذي يسألك فيه "من أنت ؟" ويكتفي بذلك وهذا
نسميه بالـ Authentication ، وينسى أن يقوم بسؤالك "ليك الحق ماذا تفعل" وهذا
نسميه Authorization المسأله تدور حول ان النظام يستخدم معرفات مباشره (Direct
References) مثل رقم تسلسل في DB لكي يستطيع الوصول الى الموارد، ويتجاوز
الأمان الظاهري للعملية تسجيل الدخول، المهاجم هنا لا يحتاج الى ذكاء خارق ولا
ادوات معقده، هو فقط يحتاج الى تغيير قيمة المعرف في الطلب، ويرى كيف سيتعامل
مع النظام (بس كده)، منظومه OWASP قامت بأضافتها في اول القائمة في سنة 2007،
ومع الوقت تمت اضافتها في ثغرات بقئه اسمها (Broken Access Control) وهي صاحبة
المركز الأول في قائمة المخاطر العالمية لسنة 2021 و 2025،
تشريح الثغرة "بالتفصيل": ليه الكود بيطلع بهذا الخطأ ؟
اذا قومنا بتفكيك الثغره كما هي ونبدأ في تحليل السبب الحقيقي خلف الثغره، سنكتشف ان المبرمج يعتمد على منطق ومفهوم ضعيف يفترض فيه ان المستخدم اذا معه الـ Session فهذا يعني ان المورد المطلوب هو ملكه بالفعل ومن حقه ان يطلبه، الخلل هنا يحدث عندما يأخذ الكود رقم الـ ID الخاص بالمستخدم من المتصفح وينفذ به أستعلام مباشر في قاعدة البيانات من دون ان يراجع العلاقه بين المستخدم وبين السجل.
الكود المصاب مكتوب هكذا:
SELECT * FROM invoices WHERE id = $id
وهذا بمثابه مشكلة برمجية كبيره في قاعده البيانات، والسبب في هذا يرجع لان المورد المطلوب لأي ID وهذا بمجرد ان يقوم بتغيير الرقم الـ ID، بينما يا صديقي ان اذا اردنا حل هذا الكود فيجب اضافه شرط التأكد من الملكية تكون للمسؤول او المالك ويكون بهذا الشكل:
AND owner_id = $session_user_id
خطأ كهذا من الممكن ان يسبب مشكلة حقيقيه في الـ APIs والـ Mircoservices تحت
اسم BOLA وهو اختصار لـ Broken Object Level Authorization، وهذا لأن الـ APIs
بيطبيعتها تعرض المعرفات كثيره جداً من أجل تطبيقات الموبايل لكي تتواصل مع
السيرفر، وهذا يفتح باب ليتحول السيرفر الى ملكية عامه لجميع المهاجمين اي شخص
يستطيع ان يفعل ما يريده، وهذا سيحدث اذا لا يوجد اي رقابه قويه في جميع الـ
Endpoint
المهاجم بيلعب إيه؟ فنون التلاعب وسيناريوهات الاختراق
الهدف الاساسي للمهاجم هي الـ Data، في اكثر من مكان، وتركيزه الاساسي مع الطلبات الذي يتم ارسالها واستقبالها (Http Traffic) وطبعاً بأستخدام الاداه العزيزه على كل المختبرين Burp Suite، ويتم استخدامها في البحث على اي IDs واضحه، وهذا يحدث من خلال التلاعب في URL (ودي اشهر حاجة على فكرة)، ومن الممكن استخدام Request Body اذا البيانات يتم ارسالها بأستخدام json، او حتى الـ Cookies والـ Headers الذي يرسلها المتصفح من دون علم المستخدم، طبيعه الهجوم يا صديقي انه لديه اكثر من اتجاه مثلاً عندما يبدأ المهاجم في سرقة داتا من مستخدم في نفس مستوى الصلاحيات، او عندما يطمع في صلاحيات الـ Admin ويقوم بالوصول في للوحة التحكم عبر البحث عن حسابات admins، وهناك نوع خبيث وغير واضح اسمه Idor blind وهو الماهجم لا يستطيع رؤية البيانات امامه، لكن يحاول ان يجعل السيرفر يقوم برده فعل بسيطه بالنيابة عن اي احد اخر مثلاً ان يقوم بعمل delete account او يقم بتغيير الأعدادات ويرى رده فعل السيرفر.
دروس قاسية من أرض الواقع: لما الكبار بيقعوا
الشركات الكبيره اخذت دروس قاسيه في هذا، والعائد في هذا اخطاء المبرمجين، والتجارب والقصص الخاصه بيهم هي دروس مجانيه، كمثال شركة كبيره مثل Facebook دفعت 12,500 دولار مكافأه لباحث استطاع اكتشاف ثغره IDOR كانت تسمح بمسح اي ألبوم صور على الموقع بمجرد تغيير الـ ID الخاص به في الـ Graph API والنظام كان يثق في أي Token (يسلام لو في من الثغره دي كثير)، قادم من اي تطبيق موبايل ومن دون اي مراجعه ملكية الآلبوم.
شركه الطيران بونايتد United Airlines ليست ثغره جعلت باحث يرى بيانات رحلات المستخدمين، وعناوينهم وحتى تفاصيل دفعهم، لكن كما نعرف عن الثغره ان يجب ان يتواجد الـ impact، كان المهاجم يستطيع ان يلغي اي رحله طيران هو يريدها بأختياره بضغه واحده لمجرد ان رقم mpNumber كان يتم ارساله كمرجع مباشر من دون فحص او ومن دون مراجعه صلاحيات.
ليس هذا فقط، هناك ايضاً GitLap في 2024 تم اكتشاف ثغره بتسريب موديلات ذكاء اصطناعي لشركات اخرى من اجل شركات اخرى من اجل معرفات كانت تسلسليه (1, 2, 3) ومن السهل توقعها من طرف اي مهاجم، وبعدها تبدأ مرحله سحب اي بيانات خاصة.
وأخيراً بوابة الضرائب الهندية التي عرضت بيانات 135 مليون مواطن للخطر لنفس السبب البسيط في التلاعب برقم حساب الضريبي (المقصود ID)
الخسائر من تسريب اي بيانات للمطرقة القانونيه
تأثير ثغره IDOR ليس مجرد حركة بسيطة ولا مجرد بيانات مسربه، تأثير الثغره كبيره على جميع المنصات تسببت في زلزال مؤثر على مستوى الشركات، بدايتاً من تسريب اي معلومات خاصة او مشاريع أو سجلات طبيه او بنكية او رسائل خاصه اي شخص يستطيع رؤيتها، وهذا يؤثر على سمعه الشركة ويجعلها في الأرض في ثوان، ثاني شيء هو التخريب المتعمد والتحكم الكامل، لأن المهاجم يستطيع تسبب في Impact مختلف على الحساب مثل تغيير Password او تغيير حسابات المديرين ويسيطر على التطبيق بالكامل
(كل ده تحت مصطلح Account Takeover)، وثالث شيء هي الكابوس المالي والعقاب القانوني، في مصر حالياً يوجد قانون حماية البيانات الشخصية الجديد رقم 151 لسنه 2020 والذي يفرض غرامات تصل الى لـ 5 مليون جنيه ومساءله جنائيه اذا اهملت الشركات في تامين بيانات المصريين اما دولياً فهناك غرامات الـ GDPR في اوروبا وصلت الان لمليارات لشركات مثل Uper و TikTok لأنهم فشلوا تطبيق مبدأ الأمان بالتصميم، وتركوا جميع Endpoint مصابه.
سد الثغرات: إزاي تبني سيستم "ناشف" ضد الـ IDOR
الضوابط الأمنية لأغلاق باب الـ IDOR تأتي من المبرمج ويغير مفهومه تماماً، علاج الثغره من الجذور، هي الفحص الألزامي للملكية في كل طلب Object-Level Authentication Check بمعنى أخر لا يوجد شيء اسمه ثقه لأي مستخدم قام بعمل Login على السيرفر يتاكد من كل حركة وان هذا المستخدم يمتلك البيانات والصلاحيات اللازمه، واستخدام المعرفات المعقده UUIDs وهو يعتبر خط الدفاع اضافي.
مفهوم Defense-in-Depth، بسبب التخمين يكون شبه مستحيل لكنها ليست البديل عن الفحص لأن الـ UUIDs من الممكن ان يتسرب في اماكن اخرى، واقوى حل تقني هو الـ Indirect Reference Maps، السيرفر هنا يعطي للمستخدم رمز مؤقت خاص بالجلسة فقط، والسيرفر هو الذي يترجم الرمز للـ ID الحقيقي، واذا قام المهاجم بسرقة الرمز وجربه على حسابه لن يجد أي معنى، ويجب ان تتذكر ان برامج الفحص الاوتوماتيك (Scanner) غالباً لا ترى الـ IDOR لأنه ثغره منطقية يحب على المهاجم هو من يجرب على بنفسه ويفهم الـ Logic الخاصه به لكي يصل الى الثغره المختبئه.
