تحليل معمق لثغرات IDOR في واجهات REST API

تُعدّ ثغرة المرجع المباشر غير الآمن (IDOR - Insecure Direct Object Reference) من أكثر الثغرات استغلالاً في تطبيقات الويب وواجهات API الحديثة. على الرغم من بساطتها المفاهيمية — يثق الخادم بمعرّف يقدمه المستخدم دون التحقق من ملكية المورد — فإن تأثيرها الفعلي هائل: وصول غير مصرح به إلى البيانات الشخصية والمالية والطبية والوظائف الإدارية. في قائمة OWASP API Security Top 10 لعام 2023، تُصنَّف IDOR باعتبارها API1:2023 Broken Object Level Authorization (BOLA)، وهي أعلى مخاطر API أولوية.

١. ما هي ثغرة IDOR؟

تنشأ ثغرة IDOR عندما يستخدم التطبيق قيمة يقدمها العميل — معرّف صحيح أو UUID أو اسم ملف أو تجزئة — لاسترداد مورد من جانب الخادم أو التعامل معه، دون التحقق من أن المستخدم الذي قدم الطلب مخوّل بالوصول إلى ذلك المورد تحديداً. الخلل هو قصور في التخويل بحت، وليس في المصادقة. المستخدم مسجّل دخوله بشكل مشروع؛ الخادم ببساطة لا يتحقق من الملكية.

المثال الكلاسيكي: يسجّل مستخدم دخوله بوصفه [email protected]، ويصل إلى ملفه الشخصي عبر /api/users/101/profile، ويلاحظ الرقم 101 في الرابط. تستبدله بـ 102. إذا أعاد الخادم ملف المستخدم 102 بدلاً من خطأ 403، فأنت أمام ثغرة IDOR.

٢. لماذا تكون واجهات REST API أكثر عرضة للخطر؟

تُكشف معرّفات الموارد في الروابط بصورة مقصودة في واجهات RESTful:

GET  /api/users/{userId}
GET  /api/orders/{orderId}
GET  /api/invoices/{invoiceId}
PUT  /api/documents/{docId}
DELETE /api/messages/{messageId}

هذه الروابط القابلة للتنبؤ تُيسّر اختبار IDOR مباشرة. المهاجم الذي يملك معرّفاً واحداً صالحاً لا يحتاج إلا إلى تعداد القيم المجاورة. المعرّفات الصحيحة المتسلسلة (1000، 1001، 1002...) قابلة للتكرار بشكل تافه.

٣. أنواع ثغرات IDOR

٣.١ IDOR بالمعرّف الرقمي

أبسط صورة. يجعل التسلسل الرقمي التعداد بالقوة الغاشمة أمراً هيناً.

# فاتورة الضحية
GET /api/invoices/1001 HTTP/1.1
Authorization: Bearer <رمز_صالح>

# IDOR: الوصول إلى فاتورة مستخدم آخر بتنقيص الرقم
GET /api/invoices/1000 HTTP/1.1
Authorization: Bearer <رمز_صالح>

٣.٢ IDOR بمعرّف UUID

يعتقد كثير من المطورين أن UUID يوفر أماناً بالغموض. لكن UUIDs ليست أسراراً — تظهر في روابط البريد الإلكتروني وتذاكر الدعم واستجابات API.

# UUID مسرَّب عبر GET /api/transactions
GET /api/accounts/f47ac10b-58cc-4372-a567-0e02b2c3d479/statement HTTP/1.1
Authorization: Bearer <رمز_صالح>

٣.٣ IDOR باسم الملف

GET /api/files/2026/alice_tax_return.pdf HTTP/1.1
Authorization: Bearer <رمز_صالح>

# محاولة:
GET /api/files/2026/bob_tax_return.pdf HTTP/1.1
Authorization: Bearer <رمز_صالح>

٣.٤ المرجع في جسم الطلب

DELETE /api/messages HTTP/1.1
Authorization: Bearer <رمز_صالح>
Content-Type: application/json

{"messageId": 42}

٤. طلبات HTTP كإثبات مفهوم

يوضّح المثال التالي تصعيداً أفقياً لصلاحيات عبر IDOR. المستخدم أ (id=123) مصادَق عليه بشكل مشروع:

# الخطوة ١ — طلب مشروع: المستخدم أ يقرأ ملفه الشخصي
GET /api/v1/users/123/profile HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.abc123

HTTP/1.1 200 OK
{"id":123,"name":"أليس","email":"[email protected]"}

# الخطوة ٢ — IDOR: المستخدم أ يقرأ ملف المستخدم ب (id=124)
GET /api/v1/users/124/profile HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.abc123

HTTP/1.1 200 OK   <-- يجب أن يكون 403
{"id":124,"name":"بوب","email":"[email protected]","creditCard":"****1234"}

٥. IDOR في المراجع غير المباشرة والمتقدمة

٥.١ تلوث المعاملات

GET /api/cart?userId=123&userId=456 HTTP/1.1

٥.٢ التباس مسار JSON

POST /api/profile/update HTTP/1.1
Content-Type: application/json

{
  "user": {
    "id": 123,
    "displayName": "أليس",
    "admin_override_id": 1
  }
}

٥.٣ IDOR في GraphQL

query {
  node(id: "VXNlcjoxMjQ=") {   # فك ترميز base64: "User:124"
    ... on User {
      email
      creditCard { number }
    }
  }
}

٦. أنماط IDOR الواقعية من برامج مكافأة الثغرات

تهيمن ثغرات IDOR على المدفوعات في منصتَي HackerOne وBugcrowd. أبرز الأنماط الشائعة:

واجهات API للطلبات والفواتير: تُكشف منصات التجارة الإلكترونية endpoint مثل /orders/{id} دون التحقق من الملكية، مما يتيح للمهاجمين حصد سجلات المشتريات وعناوين الشحن وبيانات وسائل الدفع.
نقاط نهاية السجلات الطبية: بوابات المرضى التي تستعلم عبر /patients/{id}/records دون التحقق من علاقة الطبيب أو المريض بالسجل.
نقاط نهاية تنزيل المستندات: منصات SaaS تخدم /documents/{docId}/download دون التحقق من المنظمة المالكة.
أنظمة تذاكر الدعم: منصات تستخدم معرّفات تذاكر يمكن التنبؤ بها في الروابط.

٧. الكود الضعيف مقابل الكود الآمن

التنفيذ الضعيف

// ثغرة — لا يوجد تحقق من الملكية
app.get('/api/orders/:orderId', authMiddleware, async (req, res) => {
  const order = await Order.findById(req.params.orderId);
  if (!order) return res.status(404).json({ error: 'الطلب غير موجود' });
  res.json(order); // يُعاد بصرف النظر عن المالك
});

التنفيذ الآمن

// آمن — يتم التحقق من الملكية على مستوى استعلام قاعدة البيانات
app.get('/api/orders/:orderId', authMiddleware, async (req, res) => {
  const order = await Order.findOne({
    _id: req.params.orderId,
    userId: req.user.id  // يجب أن يطابق معرّف المستخدم المصادَق عليه
  });
  if (!order) return res.status(403).json({ error: 'الوصول مرفوض' });
  res.json(order);
});

٨. استراتيجية الدفاع متعدد الطبقات

٨.١ التخويل على مستوى الكائن في كل نقطة نهاية

يجب على كل معالج API يقبل معرّف كائن إجراء استعلام للتحقق من الملكية قبل إعادة البيانات أو تنفيذ أي تعديلات.

٨.٢ معرّفات غير متسلسلة

استخدم UUID v4 (عشوائي تشفيرياً) بدلاً من الأعداد الصحيحة المتسلسلة. يُلغي هذا التعداد التافه بالتزايد. ومع ذلك، لا تُشكّل UUIDs وحدها ضبطاً أمنياً — بقاء فحوصات التخويل إلزامية أمر ضروري.

٨.٣ خرائط المراجع غير المباشرة

للموارد شديدة الحساسية، نفّذ خرائط مراجع غير مباشرة: يحتفظ الخادم بتعيين محدود بالجلسة بين رموز مبهمة والمعرّفات الداخلية الحقيقية.

٨.٤ الاختبار الآلي ضمن CI/CD

تشمل الأدوات العملية:

Burp Suite مع إضافة Autorize: تسجّل استجابات مستخدم ذي صلاحيات، ثم تعيد كل طلب برمز مستخدم أقل صلاحية وتقارن الاستجابات.
اختبارات التكامل المخصصة: أنشئ حسابَي مستخدم، وأنشئ موارد بالمستخدم أ، وتحقق من أن المستخدم ب لا يستطيع الوصول إليها.

٨.٥ التسجيل والمراقبة

سجّل كل استجابة 403 مع معرّف المستخدم المصادَق عليه ومعرّف المورد المطلوب والمالك الفعلي للمورد. ارتفاع مفاجئ في استجابات 403 من معرّف مستخدم واحد إشارة قوية إلى استطلاع IDOR نشط.

الخلاصة

ثغرة IDOR في واجهات REST API ليست ثغرة تشفيرية معقدة — إنها إخفاق في العملية حيث تغيب فحوصات التخويل التي كان ينبغي وجودها. العلاج بسيط بالقدر ذاته: يجب على كل عملية وصول إلى البيانات التحقق من أن الهوية المصادَق عليها تمتلك الكائن المطلوب أو مخوّلة بالوصول إليه. يجب تطبيق هذا الفحص من جانب الخادم، وعدم الوثوق به للعميل أبداً، ويجب أن يكون موجوداً في كل نقطة نهاية.

ادمج منع IDOR في إطار عمل API الخاص بك بوصفه سلوكاً افتراضياً، وأتمتة استعلامات مقيّدة بالملكية على مستوى ORM، واختبر التخويل بشكل مستقل عن المصادقة في كل نقطة نهاية.