Stream Vessel, özel MCP client'larının güvenli şekilde oturum açması için kullanıcı başına güvenilir redirect URI'leri öneriyor

Özel client'lara karşı bir kayıt duvarı

MCP client'ları standart OAuth ile oturum açar: client kendini kaydettirir, bir tarayıcı açar, kullanıcı Onayla'ya tıklar ve client tek kullanımlık authorization kodunu bir token ile takas eder. Kendi agent'ını çalıştıran herkes için — bir Slack bot'u, bir VPS üzerindeki servis, hafta sonu projesi bir MCP client'ı — akış çoğu zaman ilk adımda ölür. Stream Vessel blogundaki 4 Kasım tarihli bir yazıda Alexander Loginov bu başarısızlığı şöyle anlatıyor: server, client'ın redirect URI'sini — tarayıcının kodu taşıyarak geri döndüğü adresi — operatörün izin verdiği listede olmadığı için reddediyor. Bu listeler genellikle yalnızca Claude, ChatGPT, Cursor ve VS Code gibi iyi bilinen client'ları kapsar ve yeni bir client eklemek için operatörden bir yapılandırma dosyasını düzenlemesini istemek gerekir.

Liste basitçe kaldırılamaz da. Bir onayın kullanıcının düşündüğü anlamı taşıdığının tek garantisi odur: client kendine ne derse desin, anahtarlar yalnızca listenin gösterdiği yere gidebilir.

Açık bir server'ın davet ettiği saldırı

Yazıya göre, her kaydı ve her redirect adresini kabul eden bir server, bir saldırganın hiç hesap açmadan dört adımda kullanıcının erişimini ele geçirmesine izin verir: saldırgan denetimindeki callback'li "Claude" adında bir client kaydeder, oturum açmış bir kullanıcıya inandırıcı bir authorize bağlantısı gönderir, kullanıcının gerçek oturumunda gerçek onay ekranında onay vermesini bekler ve kodu saldırganın adresinde toplar; kod orada token'a dönüşür.

PKCE yardımcı olmaz çünkü akışı saldırgan başlatmıştır ve client adı kendi beyanıdır. Bu örüntü, Microsoft 365 kullanıcılarını hedefleyen sahte uygulama onay istemlerinin aynısıdır.

Zincir belgelenmiştir. 119 OAuth destekli MCP server'ını test eden Mayıs 2026 tarihli bir araştırma, bunların 114'ünde — yüzde 95,8 — anonim istekçilerden herhangi bir redirect URI kabul eden kayıt endpoint'leri buldu. Obsidian Security, Ocak 2026'da Square'in MCP server'ına karşı aynı zinciri rapor etti; tek tıkla bir satıcının profili, işlemleri ve banka bilgileri açığa çıkıyordu ve araştırmacılar Square'in düzeltmesinin yalnızca yeni kaydedilen client'ları kapsadığını belirtti. Başkaları bu zinciri tek oturum açma önündeki bir MCP proxy'sinde buldu; tık başına 24 saatlik bir access token ve 14 günlük bir refresh token değerindeydi ve bazen sosyal mühendislik diye görmezden gelindiği bug bounty programlarında da görüldü.

Daha sessiz bir yan etki daha var: bir isteğin redirect adresi kabul edildikten sonra bir denetimden geçemediği durumda hata o adrese gönderilir. Her adresi kabul eden bir server, kendi alan adında açık bir redirector haline gelir; RFC 9700 bu durumu ayrıntısıyla ele alır.

Spec ve pratiğin ters yönde çekmesi

MCP spec'i, server'lardan tam eşleşen redirect URI'leri doğrulamalarını ister ve yalnızca güvendikleri URI'lere otomatik yönlendirme yapılmasını önerir — bu son cümleleri RFC 9700'ten alır — ama neyin güvenilir sayıldığını her server'a bırakır. Kayıt da değişiyor: 2026-07-28 tarihli client kayıt sayfası, Dynamic Client Registration'ı bırakıp Client ID Metadata Documents'ı önerir; burada client id, client'ın redirect URI'lerini listeleyen bir HTTPS URL'dir. Loginov'un da belirttiği gibi, bu bir client'ı kimin yayımladığını belirler, bu kullanıcının onu bağlamayı isteyip istemediğini değil.

Pratikte yazı, server'ları iki kutuptan birinde görüyor. Sabit bir operatör listesi — örneğin pgEdge'in Postgres MCP server'ı — maruziyeti düşük tutar ama yalnızca listelenen client'ları kabul eder. Client'ın kaydettiği her şeyi kabul etmek ise — test edilen 119 server'dan 114'ünün yaptığı gibi — herkese izin verir ve yukarıdaki saldırıyı mümkün kılar. Kapalı kutbun gerçek mağdurları var: Haziran 2026 tarihli bir Claude Code issue'ı, tam eşleşme listeleri kullanan kuruluşların Claude Code ile oturum açamadığını çünkü localhost callback host ve path'inin sabit olduğunu bildiriyor; issue, planlanmadı olarak kapatıldı.

Oturum açışta karara bağlanan kullanıcı başına güven

Stream Vessel'ın önerisi, operatör listesini ve yerel client'lar için loopback URI'lerini olduğu gibi koruyor, ardından ikinci bir katman ekliyor: her kullanıcı kendi hesabı için az sayıda tam eşleşen HTTPS redirect adresine güvenebilir — üst sınır on — bunlar web uygulamasının MCP sayfasındaki "Güvenilir uygulama adresleri" olarak yönetilir ve yalnızca kullanıcının kendi tarayıcı oturumundan değiştirilebilir.

Kritik hamle zamanlamadır. Kayıt, henüz kimse oturum açmadan gerçekleştiği için hangi listeye bakacağını bilemez; her HTTPS URI'yi kabul eder ve karar, kullanıcının bilindiği authorize sayfasına kadar bekler. Her dalın altında tek bir kural yatar: hiçbir kod ve hiçbir hata, tüm hesapların ya da bu kullanıcının güvenmediği bir adrese asla yönlendirilmez.

Yazı öncülleri kabul ediyor — GitHub'ın geliştiricinin girdiği callback URL'leri, MCP spec'inin elle ön kayıt seçeneği, Atlassian'ın organizasyon başına güvenilir alan adları — ama bunların hiçbirinin, client id'si başka yerde üretilmemiş ya da bir admin tüm organizasyon adına karar vermemiş, anonim olarak kendini kaydeden bir client'a uymadığını savunuyor.

Neden önemli

Mayıs 2026 ölçümleri, dağıtılmış MCP server'larının çoğunun güvenlik yerine açıklığı seçtiğini, kilitli olanların ise kendi sunucularında barındırılan agent'ları çaresiz bıraktığını gösteriyor. Gerçek verilerin önünde bir MCP server'ı işleten herkes bu ödünleşimle karşı karşıya ve tek bir onay tıklaması bir hesabı saldırgana devretmemeli. Kullanıcı başına güvenilir redirect URI'leri soruyu bir client'ın iyi bilinip bilinmediğinden bu kullanıcının onu bağlamayı isteyip istemediğine çeviriyor ve tasarım, diğer server operatörlerinin de kopyalayabileceği kadar basit.