Dify IDOR और द रैग सप्लाई चेन: डेटा स्रोत बाइंडिंग कमजोरियों में एक तकनीकी गहन विश्लेषण

कार्यकारी सारांश: ज्ञान आधारों की मौन समझौता

"AI-नेटिव" एप्लिकेशन स्टैक (2025–2026) के तीव्र विकास में, सुरक्षा इंजीनियरों का ध्यान मुख्यतः नए हमले के तरीकों पर केंद्रित रहा है: प्रॉम्प्ट इंजेक्शन, जेलब्रेकिंग, और मॉडल इन्वर्शन। हालांकि, जैसे-जैसे Dify जैसे प्लेटफ़ॉर्म एंटरप्राइज़-ग्रेड RAG (रीट्रीवल-ऑगमेंटेड जनरेशन) ऑर्केस्ट्रेटर के रूप में परिपक्व हो रहे हैं, हम क्लासिक वेब कमजोरियों के पुनरुत्थान को देख रहे हैं—विशेष रूप से IDOR (असुरक्षित प्रत्यक्ष वस्तु संदर्भ)—नए "ज्ञान आपूर्ति श्रृंखला" में प्रकट हो रहा है।

यह लेख का एक व्यापक तकनीकी विश्लेषण प्रदान करता है। रिमोट डेटा स्रोत बाइंडिंग्स को प्रभावित करने वाली Dify IDOR भेद्यता (GitHub Issue #31839 में संदर्भित)। हम उस वास्तुशिल्पीय दोष का विश्लेषण करेंगे जो अप्रivileged उपयोगकर्ताओं को एक AI एजेंट के "मस्तिष्क" को हेरफेर करने की अनुमति देता है, और इकोसिस्टम में एक्सेस कंट्रोल विफलताओं के व्यापक पैटर्न का विश्लेषण करेंगे (संदर्भित करते हुए CVE-2025-63387 और सीवीई-2025-58747), और यह प्रदर्शित करें कि इन तार्किक खामियों को पकड़ने के लिए स्वचालित पैठ परीक्षण की अगली पीढ़ी को कैसे विकसित होना चाहिए।

संवेदनशीलता की वास्तुकला: डिफ़ाई ज्ञान का प्रबंधन कैसे करता है

एक्सप्लॉइट को समझने के लिए, पहले लक्ष्य को समझना आवश्यक है। Dify एक मल्टी-टेनेंट आर्किटेक्चर पर काम करता है जहाँ एक ही इंस्टेंस (या क्लस्टर) कई "वर्कस्पेस" (टेनेंट) को सेवा प्रदान करता है। इन टेनेंट्स में, मुख्य मूल्य प्रस्ताव असंगठित डेटा—Notion पेज, Google Drive दस्तावेज़, वेब स्क्रैप—को वेक्टर डेटाबेस के माध्यम से एक LLM से जोड़ने की क्षमता है।

The डेटा स्रोत ओएथ बाइंडिंग यह महत्वपूर्ण लिंक एंटिटी है। यह संग्रहीत करता है:

1. प्रदाता: (जैसे, नोशन, गिटहब)
2. OAuth टोकन: (बाहरी डेटा तक एन्क्रिप्टेड पहुँच)
3. दायरा: (कौन से पृष्ठ/रिपॉजिटरी सुलभ हैं)।
4. बाइंडिंग आईडी: Postgres डेटाबेस में एक अद्वितीय पहचानकर्ता (अक्सर एक UUID या पूर्णांक)।

एक सुरक्षित डिज़ाइन में, इस तालिका के लिए प्रत्येक क्वेरी को द्वारा सीमित किया जाना चाहिए। किरायेदार_आईडीDify IDOR भेद्यता तब उत्पन्न होती है जब API एंडपॉइंट में अपडेट (PATCH/PUT) या डिलीशन (DELETE) को संभालते समय यह स्कोपिंग छूट जाती है।

तकनीकी शव-परीक्षा: डेटा स्रोत बाइंडिंग IDOR

यह भेद्यता उन API एंडपॉइंट्स में निहित है जो इन डेटा स्रोत बाइंडिंग्स को सक्षम, अक्षम या रिफ्रेश करने के लिए जिम्मेदार हैं।

त्रुटिपूर्ण तर्क (पुनर्निर्माण)

आइए में मिली निष्कर्षों के आधार पर इस विशिष्ट IDOR के लिए विशिष्ट कमजोर कोड पथ का पुनर्निर्माण करें। Dify GitHub Issue #31839. बैकएंड फ्रेमवर्क (Python/Flask/SQLAlchemy) बाइंडिंग की स्थिति अपडेट करने के लिए एक एंडपॉइंट प्रदान करता है।

पाइथन

`# संवेदनशील एंडपॉइंट लॉजिक (पुनर्निर्माण) @api.route('/console/api/data-source/bindings/', methods=['PATCH']) @login_required def update_data_source_binding(binding_id): """ एक डेटा स्रोत की सक्षम/अक्षम स्थिति को अपडेट करता है। """ # 1. इनपुट सत्यापन (व्याकरण संबंधी) – पास पार्सर = reqparse.RequestParser() पार्सर.add_argument('enabled', type=bool, required=True) args = parser.parse_args()

# 2. डेटाबेस क्वेरी (सुरक्षा दोष)
# डेवलपर केवल आईडी (ID) द्वारा क्वेरी करता है, यह मानते हुए कि UUID पर्याप्त एंट्रॉपी (entropy) वाला है
# या निहित विश्वास (implicit trust) पर निर्भर करते हुए।
binding = db.session.query(DataSourceOauthBinding).filter(
    DataSourceOauthBinding.id == binding_id
).first()

if not binding:
    raise NotFound("बाइंडिंग नहीं मिली")

# 3. लॉजिक निष्पादन
# गंभीर विफलता: यह जांचने के लिए कोई जाँच नहीं है कि binding.tenant_id == current_user.tenant_id है या नहीं
binding.enabled = args['enabled']
binding.updated_at = datetime.utcnow()

db.session.commit()

return jsonify({"result": "success"}), 200`

शोषण श्रृंखला

एक रेड टीम सदस्य या दुर्भावनापूर्ण अंदरूनी व्यक्ति के लिए शोषण के चरण व्यवस्थित होते हैं:

चरण 1: टोही और पहचान सूचीकरण

हमलावर अपने Dify खाते में लॉग इन करता है और Notion इंटीग्रेशन चालू करते समय नेटवर्क ट्रैफ़िक की जाँच करता है।

• अनुरोध: PATCH /console/api/data-source/bindings/550e8400-e29b-41d4-a716-446655440000
• अवलोकन: आईडी प्रारूप। यदि यह UUID है, तो हमले के लिए आईडी लीक (साइड-चैनल या सूचना प्रकटीकरण) की आवश्यकता होती है। यदि यह क्रमिक पूर्णांक (पुराने माइग्रेशन में आम) है, तो इसे आसानी से सूचीबद्ध किया जा सकता है।

नोट: UUID के साथ भी, IDOR संभव है यदि अन्य एंडपॉइंट्स (जैसे GET /कंसोल/api/पब्लिक/स्टैट्स या त्रुटि संदेश) ऑब्जेक्ट संदर्भ लीक करते हैं।

चरण 2: क्रॉस-टेनेंट हेरफेर

हमलावर अपने का उपयोग करके एक तैयार की गई cURL अनुरोध भेजता है। अपना वैध JWT (अधिकृत बीयरर टोकन) लेकिन एक को लक्षित कर रहा है पीड़ित का बाइंडिंग_आईडी.

बश

curl -X PATCH "" \\ -H "Authorization: Bearer " \\ -H "Content-Type: application/json" \\ -d '{"enabled": false}'

चरण 3: प्रभाव – RAG सेवा अस्वीकृति (DoS)

सर्वर अनुरोध को संसाधित करता है। चूंकि डेटाबेस क्वेरी में आईडी मिल गई थी, और कोड ने टेनेंट ओनर की जांच नहीं की थी, बाइंडिंग अक्षम कर दी गई है।

• परिणाम: पीड़ित का एआई एजेंट, जो अपनी ज्ञान आधार के लिए उस Notion पेज पर निर्भर है, अचानक भ्रम करने लगता है या "मुझे नहीं पता" का जवाब देने लगता है, क्योंकि उसकी संदर्भ पुनर्प्राप्ति पाइपलाइन को दूरस्थ रूप से काट दिया गया है।

विस्तृत सीवीई परिदृश्य: टूटे हुए एक्सेस कंट्रोल का एक पैटर्न

यह IDOR कोई अलग-थलग घटना नहीं है। यह 2025 के अंत में Dify इकोसिस्टम को प्रभावित करने वाले "Broken Access Control" (OWASP LLM01) के व्यापक पैटर्न में फिट बैठता है। हाल के CVEs का विश्लेषण एक प्रणालीगत समस्या को उजागर करता है जहाँ फीचर डिलीवरी (एजेंट्स, वर्कफ़्लो, MCP) की गति कठोर RBAC (रोल-आधारित एक्सेस कंट्रोल) के कार्यान्वयन से आगे निकल गई।

विश्लेषण:

CVE-2025-63387 और CVE-2024-11821 की पुनरावृत्ति एक संघर्ष को उजागर करती है। वस्तु-स्तर प्राधिकरण. प्लेटफ़ॉर्म यह सत्यापित करता है कि "क्या उपयोगकर्ता लॉग इन है?" (प्रमाणीकरण) लेकिन यह कड़ाई से सत्यापित करने में विफल रहता है कि "क्या यह उपयोगकर्ता है" मालिक डेटाबेस में इस विशिष्ट पंक्ति का? (अधिकृतिकरण)

पारंपरिक DAST क्यों विफल होता है: तार्किक अंतराल

सुरक्षा इंजीनियर अक्सर पूछते हैं: नेसस, बुरप सूट प्रो, या ज़ैप ने इसे क्यों नहीं पकड़ा?

उत्तर लॉजिक बग्स की प्रकृति में निहित है।

1. HTTP स्थिति कोड भ्रामक हैं: एक स्कैनर के लिए, एक ठीक है एक PATCH अनुरोध से ऐसा लगता है कि यह सफल रहा। स्कैनर को यह नहीं पता कि उपयोगकर्ता A नहीं करना चाहिए यूज़र बी की वस्तु को संशोधित करने में सक्षम हुए हैं।
2. संदर्भ अंधापन: स्कैनर "टेनेंट्स" या "बाइंडिंग्स" की अवधारणा को नहीं समझते। वे केवल अपारदर्शी स्ट्रिंग्स देखते हैं।
3. राज्य निर्भरता: IDOR का परीक्षण करने के लिए एक जटिल सेटअप की आवश्यकता होती है: उपयोगकर्ता A बनाएँ, उपयोगकर्ता B बनाएँ, संसाधन A बनाएँ, B के रूप में लॉग इन करें, संसाधन A तक पहुँचने का प्रयास करें। मानक स्कैन आमतौर पर एकल-उपयोगकर्ता सत्र होते हैं।

समाधान: एआई-नेटिव स्वचालित पेंटस्टिंग

यहीं पर प्रतिमान "स्कैनिंग" से "तर्क" में बदल जाता है। पकड़ने के लिए डिफ़ाई इडोर, आपको एक ऐसा इंजन चाहिए जो समझता हो अर्थविज्ञान एपीआई का

यह इसके पीछे का मूल इंजीनियरिंग दर्शन है। पेनलिजेंट.ai.

पेनलिजेंट तार्किक दोषों का पता कैसे लगाता है

रेगेक्स-आधारित स्कैनरों के विपरीत, पेनलिजेंट स्वायत्त सुरक्षा एजेंटों के रूप में कॉन्फ़िगर किए गए लार्ज लैंग्वेज मॉडल्स (एलएलएम) का उपयोग करता है।

1. सेमांटिक एपीआई मैपिंग: Penligent Dify की Swagger/OpenAPI स्पेक को पढ़ता है और समझता है कि /बाइंडिंग्स/{id} एक संसाधन संशोधन का संकेत देता है। यह यह दर्शाता है कि {id} एक संवेदनशील संदर्भ है।
2. बहु-अभिनेता समन्वय: प्लेटफ़ॉर्म दो अलग-अलग पर्सोना कंटेनर शुरू करता है:
   • हमलावर एजेंट (उपयोगकर्ता A)
   • पीड़ित एजेंट (उपयोगकर्ता बी)
3. संदर्भ-जागरूक फज़िंग: हमलावर एजेंट स्पष्ट रूप से पीड़ित के संसाधनों तक पहुँचने का प्रयास करता है।
   • एजेंट तर्क: मैं एक देखता हूँ बाइंडिंग_आईडी यूज़र बी के ट्रैफ़िक में। मैं यूज़र ए के सेशन टोकन का उपयोग करके इस आईडी को PATCH करने का प्रयास करूँगा।
   • निर्णय विश्लेषण: यदि एपीआई लौटाती है ठीक है और डेटाबेस की स्थिति बदलने पर, पेनलिजेंट एक झंडा लगाता है। पुष्ट आईडीओआर.

डेवसैक्सऑप्स में एकीकरण:

वाईएएमएल

# .gitlab-ci.yml उदाहरण स्टेज:

• सुरक्षा-परीक्षण

penligent-check: चरण: सुरक्षा-परीक्षण स्क्रिप्ट: – penligent-cli scan –target https://staging.dify-instance.com –मोड लॉजिक-डीप-डाइव केवल: – मास्टर`

Penligent जैसे उपकरणों को एकीकृत करके, सुरक्षा टीमें "अनुपालन स्कैनिंग" से "प्रतिद्वंद्वी सिमुलेशन" की ओर बढ़ती हैं, जिससे CVE-2025-63387 और Data Source IDOR द्वारा दर्शाई गई तार्किक खामियों को प्रभावी ढंग से पकड़ा जा सकता है।

उपचार: पंक्ति-स्तर सुरक्षा लागू करना

Dify (या समान AI प्लेटफ़ॉर्म) में पैचिंग करने वाले डेवलपर्स और सुरक्षा इंजीनियरों के लिए, इस समाधान में डेटा एक्सेस लेयर (DAL) पर सख्त स्वामित्व जांच लागू करना शामिल है।

सुरक्षित पैटर्न (पाइथन/SQLAlchemy):

पाइथन

`# सुरक्षित कार्यान्वयन @api.route('/console/api/data-source/bindings/', methods=['PATCH']) @login_required def update_data_source_binding_secure(binding_id): # 1. संदर्भ निष्कर्षण # हमेशा tenant_id को विश्वसनीय सत्र टोकन से प्राप्त करें, क्लाइंट इनपुट से कभी नहीं current_tenant_id = current_user.current_tenant_id

# 2. स्कोप्ड क्वेरी (समाधान)
# हम कभी भी केवल आईडी (ID) के आधार पर क्वेरी नहीं करते हैं। हम हमेशा इसे टेनेंट_आईडी (tenant_id) के साथ AND करते हैं।
binding = db.session.query(DataSourceOauthBinding).filter(
    DataSourceOauthBinding.id == binding_id,
    DataSourceOauthBinding.tenant_id == current_tenant_id
).first()

# 3. सुरक्षित विफलता मोड
यदि बाइंडिंग नहीं है:
    आईडी एन्यूमरेशन को रोकने के लिए 404 नॉट फाउंड लौटाएँ।
    403 फॉरबिडन न लौटाएँ, क्योंकि यह हमलावरों को आईडी के अस्तित्व के बारे में जानकारी दे देता है।
    अबाउट(404)

# 4. लॉजिक निष्पादन
binding.enabled = request.json['enabled']
db.session.commit()
return jsonify({"status": "updated"})`

समाधान के लिए मुख्य बिंदु:

1. किरायेदार संदर्भ सर्वोपरि है: प्रत्येक क्वेरी में शामिल होना चाहिए किरायेदार_आईडी.
2. त्रुटियों को मौन करें: उपयोग 404 नहीं मिला संसाधनों तक अनधिकृत पहुँच के लिए, नहीं 403. यह हमलावरों को आपके डेटाबेस आईडी (Oracle Attack) का नक्शा बनाने से रोकता है।
3. यूयूआईडी सुरक्षा नहीं हैं: UUID का उपयोग क्रमिक सूचीकरण को रोकने में मदद करता है, लेकिन यदि आईडी लीक हो जाए तो यह IDOR को नहीं रोकता। एक्सेस कंट्रोल ही एकमात्र वास्तविक रक्षा है।

एआई ऐपसैक का भविष्य

The डिफ़ाई इडोर यह भेद्यता उद्योग के लिए एक महत्वपूर्ण केस स्टडी के रूप में कार्य करती है। जैसे-जैसे हम "एजेंटिक" भविष्य बनाने की दौड़ में हैं जहाँ एआई हमारी ओर से क्रियाएँ करता है, वेब सुरक्षा की मूलभूत नींव को नजरअंदाज नहीं किया जा सकता। एक समझौता किया गया डेटा स्रोत बाइंडिंग केवल डेटा हानि का मतलब नहीं है; RAG के युग में, इसका अर्थ है वास्तविकता विकृति एआई मॉडल के लिए

सुरक्षा इंजीनियरों को अनुकूलित होना चाहिए। हमें साधारण इंजेक्शन हमलों से परे देखना चाहिए और टेनेंट्स, एजेंट्स और नॉलेज बेस के बीच जटिल तार्किक संबंधों पर ध्यान केंद्रित करना चाहिए। चाहे वह कठोर कोड समीक्षा के माध्यम से हो या Penligent जैसे AI-नेटिव परीक्षण प्लेटफ़ॉर्म को अपनाकर, "नॉलेज लेयर" को सुरक्षित करना 2026 की निर्णायक चुनौती है।

संदर्भ और अतिरिक्त पठन:

• GitHub Issue #31839: Dify DataSourceOauthBinding IDOR भेद्यता
• GitHub एडवाइजरी: डिफ़ाई सिस्टम फ़ीचर्स परमिशन (CVE-2025-63387)
• एनवीडी विवरण: CVE-2025-58747 (MCP OAuth XSS)
• एलएलएम अनुप्रयोगों के लिए ओवास्प टॉप 10: आईडीओआर और डेटा पॉइज़निंग
• पेनलिजेंट ब्लॉग: पारंपरिक DAST तार्किक भेद्यताओं को क्यों चूक जाता है