MCP'de Confused Deputy Sorunu: Kaynak Doğrulama Boşluğu ve DNS Rebinding
MCP protokolündeki confused deputy açığı: kaynak doğrulama eksikliği, prompt injection ve DNS rebinding saldırıları ile tespit kuralları.
Model Context Protocol (MCP), LLM'leri dosya sistemleri, veritabanları ve web ile birleştiren katman olarak giderek daha kritik hale geliyor. Ancak protokolün tasarımında yapısal bir zayıflık var: bir tool_result modelin bağlam penceresine girdiğinde, bu içeriğin nereden geldiğine, kim tarafından üretildiğine veya yolda değiştirilip değiştirilmediğine dair kriptografik olarak doğrulanabilir hiçbir bilgi taşınmıyor. ToolAnnotations gibi alanlar (readOnlyHint, destructiveHint) sadece tavsiye niteliğinde olup güvenlik sınırı oluşturmuyor ve kötü niyetli bir sunucu tarafından kolayca sahtelenebiliyor.
Bu boşluk somut saldırı yollarına dönüşüyor. Resmi fetch sunucusu, saldırgan kontrolündeki bir URL'den gelen HTML'i Markdown'a çevirip doğrudan modele aktarıyor; sayfaya gömülü sahte sistem talimatları veya diğer araçları çağırmaya yönlendiren metinler klasik dolaylı prompt injection saldırısını mümkün kılıyor. Ayrı bir vektör olarak DNS rebinding saldırısı, allowlist kontrolü sırasında herkese açık bir IP'ye çözümlenen bir alan adının, gerçek istek anında TTL sıfırlanarak dahili bir IP'ye (RFC1918) yönlendirilmesiyle MCP sunucusunu istemsiz bir dahili proxy'ye çevirebiliyor.
Mühendisler için pratik çıkarım, bu risklerin loglanabilir sinyallerle tespit edilebilir olmasıdır: tool_result içeriğinde sistem-promptu benzeri yapılar, kayıtlı araç adlarına referanslar, basit URL'lere kıyasla anormal büyüklükte sonuçlar, fetch anında dahili IP'ye çözümlenen bağlantılar, düşük TTL değerleri ve dahili uç noktalarda biten yönlendirme zincirleri. Bu kurallar MCP proxy katmanında veya SIEM'de uygulanabilir.