(IDOR) هو ثغرة أمنية للتحكم في الوصول حيث يمكن استخدام مدخلات المستخدم غير المؤكدة للوصول غير المصرح به إلى الموارد أو العمليات، حيث يمكن أن يكون لـ (IDOR) عواقب وخيمة على الأمن السيبراني ويصعب العثور عليها ولكن من السهل استغلالها.
- “IDOR” اختصار ل”Insecure Direct Object Reference”.
IDORs في العمل
تحدث الثغرة الأمنية المرجعية المباشرة للكائن عند استيفاء ْثلاثة شروط وهما، ان يكشف التطبيق عن إشارة مباشرة إلى مورد داخلي أو عملية وان يمكن للمستخدم معالجة عنوان (URL) أو معلمة النموذج لتعديل المرجع المباشر وان يمنح التطبيق حق الوصول إلى الكائن الداخلي دون التحقق مما إذا كان المستخدم مخولًا أم لا.
في حين أن كل هذا يبدو رسميًا للغاية، إلا أنه يمكن أن يكون بسيطًا جدًا أيضًا، على فرض أن أحد المتاجر عبر الإنترنت يرسل للمستخدم بريدًا إلكترونيًا يحتوي على رمز ترويجي شخصي لمرة واحدة لإنفاق مبلغ معين في المتجر، ثم يقوم بمعالجة عنوان (URL) بدون التحقق مما إذا كان المستخدم الحالي مؤهلاً بالفعل للحصول على الخصم الترويجي المحدد، إذا تمت رؤية هذا أثناء الخروج، فقد يميل المستخدم إلى كتابة رموز ترويجية أخرى لمعرفة ما سيحدث.
- “URL” اختصار ل”Uniform Resource Locator”.
أنواع IDOR
سواء من خلال عناوين (URL) أو معلمات النموذج، يمكن للتطبيقات الكشف عن الكثير من تفاصيل التنفيذ الداخلية، يمكن استخدام بعض المعلمات، لتحقيق منفعة مالية مباشرة، قد يتم استخدام الآخرين لاستخراج البيانات الحساسة أو تصعيد امتيازات الوصول، اعتمادًا على احتمالات الهجوم التي توفرها، يمكن تقسيم ثغرات (IDOR) تقريبًا إلى أربع فئات على الرغم من أنها تتداخل في الممارسة العملية:
- الحصول على وصول غير مصرح به إلى البيانات: قد تكشف مراجع الكائنات المكشوفة معرفات قاعدة البيانات المباشرة، مما يسمح للمهاجمين باسترداد سجلات قاعدة البيانات التي تحتوي على معلومات حساسة، كما يمكن أيضًا استخدام أسماء وقيم مفاتيح قاعدة البيانات لإعداد حمولات حقن (SQL).
- “SQL” اختصار ل”Structured Query Language”.
- تنفيذ عمليات غير مصرح بها: من خلال معالجة قيم معرف المستخدم أو أسماء الأوامر أو مفاتيح واجهة برمجة التطبيقات التي لم يتم التحقق منها، حيث يمكن للمهاجمين تنفيذ عمليات غير مصرح بها في التطبيق. يمكن أن تشمل الأمثلة فرض تغيير كلمة المرور لتولي حساب المستخدم، وتنفيذ أوامر إدارية لإضافة مستخدمين أو تصعيد الامتيازات والحصول على إمكانية الوصول إلى واجهات برمجة تطبيقات أو ميزات التطبيقات المدفوعة أو المحدودة السعر.
- معالجة كائنات التطبيق: يمكن أن يسمح الوصول إلى مراجع الكائنات الداخلية للمستخدمين غير المصرح لهم بتغيير الحالة الداخلية وبيانات التطبيق، نتيجة لهذه الثغرة الأمنية، قد يتلاعب المهاجمون بمتغيرات الجلسة، على سبيل المثال لتغيير البيانات أو رفع الامتيازات أو الوصول إلى وظائف مقيدة.
- الحصول على وصول مباشر إلى الملفات: يتيح هذا النوع من (IDOR)، الذي يقترن عادةً مع اجتياز المسار، للمهاجمين معالجة موارد نظام الملفات، حيث قد يسمح لهم ذلك بتحميل الملفات أو التلاعب ببيانات المستخدمين الآخرين أو تنزيل المحتوى المدفوع مجانًا.
كشف ثغرات IDORs
بالنسبة لأي باحث أمني جاد، فإن رؤية معرف داخلي مكشوف هو دعوة فورية لاختبار ثغرات (IDOR)، خاصةً لأنها مصدر قوي لمكافآت الأخطاء، لتحديد مرجع كائن يحتمل أن يكون غير آمن، يجب أن يكون لدى المستخدم فكرة عن كيفية عمل تطبيق أو موقع ويب معين وكيفية معالجته لطلبات (HTTP) وهو بروتوكول نقل النص الفائق أو بروتوكول نقل النص التشعبي، وما هي المعلومات التي يجب ولا يجب الكشف عنها في استجابات (HTTP) الخاصة به، قد يكون اكتشاف معرفات (IDOR) أمرًا صعبًا خاصة بالنسبة إلى نقاط الضعف الأكثر تقدمًا والتي تتضمن تمرير البيانات عبر واجهات برمجة التطبيقات.
- “HTTP” اختصار ل”Hyper Text Transfer Protocol”.
منع ثغرات IDOR
في حين أنها لا تعالج السبب الجذري لثغرات (IDOR)، إلا أن هناك عدة طرق للتخفيف من المخاطر التي تشكلها المراجع المباشرة، حيث تتمثل الطريقة الأولى في استبدالها في مراجع الكائنات المباشرة التي يتم بعد ذلك تعيينها داخليًا إلى كائنات فعلية، قد يعني هذا استخدام خريطة مرجعية مؤقتة لكل جلسة يتم ملؤها فقط بقيم صالحة لمستخدم معين ومرتبطة بمفاتيح عشوائية غير متسلسلة، كما يعد استخدام التجزئة الآمنة بدلاً من مراجع الكائنات الفعلية طريقة أخرى تجعل من الصعب على المهاجمين التلاعب بالقيم التي يمكن للمستخدم التحكم فيها، هاتان الطريقتان فعالتان في إخفاء تفاصيل التنفيذ الداخلية ولكنهما لا تعالجان مشكلة التحكم في الوصول الأساسية، يتمثل النهج الأكثر قوة للتخلص من ثغرات (IDOR) في ضمان الإدارة المناسبة للجلسة والتحقق من التحكم في وصول المستخدم على مستوى الكائن، بهذه الطريقة، حتى إذا تمكن المهاجم المصمم من اكتشاف مرجع كائن داخلي والتلاعب به، فلن يحصل على وصول غير مصرح به.
استخدام خريطة مرجعية غير مباشرة
الخريطة المرجعية غير المباشرة هي طريقة تصميم بديلة لمرجع الكائن المباشر الذي يساعد الشركات على تجنب نقاط ضعف (IDOR)، إنه يستبدل المراجع الفعلية مثل معرفات المستخدم والأسماء والمفاتيح وما إلى ذلك بمعرفات بديلة يتم تعيينها للقيم الأصلية، كما تتم المحافظة على التعيين بين المعرفات البديلة والمراجع الفعلية بأمان على الخوادم.
التحقق من صحة وصول المستخدم
تفشل الخوادم في تحديد عناوين (URL) التي تم العبث بها نظرًا لعدم وجود عمليات تدقيق وصول على مستوى كائن البيانات، حيث يجب فرض ضوابط الوصول إلى طبقة البيانات فقط عندما يتحقق الخادم مما إذا كان المستخدم الحالي يمتلك أو لديه أذونات الوصول إلى البيانات المطلوبة، على الأقل، يجب أن يقوم التطبيق بإجراء التحقق النحوي للتحقق من المدخلات المشبوهة ويجب أن يضع التطبيق معايير للإدخال الوارد، وإذا لم يلبي التوقعات، يجب رفض القيمة.
حيث ان هنالك عدة معايير التي يمكن تطبيقها على الطلب منها، الطول الأدنى أو الأقصى والحدود الدنيا أو القصوى للقيم الرقمية والشخصيات المقبولة ونوع البيانات، على سبيل المثال، سلسلة، تاريخ، عدد صحيح وغيرها، كما يمكن للإجراءات الوقائية المذكورة أعلاه فقط منع هجوم (IDOR) من الحدوث، لكنها لا تخفف من تأثير هجوم ناجح، يجب أن يكون العمل جاهزًا لأي موقف هجوم إلكتروني، وهذا يتضمن وجود خطة عمل لنشر هجوم (IDOR).
