ما هي ثغرة IDOR وكيف تحمي صلاحيات الوصول؟
الكاتب: فريق تحرير Domeny.ForSale تاريخ النشر
باختصار: IDOR (Insecure Direct Object Reference)، أي الإشارة المباشرة غير الآمنة إلى كائن، ثغرة تتيح فيها التطبيقات الوصول إلى مورد يخص شخصًا آخر بمجرد تحديد معرّفه، دون التحقق من الصلاحيات كما ينبغي. على سبيل المثال، يغيّر المستخدم رقم الفاتورة في العنوان فيطّلع على مستند يخص عميلًا آخر. ليست المشكلة في وجود الرقم داخل العنوان، بل في أن الخادم لا يتحقق من حق هذا المستخدم في الوصول إلى الفاتورة.
كيف تعمل ثغرة IDOR — مثال بسيط
تخيّل لوحة عميل يمكنك من خلالها تنزيل فاتورتك بعد تسجيل الدخول. يرسل المتصفح إلى الخادم طلبًا للمسار /fawatir/481، فيعيد التطبيق المستند رقم 481.
استخدام عنوان كهذا أمر طبيعي بحد ذاته. تظهر الثغرة عندما يتيح تغيير المسار إلى /fawatir/482 تنزيل فاتورة عميل آخر، رغم أنك لم تُمنح صلاحية الوصول إليها.
يشبه ذلك موظفًا في غرفة حفظ المعاطف يسلّم المعطف لأي شخص يذكر رقم العلّاقة، بدلًا من التحقق من حقه في استلامه. فالرقم يحدد الغرض، لكنه لا يثبت الحق في الحصول عليه.
تعني كلمة «كائن» في اسم IDOR هنا أحد موارد التطبيق: مستندًا أو طلب شراء أو صورة أو رسالة أو حسابًا. وتعني «الإشارة المباشرة» تحديد ذلك المورد بواسطة معرّف. وليس من الضروري أن يكون المعرّف رقمًا متسلسلًا؛ فقد يكون اسم ملف أو عنوان بريد إلكتروني أو سلسلة طويلة من المحارف.
لماذا لا يكفي تسجيل الدخول وحده
تجيب المصادقة عن سؤال: «من أنت؟». أما التفويض، أي التحقق من الصلاحيات، فيجيب عن سؤال آخر: «ما الذي يُسمح لك بفعله؟». قد يتعرّف التطبيق إلى المستخدم المسجّل دخوله بشكل صحيح، ومع ذلك يتيح له الوصول إلى بيانات الآخرين.
ينبغي للخادم الآمن ألا يكتفي بالتحقق من وجود الفاتورة، بل أن يتحقق أيضًا من صلاحية المستخدم لقراءتها. وقد يستند حق الوصول إلى ملكية المستند، أو دور المستخدم في المؤسسة، أو قرار مقصود بمشاركة المستند مع شخص آخر.
لا تقتصر ثغرة IDOR على الاطلاع على المعلومات. فقد يتيح غياب التحقق أيضًا تعديل مورد يخص شخصًا آخر أو حذفه، مثل تغيير عنوان التسليم في طلب شراء. ولا تعني صلاحية القراءة تلقائيًا امتلاك صلاحية التعديل، لذا تتطلب كل عملية تحققًا مناسبًا.
إذا كان التطبيق يخدم عدة شركات، فمن المهم أيضًا مراعاة الحدود الفاصلة بين المؤسسات. يجب ألا يتمكن مسؤول في شركة من الوصول إلى بيانات شركة أخرى لمجرد معرفته بمعرّف أحد مستنداتها.
أين قد يوجد المعرّف المرتبط بالثغرة
ليس من الضروري أن يظهر المعرّف في شريط العنوان. فقد يكون ضمن معاملات الاستعلام، أو في محتوى طلب يرسله نموذج، أو في استدعاء API، وهي واجهة تُستخدم للتواصل بين البرامج.
من العمليات الشائعة التي تتطلب التحقق من الصلاحيات:
- تنزيل الفواتير والمرفقات وملفات تصدير البيانات؛
- قراءة الرسائل والتذاكر وطلبات الشراء؛
- تحديث الملف الشخصي أو إعدادات الحساب؛
- حذف الملفات وغيرها من الموارد.
لا يعني كل وصول يتحقق بعد تغيير المعرّف وجود خطأ. فمن المفترض أن تكون تدوينة عامة متاحة للجميع، وأن يكون المستند المشترك متاحًا للزملاء المخوّلين. ما يحدد وجود الثغرة هو انتهاك قواعد الوصول المقصودة، لا مجرد إمكانية تحديد كائن آخر.
تُوصَف أخطاء مشابهة في API أحيانًا باسم BOLA (Broken Object Level Authorization)، أي خلل في التحقق من الصلاحيات على مستوى كائن بعينه. والمفهومان وثيقا الصلة؛ إذ يظل السؤال العملي نفسه: هل يتحقق الخادم من حق المستخدم في الوصول إلى المورد المحدد وتنفيذ العملية المطلوبة؟
ما الذي يحمي فعلًا من IDOR
الحماية الأساسية هي التحقق من الصلاحيات على جانب الخادم عند كل محاولة للوصول إلى مورد. ولا يكفي إخفاء زر في الواجهة، لأن إرسال الطلب ممكن دون استخدام ذلك الزر.
في مثال الفواتير، ينبغي للتطبيق أن يبحث عن المستند ضمن مجموعة المستندات المتاحة للمستخدم المعني، أو أن يتحقق من الصلاحيات قبل إعادته. ويجب ألا يثق بحقل «المالك» الذي يرسله المتصفح بوصفه دليلًا على الملكية.
تصعّب المعرّفات العشوائية، مثل UUID، تخمين العناوين، لكنها لا تغني عن التحقق من الصلاحيات. فإذا تسرّب المعرّف، عبر رابط تمت مشاركته مثلًا، فلا يزال على الخادم رفض وصول أي شخص غير مخوّل.
من القواعد الجيدة اعتماد الرفض افتراضيًا: إذا لم يستطع التطبيق تأكيد حق المستخدم في تنفيذ عملية، فلا ينفذها. وينبغي أن يشمل التحقق تنزيل الملفات وتصدير البيانات أيضًا، لا الشاشة الرئيسية للمستند وحدها.
كيف تختبر تطبيقك بأمان
لا تُجرِ هذا الاختبار إلا على نظام تملكه أو لديك إذن باختباره. ومن الأفضل استخدام بيئة اختبار وبيانات وهمية، خصوصًا عند اختبار عمليات التعديل والحذف.
- أنشئ حسابَي اختبار: A وB، دون مشاركة أي موارد بينهما.
- أنشئ مستندًا باستخدام الحساب A، وسجّل معرّفه.
- سجّل الدخول بالحساب B وحاول قراءة المستند عبر الواجهة المخصصة لذلك أو عبر API.
- اختبر إمكانات التعديل والتنزيل والحذف كلًا على حدة، إن كانت هذه العمليات متاحة.
- لا تكتفِ بالتحقق من ظهور رسالة رفض، بل تأكد أيضًا من عدم كشف أي بيانات أو تغييرها.
ينبغي للخادم رفض العملية غير المسموح بها، وقد يتعمّد أيضًا عدم الإفصاح عما إذا كان المستند موجودًا. ومن المفيد إضافة هذا السيناريو إلى الاختبارات الآلية، حتى لا يؤدي تغيير في الشيفرة إلى عودة الثغرة.
اقرأ أيضًا
