Dify IDOR وسلسلة توريد RAG: نظرة تقنية متعمقة في نقاط الضعف في ربط مصدر البيانات

ملخص تنفيذي: التسوية الصامتة لقواعد المعرفة

في التطور السريع لمكدس تطبيقات "الذكاء الاصطناعي الأصلي" (2025-2026)، انصب تركيز مهندسي الأمن إلى حد كبير على نواقل الهجوم الجديدة: الحقن الموجه وكسر الحماية وعكس النموذج. ومع ذلك، مع نضوج منصات مثل Dify لتصبح منظّمات RAG (الجيل المعزّز للاسترجاع) على مستوى المؤسسات، نشهد عودة ظهور ثغرات الويب الكلاسيكية - وتحديداً IDOR (مرجع الكائن المباشر غير الآمن)-تتجلى في "سلسلة توريد المعرفة" الجديدة.

تقدم هذه المقالة تحليلاً فنيًا شاملاً لـ ثغرة Dify IDOR التي تؤثر على ارتباطات مصدر البيانات عن بعد (المشار إليها في GitHub Issue #31839). سنقوم بتشريح الخلل المعماري الذي يسمح للمستخدمين غير المصرح لهم بالتلاعب بـ "دماغ" وكيل الذكاء الاصطناعي، وتحليل النمط الأوسع لفشل التحكم في الوصول في النظام البيئي (بالرجوع إلى CVE-2025-63387 و CVE-2025-58747)، وإيضاح كيف يجب أن يتطور الجيل التالي من اختبارات الاختراق الآلي لالتقاط هذه الثغرات المنطقية.

بنية الضعف: كيف يدير ديفاي المعرفة

لفهم الاستغلال، يجب أولاً فهم الهدف. تعمل Dify على بنية متعددة المستأجرين حيث يخدم مثيل واحد (أو مجموعة واحدة) "مساحات عمل" (مستأجرين) متعددة. وضمن هؤلاء المستأجرين، فإن القيمة الأساسية المقترحة هي القدرة على ربط البيانات غير المهيكلة - صفحات الانتقال، ومستندات Google Drive، ومخطوطات الويب - بقاعدة بيانات متجهة.

إن DataSourceOauthBinding هو كيان الربط الحرج. فهو يخزن:

1. مقدم الخدمة: (على سبيل المثال، Notion، GitHub).
2. رمز OAuth Token: (وصول مشفر إلى البيانات الخارجية).
3. النطاق: (ما هي الصفحات/المراجع التي يمكن الوصول إليها).
4. المُعرّف الملزم: معرّف فريد (غالباً ما يكون UUID أو عدد صحيح) في قاعدة بيانات Postgres.

في التصميم الآمن، يجب أن يتم تحديد نطاق كل استعلام إلى هذا الجدول بواسطة المستأجر_المعرف. تنشأ ثغرة Dify IDOR عندما يتم تفويت هذا النطاق في نقطة نهاية واجهة برمجة التطبيقات التي تتعامل مع التحديثات (PATCH/PATUT) أو الحذف (DELETE).

التشريح الفني: مصدر البيانات الملزم IDOR

تكمن الثغرة الأمنية في نقاط نهاية واجهة برمجة التطبيقات المسؤولة عن تمكين روابط مصادر البيانات هذه أو تعطيلها أو تحديثها.

المنطق المعيب (إعادة الإعمار)

دعونا نعيد بناء مسار الكود الضعيف النموذجي لهذا IDOR المحدد، استنادًا إلى النتائج في مشكلة Dify GitHub العدد #31839. يعرض إطار عمل الواجهة الخلفية (Python/Flask/SQLAlchemy) نقطة نهاية لتحديث حالة الربط.

بايثون

''# VULNERABLE ENDPOINT LOGIC (إعادة البناء) @API.route('/console/API/data-source/bindings/'', methods=['PATCH'])) @login_required def update_data_source_source_binding(binding_id): """ تحديث حالة التمكين/التعطيل لمصدر البيانات. """ # 1. التحقق من صحة المدخلات (نحويًا) - PASS parser = reqparse.RequestParser() parser.add_argument('enabled'، النوع = bool، مطلوب=صحيح) args = parser.parse_args()

# 2. استعلام قاعدة البيانات (الخلل الأمني)
# يستفسر المطور عن طريق المعرف فقط، بافتراض أن معرف UUID هو إنتروبيا كافية
# أو الاعتماد على الثقة الضمنية.
الربط = db.session.query(DataSourceOauthBinding).filter(
    DataSourceOauthBinding.id = = معرف = binding_id
).first()

إذا لم يكن الربط
    رفع NotFound("الربط غير موجود")

# 3. تنفيذ المنطق
# فشل حرج: لا يوجد تحقق لمعرفة ما إذا كان الربط.tenant_id = = current_user.tenant_id الحالي
الربط.ممكّن = args['ممكّن']
binding.updated_at = datetime.utcnow()

db.session.commit()

إرجاع jsonify({"نتيجة": "نجاح"})، 200``

سلسلة الاستغلال

بالنسبة للفريق الأحمر أو المطلعين الخبيثين، تكون خطوات الاستغلال منهجية:

المرحلة 1: الاستطلاع وحصر الهويات

يقوم المهاجم بتسجيل الدخول إلى حساب Dify الخاص به وفحص حركة مرور الشبكة عند تبديل تكامل Notion.

• الطلب: PATCH /console/api/data-source/bindings/550e8400-e29b-41d4-a716-446655440000
• الملاحظة: تنسيق المعرف. إذا كان معرّف UUID، فإن الهجوم يتطلب تسرب معرّف (قناة جانبية أو إفشاء معلومات). إذا كان عددًا صحيحًا متسلسلًا (شائع في عمليات الترحيل القديمة)، فيمكن تعداده بشكل بديهي.

ملاحظة: حتى مع معرّفات UUIDs، فإن IDOR ممكن إذا كانت نقاط النهاية الأخرى (مثل GET /console/API/public/stats أو رسائل الخطأ) تسرب مراجع الكائنات.

المرحلة 2: التلاعب المتبادل بين المستأجرين

يقوم المهاجم بإرسال طلب cURL مصطنع باستخدام تملك الرمز المميز لحامل التخويل (JWT) الصالح ولكنه يستهدف الضحية الربط_المعرف.

باش

كيرل -X باتش "" \\ -H "Authorization: Bearer " \ \ -H "نوع المحتوى: تطبيق/جوسون" \ \ -d '{"ممكّن": خطأ}

المرحلة 3: التأثير - RAG الحرمان من الخدمة (DoS)

يعالج الخادم الطلب. نظرًا لأن استعلام قاعدة البيانات عثر على المعرف، ولم يتحقق الرمز من مالك المستأجر، يتم تعطيل الربط.

• النتيجة: يبدأ وكيل الذكاء الاصطناعي للضحية، الذي يعتمد على صفحة المفاهيم تلك لقاعدة المعرفة الخاصة به، بالهلوسة فجأة أو الرد بـ "لا أعرف"، حيث تم قطع التحكم عن بعد في خط أنابيب استرجاع السياق الخاص به.

مشهد CVE الأوسع نطاقاً: نمط من التحكم في الوصول المعطل

هذا IDOR ليس حادثة معزولة. فهو يتناسب مع نمط أوسع من "التحكم في الوصول المعطّل" (OWASP LLM01) الذي ابتلي به نظام Dify في أواخر عام 2025. يكشف تحليل حالات مكافحة التطرف العنيف الأخيرة عن مشكلة منهجية حيث تجاوزت سرعة تقديم الميزات (الوكلاء وسير العمل و MCP) تنفيذ التحكم الصارم في الوصول القائم على الأدوار (RBAC).

التحليل:

يسلط تكرار CVE-2025-63387 و CVE-2024-11821 الضوء على الصراع مع التفويض على مستوى الكائن. تتحقق المنصة من صحة "هل قام المستخدم بتسجيل الدخول؟ (مصادقة) ولكنها تفشل في التحقق بدقة من صحة "هل هذا المستخدم هو المالك لهذا الصف المحدد في قاعدة البيانات؟" (تفويض).

لماذا يفشل برنامج DAST التقليدي: الفجوة المنطقية

غالباً ما يسأل مهندسو الأمن: "لماذا لم يكتشف برنامج Nessus أو Burp Suite Pro أو Zap هذا الأمر؟

تكمن الإجابة في طبيعة الأخطاء المنطقية.

1. رموز حالة HTTP خادعة: بالنسبة إلى الماسح الضوئي، فإن 200 موافق من طلب التصحيح يبدو ناجحًا. لا يعرف الماسح الضوئي أن المستخدم A لا ينبغي تمكنوا من تعديل كائن المستخدم B.
2. عمى السياق: لا تفهم الماسحات الضوئية مفهوم "المستأجرين" أو "الروابط". فهم يرون سلاسل مبهمة.
3. تبعية الدولة: يتطلب اختبار IDOR إعدادًا معقدًا: إنشاء مستخدم أ، وإنشاء مستخدم ب، وإنشاء مستخدم ب، وإنشاء المورد أ، وتسجيل الدخول بصيغة ب، ومحاولة الوصول إلى المورد أ. عادةً ما تكون عمليات الفحص القياسية جلسات عمل لمستخدم واحد.

الحل: الاختبار الآلي المؤتمت للذكاء الاصطناعي

هنا يتحول النموذج من "المسح" إلى "الاستدلال". للقبض على ديفي آيدور، فأنت بحاجة إلى محرك يفهم الدلالات لـ API

هذه هي الفلسفة الهندسية الأساسية وراء Penligent.ai.

كيف يكتشف Penligent عيوب المنطق

على عكس الماسحات الضوئية القائمة على regex، يستخدم Penligent نماذج اللغة الكبيرة (LLMs) التي تم تكوينها كعوامل أمان مستقلة.

1. تخطيط واجهة برمجة التطبيقات الدلالية: يقرأ Penligent مواصفات Swagger/OpenAPI الخاصة بـ Dify ويفهم أن / الروابط/{المعرف} ينطوي على تعديل في الموارد. ويستنتج منه أن {المعرف} مرجع حساس.
2. تنسيق متعدد الجهات الفاعلة: تقوم المنصة بتدوير حاويتين شخصيتين مختلفتين:
   • العميل المهاجم (المستخدم أ)
   • العميل الضحية (المستخدم ب)
3. التشويش الواعي بالسياق: يحاول العميل المهاجم صراحةً الوصول إلى موارد الضحية.
   • المنطق العميل: "أرى أن الربط_المعرف في حركة مرور المستخدم B. سأحاول تصحيح هذا المعرف باستخدام الرمز المميز لجلسة عمل المستخدم A."
   • تحليل الحكم: إذا قامت واجهة برمجة التطبيقات بإرجاع 200 موافق وتغيرت حالة قاعدة البيانات، يقوم Penligent بوضع علامة تأكيد IDOR.

التكامل في DevSecOps:

YAML

'# .gitlab-ci.yml مثال على المراحل:

• اختبار الأمان

فحص penligent-check: المرحلة: برنامج نصي لاختبار الأمان: - فحص penligent-cli - الهدف https://staging.dify-instance.com -الوضع المنطقي-المنطق-الغوص العميق فقط: -سيدي``

من خلال دمج أدوات مثل Penligent، تنتقل فرق الأمن من "فحص الامتثال" إلى "محاكاة الخصومة"، مما يؤدي إلى اكتشاف العيوب المنطقية التي يمثلها CVE-2025-63387 وIDOR مصدر البيانات.

الإصلاح: تنفيذ الأمان على مستوى الصفوف

بالنسبة للمطورين ومهندسي الأمن الذين يقومون بتصحيح Dify (أو منصات الذكاء الاصطناعي المماثلة)، يتضمن الإصلاح فرض عمليات تحقق صارمة من الملكية في طبقة الوصول إلى البيانات (DAL).

النمط الآمن (Python/SQLAlchemy):

بايثون

'# التنفيذ الآمن @API.route('/console/API/data-source/bindings/', methods=['PATCH']) @login_required def update_data_source_source_binding_secle(binding_id): # 1. استخراج السياق # اشتق دائمًا المستأجر_id من الرمز المميز لجلسة العمل الموثوق بها، ولا يتم اشتقاقه أبدًا من مدخلات العميل current_tenant_id = current_user.current_tenant_id

# 2. استعلام محدد النطاق (الإصلاح)
# نحن لا نستعلم أبدًا عن طريق المعرف وحده. نحن دائمًا ما نجمعه مع معرف المستأجر.
الربط = db.session.query(DataSourceOauthBinding).filter(
    DataSourceOauthBinding.id = = معرف_ind,
    DataSourceOauthBinding.tenant_id == معرف_المستأجر الحالي
).first()

# 3. وضع الفشل الآمن
إذا لم يتم الربط
    # إرجاع 404 غير موجود لمنع تعداد المعرف.
    # لا تقم بإرجاع 403 ممنوع، لأن ذلك يسرب وجود المعرف للمهاجمين.
    إحباط(404)

# 4. تنفيذ المنطق
الربط.ممكّن = request.json['ممكّن']
db.session.commit()
إرجاع jsonify({"الحالة": "محدَّث"})'

الوجبات الرئيسية للإصلاح:

1. سياق المستأجر هو الملك: يجب أن يتضمن كل استعلام المستأجر_المعرف.
2. إسكات الأخطاء: الاستخدام 404 لم يتم العثور على 404 للوصول غير المصرح به إلى الموارد، وليس 403. وهذا يمنع المهاجمين من تعيين معرفات قاعدة البيانات الخاصة بك (هجوم أوراكل).
3. معرّفات UUID ليست أمنية: يساعد استخدام معرّفات UUIDs في منع التعداد المتسلسل، لكنه لا يمنع IDOR إذا تم تسريب المعرّف. التحكم في الوصول هو الدفاع الحقيقي الوحيد.

مستقبل تطبيقات الذكاء الاصطناعي

إن ديفي آيدور تُعد الثغرة الأمنية بمثابة دراسة حالة حرجة للصناعة. بينما نندفع نحو بناء مستقبل "عميل" حيث يقوم الذكاء الاصطناعي بتنفيذ الإجراءات نيابةً عنا، لا يمكن تجاهل أسس أمن الويب الأساسية. لا يعني اختراق رابط مصدر البيانات المخترق فقدان البيانات فحسب؛ بل يعني في عصر RAG، يعني تشويه الواقع لنموذج الذكاء الاصطناعي.

يجب على مهندسي الأمن التكيف. يجب أن ننظر إلى ما وراء هجمات الحقن البسيطة والتركيز على العلاقات المنطقية المعقدة بين المستأجرين والوكلاء وقواعد المعرفة. وسواء من خلال المراجعة الصارمة للأكواد البرمجية أو اعتماد منصات اختبار الذكاء الاصطناعي مثل Penligent، فإن تأمين "طبقة المعرفة" هو التحدي الحاسم لعام 2026.

المراجع والمزيد من القراءة:

• مشكلة GitHub العدد #31839: ثغرة Dify DataSourceOauthBinding IDOR
• استشارة GitHub: أذونات ميزات نظام Dify (CVE-2025-63387)
• تفاصيل NVD: CVE-2025-58747 (MCP OAuth XSS)
• أفضل 10 تطبيقات لـ OWASP لتطبيقات LLM: IDOR وتسمم البيانات
• مدونة Penligent: لماذا تفتقد تقنية DAST التقليدية نقاط الضعف المنطقية