Dify IDOR & RAG Tedarik Zinciri: Veri Kaynağı Bağlama Güvenlik Açıklarına Teknik Bir Derin Dalış

Yönetici Özeti: Bilgi Tabanlarının Sessiz Uzlaşması

"AI-Native" uygulama yığınının hızlı evriminde (2025-2026), güvenlik mühendislerinin odağı büyük ölçüde yeni saldırı vektörleri tarafından büyülendi: Prompt Injection, Jailbreaking ve Model Inversion. Bununla birlikte, Dify gibi platformlar kurumsal düzeyde RAG (Retrieval-Augmented Generation) orkestratörlerine dönüştükçe, klasik web güvenlik açıklarının yeniden canlanmasına tanık oluyoruz - özellikle IDOR (Güvensiz Doğrudan Nesne Referansı)-Yeni "Bilgi Tedarik Zinciri "nde tezahür ediyor.

Bu makale aşağıdakilerin kapsamlı bir teknik analizini sunmaktadır Uzak Veri Kaynağı Bağlamalarını etkileyen Dify IDOR güvenlik açığı (GitHub Issue #31839'da referans verilmiştir). Ayrıcalıksız kullanıcıların bir yapay zeka ajanının "beynini" manipüle etmesine izin veren mimari kusuru inceleyecek, ekosistemdeki daha geniş erişim kontrolü hataları modelini analiz edeceğiz (referans CVE-2025-63387 ve CVE-2025-58747) ve yeni nesil otomatik sızma testlerinin bu mantık boşluklarını yakalamak için nasıl gelişmesi gerektiğini göstermektedir.

Güvenlik Açığı Mimarisi: Dify Bilgiyi Nasıl Yönetiyor?

İstismarı anlamak için önce hedefi anlamak gerekir. Dify, tek bir örneğin (veya kümenin) birden fazla "Çalışma Alanına" (Kiracı) hizmet verdiği çok kiracılı bir mimari üzerinde çalışır. Bu kiracılar içinde temel değer önerisi, yapılandırılmamış verileri (Duygu sayfaları, Google Drive dokümanları, Web Kazımaları) bir Vektör Veritabanı aracılığıyla bir LLM'ye bağlama yeteneğidir.

Bu DataSourceOauthBinding kritik bağlantı varlığıdır. Depolar:

1. Sağlayıcı: (örneğin, Notion, GitHub).
2. OAuth Belirteci: (Harici verilere şifreli erişim).
3. Kapsam: (Hangi sayfalara/repolara erişilebilir).
4. Bağlama Kimliği: Postgres veritabanında benzersiz bir tanımlayıcı (genellikle bir UUID veya Integer).

Güvenli bir tasarımda, bu tabloya yapılan her sorgunun kapsamı tenant_id. Dify IDOR güvenlik açığı, güncellemeleri (PATCH/PUT) veya silmeleri (DELETE) işleyen API uç noktasında bu kapsamlama gözden kaçırıldığında ortaya çıkar.

Teknik Otopsi: Veri Kaynağı Bağlayıcı IDOR

Güvenlik açığı, bu veri kaynağı bağlamalarını etkinleştirmek, devre dışı bırakmak veya yenilemekten sorumlu API uç noktalarında bulunur.

Kusurlu Mantık (Yeniden Yapılanma)

'daki bulgulara dayanarak, bu özel IDOR'a özgü güvenlik açığı kod yolunu yeniden yapılandıralım Dify GitHub Sorunu #31839. Arka uç çerçevesi (Python/Flask/SQLAlchemy) bir bağın durumunu güncellemek için bir uç nokta sunar.

Python

'# VULNERABLE ENDPOINT LOGIC (Reconstruction) @api.route('/console/api/data-source/bindings/', methods=['PATCH']) @login_required def update_data_source_binding(binding_id): """ Bir veri kaynağının etkin/devre dışı durumunu günceller. """ # 1. Girdi Doğrulama (Sözdizimsel) - PASS parser = reqparse.RequestParser() parser.add_argument('enabled', type=bool, required=True) args = parser.parse_args()

# 2. Veritabanı Sorgusu (Güvenlik Açığı)
# Geliştirici, UUID'nin yeterince entropik olduğunu varsayarak yalnızca kimliğe göre sorgular
# veya örtük güvene güvenme.
binding = db.session.query(DataSourceOauthBinding).filter(
    DataSourceOauthBinding.id == binding_id
).first()

if not binding:
    raise NotFound("Bağlayıcı bulunamadı")

# 3. Mantık Yürütme
# KRITIK HATA: binding.tenant_id == current_user.tenant_id olup olmadığını görmek için kontrol yok
binding.enabled = args['enabled']
binding.updated_at = datetime.utcnow()

db.session.commit()

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

İstismar Zinciri

Bir Red Teamer ya da kötü niyetli bir içeriden öğrenen için istismar adımları metodiktir:

Aşama 1: Keşif ve Kimlik Sayımı

Saldırgan kendi Dify hesabında oturum açar ve bir Notion entegrasyonunu değiştirirken ağ trafiğini inceler.

• İstek: PATCH /console/api/data-source/bindings/550e8400-e29b-41d4-a716-446655440000
• Gözlem: Kimlik biçimi. Bir UUID ise, saldırı bir ID sızıntısı gerektirir (Yan Kanal veya Bilgi İfşası). Sıralı bir Tamsayı ise (eski geçişlerde yaygındır), önemsiz bir şekilde numaralandırılabilir.

Not: UUID'lerle bile, IDOR diğer uç noktalar (örneğin GET /console/api/public/stats veya hata mesajları) nesne referanslarını sızdırır.

Aşama 2: Kiracılar Arası Manipülasyon

Saldırgan, cURL isteklerini kullanarak hazırlanmış bir cURL isteği gönderir. kendi geçerli JWT (Yetkilendirme Taşıyıcısı belirteci) ancak bir kurbanın binding_id.

Bash

curl -X PATCH "" \\ -H "Yetkilendirme: Taşıyıcı " \\ -H "Content-Type: application/json" \\ -d '{"enabled": false}'

Aşama 3: Etki - RAG Hizmet Reddi (DoS)

Sunucu isteği işler. Veritabanı sorgusu kimliği bulduğundan ve kod Kiracı Sahibini kontrol etmediğinden, bağlama devre dışı bırakılır.

• Sonuç: Bilgi Tabanı için o Kavram sayfasına güvenen kurbanın Yapay Zeka Ajanı, bağlam alma hattı uzaktan kumandayla kesildiği için aniden halüsinasyon görmeye veya "Bilmiyorum" diye yanıt vermeye başlar.

Daha Geniş CVE Manzarası: Bozuk Erişim Kontrolü Örüntüsü

Bu IDOR münferit bir olay değildir. Dify ekosistemini 2025'in sonlarında rahatsız eden daha geniş bir "Bozuk Erişim Kontrolü" (OWASP LLM01) modeline uymaktadır. Son CVE'ler incelendiğinde, özellik sunum hızının (Aracılar, İş Akışları, MCP) katı RBAC (Rol Tabanlı Erişim Kontrolü) uygulamasını geride bıraktığı sistemik bir sorun ortaya çıkmaktadır.

Analiz:

CVE-2025-63387 ve CVE-2024-11821'in tekrarlanması, aşağıdaki sorunlarla mücadele edildiğini göstermektedir Nesne Düzeyinde Yetkilendirme. Platform "Kullanıcı giriş yaptı mı?" sorusunu doğrular (Kimlik Doğrulama) (Kimlik Doğrulama) doğruluyor ancak "Bu kullanıcı sahibi veritabanındaki bu belirli satırın?" (Yetkilendirme).

Geleneksel DAST Neden Başarısız Olur? Mantık Boşluğu

Güvenlik Mühendisleri sık sık sorar: "Nessus, Burp Suite Pro veya Zap bunu neden yakalamadı?"

Cevap, Mantık Hatalarının doğasında yatmaktadır.

1. HTTP Durum Kodları Aldatıcıdır: Bir tarayıcıya, bir 200 TAMAM bir PATCH isteğinden başarılı gibi görünüyor. Tarayıcı, Kullanıcı A'nın yapmamalı Kullanıcı B'nin nesnesini değiştirebilmiştir.
2. Bağlam Körlüğü: Tarayıcılar "Kiracılar" veya "Bağlar" kavramını anlamazlar. Onlar opak dizeler görürler.
3. Eyalet Bağımlılığı: IDOR'u test etmek karmaşık bir kurulum gerektirir: Kullanıcı A Oluştur, Kullanıcı B Oluştur, Kaynak A Oluştur, B olarak Oturum Aç, Kaynak A'ya Erişmeye Çalış Standart taramalar genellikle tek kullanıcılı oturumlardır.

Çözüm: Yapay Zeka-Yerel Otomatik Pentesting

Paradigmanın "Tarama "dan "Muhakeme "ye geçtiği yer burasıdır. Yakalamak için Dify IDORanlayan bir motora ihtiyacınız var. anlambilim API'nin.

Bu, aşağıdakilerin arkasındaki temel mühendislik felsefesidir Penligent.ai.

Penligent Mantık Hatalarını Nasıl Tespit Ediyor?

Regex tabanlı tarayıcıların aksine Penligent, otonom güvenlik aracıları olarak yapılandırılmış Büyük Dil Modelleri (LLM'ler) kullanır.

1. Semantik API Eşleme: Penligent, Dify'ın Swagger/OpenAPI spesifikasyonunu okur ve şunları anlar /bindings/{id} bir kaynak değişikliği anlamına gelir. Bu şu anlama gelir {id} hassas bir referanstır.
2. Çok Aktörlü Orkestrasyon: Platform iki farklı persona konteynerini döndürür:
   • Saldırgan Aracı (Kullanıcı A)
   • Mağdur Temsilci (Kullanıcı B)
3. Bağlam Farkında Bulanıklaştırma: Saldırgan Ajan açıkça Kurbanın kaynaklarına erişmeye çalışır.
   • Temsilci Muhakemesi: "Ben bir binding_id Kullanıcı B'nin trafiğinde. Kullanıcı A'nın oturum belirtecini kullanarak bu kimliği YÖNLENDİRMEYİ deneyeceğim."
   • Karar Analizi: API geri dönerse 200 TAMAM ve veritabanı durumu değiştiğinde, Penligent bir Onaylanmış IDOR.

DevSecOps'a entegrasyon:

YAML

# .gitlab-ci.yml örnek aşamaları:

• güvenlik-testi

penligent-check: stage: security-test script: - penligent-cli tarama -hedef https://staging.dify-instance.com -mode logic-deep-dive only: - master`

Güvenlik ekipleri Penligent gibi araçları entegre ederek "Uyumluluk Taraması "ndan "Muhalif Simülasyon "a geçerek CVE-2025-63387 ve Veri Kaynağı IDOR'unun temsil ettiği mantık hatalarını etkili bir şekilde yakalayabilir.

Düzeltme: Satır Düzeyinde Güvenlik Uygulama

Dify'a (veya benzer yapay zeka platformlarına) yama uygulayan geliştiriciler ve güvenlik mühendisleri için düzeltme, Veri Erişim Katmanında (DAL) sıkı sahiplik kontrollerinin uygulanmasını içeriyor.

Güvenli Model (Python/SQLAlchemy):

Python

# GÜVENLİ UYGULAMA @api.route('/console/api/data-source/bindings/', methods=['PATCH']) @login_required def update_data_source_binding_secure(binding_id): # 1. BAĞLAM ÇIKARMA Bağlam Çıkarma # Kiracı_id'sini her zaman güvenilir oturum belirtecinden türetin, istemci girdisinden ASLA current_tenant_id = current_user.current_tenant_id

# 2. Kapsamlı Sorgu (Düzeltme)
# ASLA tek başına ID ile sorgulama yapmayız. Her zaman kiracı_id ile AND yaparız.
binding = db.session.query(DataSourceOauthBinding).filter(
    DataSourceOauthBinding.id == binding_id,
    DataSourceOauthBinding.tenant_id == current_tenant_id
).first()

# 3. Güvenli Arıza Modu
eğer bağlayıcı değilse:
    # Kimlik numaralandırmayı önlemek için 404 Bulunamadı döndürün.
    # Kimliğin varlığını saldırganlara sızdıracağı için 403 Forbidden döndürmeyin.
    iptal(404)

# 4. Mantık Yürütme
binding.enabled = request.json['enabled']
db.session.commit()
return jsonify({"status": "updated"})`

Düzeltme için Önemli Çıkarımlar:

1. Kiracı Bağlamı Kraldır: Her sorgu şunları içermelidir tenant_id.
2. Hataları susturun: Kullanım 404 Bulunamadı kaynaklara yetkisiz erişim için değil 403. Bu, saldırganların veritabanı kimliklerinizi eşlemesini engeller (Oracle Saldırısı).
3. UUID'ler Güvenlik değildir: UUID'lerin kullanılması sıralı numaralandırmayı önlemeye yardımcı olur, ancak ID sızdırılırsa IDOR'u önlemez. Erişim Kontrolü tek gerçek savunmadır.

Yapay Zeka AppSec'in Geleceği

Bu Dify IDOR güvenlik açığı sektör için kritik bir vaka çalışması niteliğindedir. Yapay zekanın bizim adımıza eylemler gerçekleştirdiği "Agentic" gelecekler inşa etmek için acele ederken, temel web güvenliği temelleri göz ardı edilemez. Güvenliği ihlal edilmiş bir Veri Kaynağı Bağlantısı sadece veri kaybı anlamına gelmez; RAG çağında, şu anlama gelir gerçeklik çarpıtması yapay zeka modeli için.

Güvenlik mühendisleri uyum sağlamalıdır. Basit enjeksiyon saldırılarının ötesine bakmalı ve Kiracılar, Temsilciler ve Bilgi Tabanları arasındaki karmaşık mantıksal ilişkilere odaklanmalıyız. İster titiz kod incelemesi ister Penligent gibi yapay zekaya dayalı test platformlarının benimsenmesi yoluyla olsun, "Bilgi Katmanını" güvence altına almak 2026'nın belirleyici zorluğudur.

Referanslar ve İleri Okuma:

• GitHub Sorunu #31839: Dify DataSourceOauthBinding IDOR Güvenlik Açığı
• GitHub Danışmanlığı: Dify Sistem Özellikleri İzinleri (CVE-2025-63387)
• NVD Detayı: CVE-2025-58747 (MCP OAuth XSS)
• LLM Uygulamaları için OWASP Top 10: IDOR ve Veri Zehirlenmesi
• Penligent Blog: Geleneksel DAST Mantık Zafiyetlerini Neden Gözden Kaçırıyor?