تُعد ثغرة IDOR أو ما يعرف باسم Insecure Direct Object Reference من أشهر ثغرات التحكم في الصلاحيات داخل تطبيقات الويب وواجهات API. تظهر هذه الثغرة عندما يسمح النظام للمستخدم بالوصول إلى بيانات أو ملفات أو حسابات لا تخصه، وذلك عبر تغيير رقم المستخدم أو رقم الملف أو أي معرّف آخر داخل الطلب.
العثور على IDOR لا يعني تلقائيًا الحصول على مكافأة كبيرة، لأن قيمة التقرير تعتمد على نوع البيانات المتأثرة، مستوى الصلاحيات المطلوبة، وضوح خطوات إعادة الاستغلال، والأثر الحقيقي على المستخدمين أو الشركة. فيما يلي مجموعة من أقوى عناوين تقارير IDOR مع شرح مختصر لكل حالة.
🔴 Unauthenticated IDOR Allows Access to Sensitive User Documents
تعني أن المهاجم يستطيع الوصول إلى مستندات حساسة تخص مستخدمين آخرين دون تسجيل الدخول، مثل العقود، الفواتير، ملفات الهوية أو المستندات الخاصة. وتكون الخطورة أكبر لأن الهجوم لا يحتاج إلى حساب داخل الموقع.
🔴 Cross-Account IDOR Exposes Private Customer Data
تسمح هذه الثغرة لمستخدم مسجل بالدخول إلى بيانات حساب مستخدم آخر عن طريق تغيير معرّف الحساب داخل الرابط أو طلب API. قد تشمل البيانات الاسم الكامل، البريد الإلكتروني، رقم الهاتف، العنوان أو معلومات شخصية أخرى.
🟠 IDOR Allows Unauthorized Modification of Another User’s Account
في هذه الحالة لا يقتصر التأثير على قراءة البيانات، بل يستطيع المهاجم تعديل معلومات حساب شخص آخر، مثل الاسم، رقم الهاتف، العنوان، الإعدادات أو البيانات المرتبطة بالحساب دون امتلاك الصلاحية المناسبة.
🔴 IDOR Enables Permanent Deletion of Other Users’ Files
تسمح الثغرة بحذف ملفات تخص مستخدمين آخرين بشكل دائم عبر تغيير معرّف الملف داخل طلب الحذف. هذا النوع من الثغرات يسبب فقدان البيانات وقد يؤثر على مستندات مهمة أو ملفات لا يمكن استرجاعها.
🔴 Broken Object Level Authorization Allows Account Takeover
تظهر هذه الحالة عندما يؤدي ضعف التحقق من صلاحيات المستخدم إلى السيطرة على حساب شخص آخر. يجب استخدام هذا العنوان فقط عندما يثبت الباحث إمكانية تغيير البريد الإلكتروني أو كلمة المرور أو إعدادات الأمان والوصول الكامل إلى الحساب.
🔴 IDOR Exposes Payment and Billing Information Across Accounts
تسمح الثغرة بالوصول إلى معلومات الدفع والفواتير الخاصة بحسابات أخرى، مثل تفاصيل المعاملات، مبالغ الشراء، عناوين الفوترة أو بيانات مالية حساسة. وترتفع الخطورة حسب كمية ونوع المعلومات المكشوفة.
🔴 IDOR Allows Unauthorized Withdrawal or Transfer of Funds
تُعد من أخطر حالات IDOR، حيث يستطيع المهاجم تنفيذ عملية سحب أو تحويل أموال من حساب شخص آخر من خلال التلاعب بمعرّف المحفظة أو الحساب أو المعاملة. يجب إثبات هذا النوع فقط باستخدام حسابات اختبارية وتحت تصريح واضح من البرنامج.
🔴 IDOR Enables Privilege Escalation to Administrator
تسمح هذه الثغرة للمستخدم العادي بالحصول على صلاحيات إدارية عبر تعديل معرّف الدور أو المستخدم أو أحد الكائنات المرتبطة بالصلاحيات. قد يؤدي ذلك إلى الوصول إلى لوحة الإدارة، إدارة المستخدمين أو التحكم في وظائف حساسة.
🔴 Cross-Tenant IDOR Exposes Confidential Organization Data
يظهر هذا النوع غالبًا في المنصات التي تخدم عدة شركات أو مؤسسات. تسمح الثغرة لمستخدم تابع لمؤسسة بالوصول إلى بيانات مؤسسة أخرى، مثل ملفات الموظفين، التقارير الداخلية، العقود أو المعلومات التجارية السرية.
🔴 IDOR Allows Unauthorized Access to Medical or Identity Documents
تسمح الثغرة بالوصول إلى وثائق طبية أو وثائق إثبات الهوية الخاصة بأشخاص آخرين. تشمل الأمثلة التقارير الطبية، جوازات السفر، بطاقات الهوية أو وثائق التحقق من الشخصية، ولهذا يكون تأثيرها مرتفعًا بسبب حساسية البيانات.
🟠 IDOR in API Endpoint Exposes Full User Profiles Without Authorization
تظهر الثغرة داخل أحد مسارات API عندما يستطيع المهاجم تغيير معرّف المستخدم والحصول على ملفه الشخصي الكامل. قد يتضمن الرد بيانات شخصية، معلومات الحساب، حالة التحقق أو تفاصيل غير مخصصة للعرض العام.
🔴 Unauthenticated IDOR Allows Modification of Any User Resource
تعني أن المهاجم غير المسجل يستطيع تعديل مورد يخص أي مستخدم، مثل ملف أو عنوان أو طلب أو إعداد داخل الحساب. ويعد هذا النوع شديد الخطورة لأن التطبيق يسمح بتنفيذ عملية تعديل دون التحقق من هوية المهاجم أو ملكيته للمورد.
كيف تكتب عنوانًا احترافيًا لتقرير IDOR؟
العنوان القوي يجب أن يوضح مستوى الوصول، نوع الثغرة، العملية غير المصرح بها، والبيانات أو الوظيفة المتأثرة. مثال مناسب:
Unauthenticated IDOR Allows Permanent Deletion of Other Users’ Documents
هذا العنوان يوضح أن الهجوم لا يحتاج إلى تسجيل الدخول، وأن التأثير هو الحذف الدائم، وأن الملفات المتأثرة تخص مستخدمين آخرين.
لا تستخدم عبارات مثل Account Takeover أو Admin Access أو Financial Loss إلا عندما يكون لديك دليل واضح يثبت هذا التأثير. المبالغة في العنوان قد تضعف التقرير، بينما العنوان الدقيق يساعد فريق التقييم على فهم الثغرة بسرعة.
🟢 الخلاصة
قوة تقرير IDOR لا تعتمد على الاسم وحده، بل تعتمد على إثبات أن المستخدم يستطيع قراءة أو تعديل أو حذف مورد لا يملكه. التقرير الجيد يحتوي على طلب المستخدم المهاجم، طلب المستخدم المتضرر، المعرف الذي تم تغييره، النتيجة قبل الاستغلال وبعده، وشرح واضح للتأثير الأمني.
يجب إجراء جميع الاختبارات داخل برامج Bug Bounty المصرح بها فقط، مع استخدام حسابات وبيانات تجريبية وتجنب الوصول إلى بيانات حقيقية أكثر من الحد الضروري لإثبات الثغرة.
إعداد: MONSTR M1ND
Instagram: @httpx.mrmonsif
