تعرّف على ما يعنيه المرجع المباشر غير الآمن للكائنات (IDOR)، وكيف يستغلها المهاجمون، وكيف يمكن للمطورين منع ثغرات IDOR باستخدام ممارسات الترميز الآمنة، وأنماط التحكم في الوصول، ومنصات الاختبار الآلي.
ما هو IDOR؟
المرجع المباشر غير الآمن للكائنات (IDOR) هو ثغرة أمنية حيث يقوم التطبيق بكشف معرّفات الكائنات الداخلية - مثل معرّفات المستخدم أو أرقام الطلبات أو أسماء الملفات - دون التحقق مما إذا كان طالب الخدمة مخولاً بالوصول إلى هذا الكائن. من خلال تغيير معلمة في عنوان URL أو استدعاء واجهة برمجة التطبيقات، يمكن للمهاجمين عرض أو تعديل أو حذف البيانات التي لا ينبغي أن يكون لديهم حق الوصول إليها.
فهم IDOR: لماذا لا تزال هذه الثغرة مهمة؟
ينتمي IDOR إلى الفئة الواسعة من التحكم في الوصول المعطلالذي صنفته منظمة OWASP كأحد أهم المخاطر الأمنية على الويب لسنوات. تكمن خطورة IDOR في بساطته: لا يحتاج المهاجم إلى تقنيات استغلال متقدمة، أو ترميز الحمولة، أو تصعيد الامتيازات. يمكن لمعلمة واحدة معدلة - غالبًا ما تكون مجرد رقم - أن تكشف معلومات خاصة.
يبدو النمط النموذجي الضعيف هكذا
باش
/API/API/مستخدم/ملف تعريف؟ id=1002
إذا لم يتحقق التطبيق من الملكية أو التفويض، فإن تغيير المعرف إلى 1003 قد تكشف بيانات مستخدم آخر.
غالبًا ما تعتمد التطبيقات الحديثة - خاصةً تلك التي تتضمن واجهات برمجة التطبيقات أو الخدمات المصغرة أو عملاء الأجهزة المحمولة - بشكل كبير على الوصول إلى الكائنات ذات المعلمات. وعلى الرغم من أن هذه البنية سريعة ومرنة، إلا أنها يمكن أن تقدم بسهولة IDOR عندما تكون عمليات التحقق من التفويض غير متسقة أو مفقودة.
CVE-2025-13526: حالة IDOR في العالم الحقيقي في البرية
أحد أحدث الأمثلة البارزة على استغلال IDOR هو CVE-2025-13526تؤثر على إضافة ووردبريس الشهيرة OneClick Chat to Order (الإصدار ≤ 1.0.8).
- تكمن الثغرة الأمنية في المكون الإضافي
وا_أمر_شكراً_للمتجاوزةالوظيفة. يثق المكون الإضافي بـالطلب_المعرفمن سلسلة الاستعلام الخاصة بعنوان URL - دون التحقق من أن الطلب يأتي من المالك الشرعي للطلب. - يمكن للمهاجمين (حتى غير المصادق عليهم) التلاعب ببساطة ب
الطلب_المعرفعلى عنوان URL لصفحة "الشكر" (على سبيل المثال، تغييرالطلب_id=123456إلىالطلب_id=123455123455) واسترداد تفاصيل طلبات العملاء الآخرين. تتضمن البيانات المكشوفة الأسماء، وعناوين البريد الإلكتروني، وأرقام الهواتف، وعناوين الفواتير/الشحن، وعناصر الطلبات والأسعار، والبيانات الوصفية لطريقة الدفع. ويز.io+2جوري إنفوسيك+2 - نظرًا لأن معرّفات الطلبات كانت متسلسلة ويمكن التنبؤ بها، فقد أصبح التعداد الجماعي تافهًا - مما يعني أن المهاجم أو البرنامج النصي الآلي يمكنه جمع آلاف الطلبات في دقائق. متوسط + 1
- تم تعيين درجة أساسية للثغرة الأمنية CVSS v3.1 تبلغ 7.5 (عالية)، مما يعكس سهولة الاستغلال (لا حاجة إلى مصادقة) وشدة تعرض البيانات للخطر.
- قام المطور بإصلاح المشكلة في الإصدار 1.0.9من خلال تنفيذ عمليات التحقق من التفويض المناسبة لضمان أن المالكين الشرعيين (أو المستخدمين المصرح لهم) هم فقط من يمكنهم عرض بيانات الطلبات. تم حث أصحاب المواقع على الترقية على الفور. جوري إنفوسيك+1
يُظهر هذا الاختراق في العالم الحقيقي أن IDOR ليس خطأً نظريًا أو قديمًا - فهو لا يزال حيًا وقابلًا للاستغلال، ومن المحتمل أن تكون له عواقب وخيمة على الخصوصية والامتثال.
سيناريوهات العالم الواقعي الشائعة التي يحدث فيها IDOR
يمكن أن تظهر IDOR في أي نظام يشير إلى كائنات داخلية عبر مدخلات يتحكم فيها المستخدم. فيما يلي السياقات الشائعة:
| نوع التطبيق | مثال على الكائن | سبب حدوث IDOR |
|---|---|---|
| أنظمة الحسابات | معرف المستخدم | الكشف المباشر عن معرّفات المستخدم |
| تطبيقات التجارة الإلكترونية | معرّف الطلب | التحقق غير السليم من صحة الملكية |
| إدارة الملفات | معرف الملف | عدم التحكم في الوصول إلى الملفات |
| منصات التذاكر | معرف التذكرة | وصول المستخدمين إلى تذاكر المستخدمين الآخرين |
| تطبيقات SaaS متعددة المستأجرين | معرف المستأجر | تسرّب البيانات عبر المستأجرين |
غالبًا ما يقوم المهاجمون بتعداد المعرّفات التي يمكن التنبؤ بها، أو محاولة الحصول على معرّفات متسلسلة، أو إعادة تشغيل الطلبات المصادق عليها بمعلمات معدلة.
كيف يستغل المهاجمون IDOR (أمثلة آمنة ومحكومة)
فيما يلي أمثلة توضيحية آمنة تُظهر الأنماط النموذجية غير الآمنة ونظيراتها الآمنة. هذه ليست ثغرات ضارة؛ بل هي نماذج لأخطاء شائعة لمساعدة المطورين على التعرف على الأنماط غير الآمنة.
مثال 1: IDOR في Node.js / Express
جافا سكريبت
// ❌ ❌ مثال ضعيف: الثقة في المعرف المقدم من المستخدم
app.get('/api/appi/user/profile, (req, res) => {
const userId = req.query.query.id;
db.users.findById(userId).then(user => {
res.json(المستخدم);
});
});
// // ✅ مثال آمن: فرض التفويض
app.get('/api/appi/user/profile, (req, res) => {
const authenticatedId = req.user.id;
db.users.findById(authenticatedId).then(user => {
إذا (!المستخدم) يُرجع res.status(404).json({ خطأ: "لم يتم العثور على المستخدم"});
res.json({المعرف: user.id، البريد الإلكتروني: user.email، الدور: user.role });
});
});
مثال 2: النمط الشائع في بايثون / فلاسك
بايثون
# ❌ غير آمن: لا يوجد توثيق للملكية
@app.get("/الفاتورة")
def get_invoice():
معرف_الفاتورة = request.args.get("id")
الإرجاع get_invoice_by_id(invoice_id)
#✅ آمن: تمت إضافة التحقق من الأذونات
@app.get("/الفاتورة")
def get_invoice_secure():
معرف_الفاتورة = request.args.get("id")
user_id = الجلسة ["مستخدم_id"]
الفاتورة = get_in_voice_by_id(invoice_id)
إذا كان invoice.owner_id !.= user_id:
إرجاع {"خطأ": "غير مصرح به"}, 403
إرجاع الفاتورة
مثال 3: الدفاع المشترك بين الواجهة الخلفية والواجهة الأمامية (جافا + رياكت)
جافا (سبرينغ بوت)
جافا
// ❌ ❌ فحص التفويض المفقود
@GetMapping("/أوامر")
عام طلبية عامة getOrder(@RequestParam String orderId) {
إرجاع orderRepository.findById(orderId);
}
// // ✅ التنفيذ الآمن
@GetMapping("/أوامر")
العمومية كيان الاستجابة getOrder(
@RequestParam String orderId,
المدير الرئيسي) {
أمر الطلب = orderReorderRepository.findById(orderId);
إذا (!order.getUser().equals(principal.getName())) {
إرجاع ResponseEntity.status(HttpStatus.FORBIDDEN)
.body(Collections.singletonMap("خطأ"، "الوصول مرفوض"));
}
إرجاع ResponseEntity.ok(طلب);
}
طلب آمن من جانب رد الفعل
جافا سكريبت
دالة غير متزامنة fetchOrder(orderId) {
const res = await fetch(/orders?orderId=${orderId}, {
الرؤوس: {"التخويل": Bearer ${localStorage.getItem("token")} }
});
إذا (!res.ok) قم بإلقاء خطأ جديد ("غير مصرح به أو غير موجود");
إرجاع res.json();
}
اكتشاف ثغرات IDOR: مناهج المطورين العملية
غالبًا ما يكون العثور على IDOR أصعب من استغلاله. على عكس ثغرات الحقن، لا ينتج عن IDOR دائمًا أخطاء تقنية واضحة - فأعراضه منطقية وسلوكية.
تشمل تقنيات الكشف الشائعة ما يلي:
- التشويش التفاضلي (اختبار معرّفات متعددة)
- اختبار الإعادة (الالتقاط → التعديل → الإعادة)
- تبديل الأدوار متعدد المستخدمين
- تعداد المعلمات
رمز زائف آمن للتشويش الآمن:
بايثون
مثال بسيط للتشويش الآمن
المعرفات = ["1001"، "1002"، "1003"]
بالنسبة إلى i في المعرفات:
res = client.get(f"/API/user/profile/profile?id={i}")
طباعة(i, res.status_code، len(res.text))
الوقاية من IDOR: أفضل الممارسات التي يجب على المطورين اتباعها
لا يتعلق منع IDOR بالتعتيم - بل يتعلق بـ التفويضيتم تنفيذها باستمرار على مستوى الخادم.
لا تثق أبدًا في معرّفات الكائنات من العميل
كل معلمة قابلة للتعديل. حتى المعرفات المشفرة يمكن التلاعب بها.
فرض التفويض من جانب الخادم على كل طلب
استخدام نماذج التحكم في الوصول المعترف بها:
- RBAC (التحكم في الوصول المستند إلى الدور)
- ABAC (التحكم في الوصول المستند إلى السمات)
- ACLs (قوائم التحكم في الوصول)
- السياسة كقانون أنظمة مثل OPA
موارد السلطة:
- OWASP: https://owasp.org
أكاديمية PortSwigger لأمن الويب: https://portswigger.net/web-security/access-control
تفضيل المعرفات غير القابلة للتعداد
تقلل معرّفات UUIDs من مخاطر IDOR ولكنها لا تقضي عليها.
التحقق من صحة حدود المستأجرين في البيئات متعددة المستأجرين
يعد IDOR عبر المستأجرين أحد أكثر الأشكال خطورة وتكلفة.
استخدام طبقة الواجهة الخلفية للواجهة الأمامية (BFF)
يمكن لـ BFF إضفاء الطابع المركزي على منطق التفويض، مما يقلل من التناقضات بين العملاء.
أمثلة متقدمة إضافية
مثال 4: واجهة برمجة تطبيقات Go API مع تفويض مفقود
اذهب
// ❌ المعالج الضعيف
func GetDocument(w http.respons ResponseWriter, r *http.Request) {
المُعرِّف := r.URL.Query().Get("id")
المستند := db.FindDocument(id)
json.NewEncoder(w).Encode(doc)
}
// // ✅ مع التحقق من صحة الملكية
func GetDocumentSecure(w http.ResponseWriter، r *http.Request) {
المُعرِّف := r.URL.Query().Get("id")
المستخدم := r.Context().Value("مستخدم").(string).
المستند := db.FindDocument(id)
إذا كان doc.Owner.= مستخدم {
http.Error(w, "غير مصرح به", http.StatusForbidden)
العودة
}
json.NewEncoder(w).Encode(doc)
}
مثال 5: نقاط نهاية GraphQL وتخويل الكائنات
جافا سكريبت
// ❌ محلل ضعيف
تشكل المحللات = { {
استعلام: {
الطلب: (_, { id }) => db.getOrder(id),
}
};
// // ✅ محلل آمن مع التحقق من الملكية
const resolversSecure = {
استعلام: {
الطلب: (_، {المعرف }، السياق}، السياق) => {
const order = db.getOrder(id);
إذا (كان (Order.owner.owner !== context.user.id) {
طرح خطأ جديد("الوصول مرفوض");
}
أمر الإرجاع;
}
}
};
مثال 6: الوصول الآمن في Rust (Actix Web)
الصدأ
// ❌ عرضة للخطر
async fn get_ticket(path: web::Path) -> ضمنًا المستجيب {
دع المعرف = path.in_inner();
دع التذكرة = db::find_ticket(&id);
الويب::Json(تذكرة)
}
// // ✅ إصدار آمن
غير متزامن fn get_ticket_secure(
المسار: الويب::مسار,
مستخدم مستخدم مسجل الدخول
) -> المستجيب الضمني {
دع المعرف = path.in_inner();
دع التذكرة = db::find_ticket(&id);
إذا كان مالك التذكرة != user.id.user.id {
إرجاع HttpResponse::Forbidden().json("الوصول مرفوض");
}
HttpResponse::Ok().json(ticket)
}
أتمتة اكتشاف IDOR: لماذا تكافح الأدوات التقليدية
لا يمكن لمعظم ماسحات الثغرات التقليدية اكتشاف IDOR بشكل موثوق لأن IDOR يتطلب شيئين تفشل الماسحات التقليدية في القيام بهما:
- الوعي بمنطق الأعمال التجارية
- الاختبار السياقي متعدد المستخدمين
أدوات الفحص التي تعتمد فقط على الاكتشاف القائم على التوقيع أو طلبات المستخدم الواحد عادةً ما تغفل IDOR بالكامل، خاصةً في واجهات برمجة التطبيقات.
كيف يساعد Penligent في تحديد هوية IDOR تلقائيًا
هذا هو المكان بنليجنتوهي منصة لاختبار الاختراق تعتمد على الذكاء الاصطناعي، وتوفر ميزة فريدة من نوعها. وخلافاً للماسحات الضوئية التقليدية، فإن Penligent يقوم بـ
- محاكاة تلقائية متعددة المستخدمين
- الاستدلال على المعلمات عبر الكائنات
- التعرف الذكي على أنماط الهوية الذكية
- التحليل التفاضلي السلوكي
- تشويش الذكاء الاصطناعي الذي يتكيف بناءً على الاستجابات المرصودة
عينة من مخرجات الكشف الآمنة والمجهولة المصدر من Penligent:
شبكة vbnet
"تم اكتشاف IDOR محتمل: نقطة النهاية: /الأوامر؟ id=1002السلوك الملحوظ:
- تلقى المستخدم (أ) الطلب #1003 (مملوكة للمستخدم (ب)) الخطر: وصول غير مصرح به إلى بيانات مستخدم آخر'
من الصعب تحقيق هذا النوع من البصيرة باستخدام الأدوات الثابتة أو المراجعة اليدوية وحدها.
الحد من مخاطر IDOR عبر CI/CD مع Penligent
يتكامل Penligent بشكل طبيعي مع خطوط أنابيب CI/CD ويوفر تغطية مستمرة:
- واجهة برمجة التطبيقات (API) والاكتشاف التلقائي للمسار
- الاستدلال على مصفوفة الأذونات في الوقت الحقيقي
- مسح بيئات التدريج والبيئات الشبيهة بالإنتاج
- التوليد التلقائي لتسلسلات آمنة وقابلة للتكرار من PoC
هذا يقلل:
- النقاط العمياء في منطق الأعمال التجارية
- التعرض متعدد المستأجرين
- المخاطر التنظيمية (النظام الأوروبي العام لحماية البيانات (GDPR)، وقانون HIPAA، وSOC2)
الخلاصة: IDOR بسيط ولكنه مدمر - ويمكن الوقاية منه
يظل IDOR أحد أكثر أشكال ثغرات التحكم في الوصول شيوعاً وضرراً. ولأنه يختبئ داخل منطق العمل، فإنه غالباً ما يتخطى الأدوات التقليدية. من خلال فرض عمليات التحقق من التفويض المتسقة، واستخدام معرّفات غير قابلة للتنبؤ، والتحقق من صحة حدود المستأجر، واعتماد منصات اختبار مؤتمتة مثل Penligent، يمكن للمؤسسات أن تقلل بشكل كبير من مخاطر انكشاف البيانات على نطاق واسع.
لا يمكن القضاء على IDOR بشكل كامل عن طريق الصدفة أو النوايا الحسنة - فهو يتطلب تحكمًا منظمًا في الوصول، ومبادئ هندسية متسقة، واختبارًا مستمرًا.
