SSRF: sunucuyu vekil hâline getirmek

Web uygulamalarının çoğu, kullanıcının verdiği bir adresten veri çeker: profil resmi indirme, bağlantı önizleme, faturaya gömülecek görsel, web kancası (webhook) doğrulama. Uygulama bu isteği kendi sunucusundan atar, kullanıcının tarayıcısından değil. Sunucu tarafı istek sahteciliğinde (SSRF) saldırgan, adres alanına kendi ulaşamadığı bir hedef yazar.

Uygulama isteği kendi ağından attığı için, saldırganın hiç göremediği bir iç adrese ulaşır. Saldırganın istediği veri kendisine değil uygulamaya döner; uygulama da bu yanıtı olduğu gibi ya da işlenmiş biçimde geri gösterirse, saldırgan iç ağın içini dışarıdan okumuş olur.

Zincirin değeri, sunucunun bulunduğu ağ konumundan gelir. Kurumsal ağlarda dış dünyaya kapalı, kimlik doğrulaması bile istemeyen yönetim panelleri ve iç servisler bulunur; bunlar zaten iç ağdayız varsayımıyla açık bırakılır. Bulut ortamında ayrıca her sanal makinenin kendi kimlik bilgilerini okuduğu bir üstveri servisi (metadata service) çalışır ve bu servis yalnız makinenin kendisinden erişilebilir bir adrestedir. SSRF, uygulamayı bu iki dünyaya da bir köprüye çevirir: saldırgan dışarıdan ulaşamadığı iç servise ya da üstveri adresine, uygulamanın ağ konumunu ödünç alarak ulaşır.

Neden bu kadar yaygın? Çünkü sunucudan dış veri çekmek pek çok özelliğin doğal parçasıdır. Bağlantı önizleme bir adresin başlığını ve görselini getirir, ödeme sağlayıcısı bir web kancasına durum yazar, belge servisi uzak bir şablonu indirir. Bu akışların hepsinde adres bir girdi alanıdır.

Geliştirici adresi iş mantığının bir ayarı gibi görür, oysa saldırgan onu bir hedef seçici olarak kullanır. SSRF'in kök nedeni tam burada yatar: güvenilmeyen bir girdi, sunucunun ağ kimliğiyle çıkan bir isteğe çevrilir. Girdi doğrulanmadıkça, isteğin nereye gittiğini saldırgan belirler.

SSRF tek bir biçimde gelmez. Temel SSRF'te uygulama, iç hedeften dönen yanıtı ekrana basar; saldırgan iç servisin çıktısını doğrudan okur. Kör SSRF'te yanıt hiç görünmez, çünkü uygulama görseli küçültüp gösterir ya da isteği arka planda atar.

Yarı kör SSRF arada durur: tam yanıt görünmez ama hata kodu, yanıt uzunluğu ya da süre farkı sızar. Üçü de aynı kök nedenden doğar, yalnız geri bildirim kanalı değişir. Hangi biçimle karşılaştığını, uygulamanın verdiği her ipucunu okuyarak anlarsın.

Kurumsal bir ödeme panelinde bu ayrımı bilmek, bir bulgunun gerçek etkisini doğru raporlamana yarar. Kör bir SSRF yüzeysel bakışta zararsız görünür, oysa saldırgan onu bir yanıt kanalına çevirmenin yolunu bulur.

Pratikte bu üç biçimi şöyle ayırırsın. Yanıt gövdesinde iç servisin çıktısını görüyorsan temel SSRF'tir. Hiçbir fark görünmüyorsa ve ancak kendi sunucuna gelen bir geri çağrıyla doğrulayabiliyorsan kör SSRF'tir; kanıtı uygulamanın dışından toplarsın.

Yanıt gövdesi aynı kalıp hata kodu, gecikme ya da içerik uzunluğu değişiyorsa yarı kördür; bu küçük farklar bile iç bir portun açık mı kapalı mı olduğunu ele verir. Bir bulguyu raporlarken bu ayrımı net yazarsın, çünkü etki ve aciliyet biçime göre değişir. Kör görünen bir SSRF, doğru kanalla temel SSRF kadar ağır olabilir.

Savunma tarafında kör SSRF'i yanıt gövdesinden yakalayamazsın, çünkü uygulama ham yanıtı hiç ekrana basmaz. Tespit için sunucunun giden bağlantı kaydına (egress log) bakarsın. Web sunucusunun kendi bulunduğu ağ aralığına ya da bağlantı yerel (link-local) adreslere giden istekler, normal bir görsel indirme trafiğinde hiç görünmez. Aynı uç noktaya kısa sürede farklı iç adresler denenmesi de bir tarama örüntüsüdür.

Bulut sağlayıcıları her sanal makineye bir üstveri servisi verir. Bu servis, makinenin kendi yapılandırmasını ve ona atanmış rolün geçici kimlik bilgilerini sabit bir bağlantı yerel adresten sunar: 169.254.169.254. Adres yalnız makinenin kendi içinden erişilebilir, bu yüzden tasarımcılar onu güvenli varsayar. İlk sürüm IMDSv1, tek bir GET isteğiyle yanıt verir; kimlik ya da belirteç istemez.

SSRF bu varsayımı kırar. Uygulamaya 169.254.169.254 adresini okutabilen saldırgan, rolün geçici anahtarlarını tek istekle çeker ve bulut hesabında o rolün yetkisiyle hareket eder. Kurumsal bir görsel işleme servisinde bu, tek bir önizleme özelliğinin tüm bulut ortamına kapı açması demektir.

# 1) Saldırganın görsel adresi alanına yazdığı değer
http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Uygulama bu adresi kendi ağından okur, dönen yanıt rol adıdır:
altaykargo-gorsel-rolu

# 2) Rol adı öğrenilince ikinci istek aynı yolun altına gider
http://169.254.169.254/latest/meta-data/iam/security-credentials/altaykargo-gorsel-rolu

# Dönen yanıt, rolün geçici anahtarlarıdır:
{
  "AccessKeyId": "ORNEK_ANAHTAR",
  "SecretAccessKey": "ORNEK_GIZLI",
  "Token": "ORNEK_OTURUM",
  "Expiration": "2026-10-01T12:00:00Z"
}

Örneği satır satır oku. İlk adres, rol kimliklerinin listelendiği yola gider ve yanıt tek satırlık bir rol adıdır. Saldırgan bu adı ikinci isteğin sonuna ekler.

İkinci yanıt, rolün geçici erişim anahtarını, gizli anahtarını ve oturum belirtecini taşır. Anahtarlar süreli olsa da, saldırgan bu pencere boyunca rolün izin verdiği her bulut işlemini yapar. Dikkat et: iki istek de 169.254.169.254 adresine, yani makinenin kendi üstverisine gider ve ikisi de uygulamanın ağ kimliğiyle çıkar.

İkinci sürüm IMDSv2 bu akışı değiştirir. Üstveriyi okumadan önce istemci, kısa ömürlü bir oturum belirteci almak için bir PUT isteği atar; sonraki her GET bu belirteci bir başlıkta taşır. Belirteç zorunlu kılındığında, belirteçsiz istek 401 yanıtıyla reddedilir. SSRF açıklarının çoğu yalnız basit bir GET isteği attırabildiği için, belirteç adımı tek başına birçok denemeyi boşa çıkarır.

Belirteç yanıtının IP paketi varsayılan olarak tek atlamayla sınırlıdır; yanıt makineden bir ağ geçişi bile öteye gidemez. X-Forwarded-For başlığı taşıyan PUT istekleri de reddedilir, böylece açık bırakılmış bir ters vekil belirteç alamaz. Yeni makinelerde IMDSv2'yi zorunlu kılmak, bu konudaki en somut tek ayarlı savunmadır.

Sık yapılan bir hata, üstveri adresini kara listeye ekleyip işin bittiğini sanmaktır. Saldırgan aynı bağlantı yerel adrese farklı yazımlarla ulaşır ve kara liste geride kalır. Bir başka hata, IMDSv2'yi açıp eski IMDSv1'i kapatmayı unutmaktır; iki sürüm birlikte açıkken saldırgan basit olanı seçer.

Kurumsal bir ortamda bu açığı kapatmanın en temiz yolu, yeni makineleri baştan yalnız IMDSv2 ile açmak ve üstveri yolunu uygulama konteynerinin ağından tümden kesmektir. Böylece tek bir SSRF, bulut hesabının anahtarlarına uzanamaz. Üstveriye hiç ihtiyacı olmayan bir servis için en güçlü ayar, o yolu baştan erişilemez kılmaktır.

Doğru savunma bir izin listesidir (allowlist), yasak listesi değil. Uygulama, yalnız önceden onaylı alan adlarına istek atar; listede olmayan her adres reddedilir. Yasak listesi (kara liste) localhost, 127.0.0.1 ve bulut üstveri adresini engellemeye çalışsa da, kısaltılmış IP yazımı, onluk gösterim ya da DNS yeniden bağlama (rebinding) ile aşılır.

İzin listesi bu oyunu tersine çevirir: adres önce çözülür, çözülen IP izin listesiyle karşılaştırılır, ancak öyleyse istek atılır. Kara liste bütün kötü adresleri önceden bilmek zorundadır; izin listesi yalnız birkaç iyi adresi tanır. İkincisini korumak çok daha kolaydır.

Adımları ayır: önce adresi al, sonra alan adını bir IP'ye çöz, çözülen IP'yi izin listesiyle karşılaştır, ancak eşleşirse isteği at. Bu sıralama kritiktir, çünkü adı değil çözülen adresi denetlersin. Yönlendirmeyi de elle yönetmen gerekir.

İzin verilen ilk adres bir 302 yanıtıyla iç bir adrese yönlendirirse ve istemci yönlendirmeyi sessizce izlerse, kontrol boşa çıkar. redirect ayarını manual yapınca, her yönlendirme yeniden izin listesinden geçer. Tek bir çözüm, tek bir hedef, tek bir onay.

// Güvensiz: kullanıcının verdiği her adrese istek at
const cevap = await fetch(req.body.url);

// Güvenli: izin listesi + yönlendirmeyi kapat
const hedef = new URL(req.body.url);
if (!IZINLI_ALAN_ADLARI.includes(hedef.hostname)) return res.status(400).end();
const cevap = await fetch(hedef, { redirect: "manual" });

İzin listesini kodda tek bir yerde toplarsın. Her özellik kendi adres denetimini yazarsa, biri mutlaka eksik kalır. Dış adrese giden her isteği ortak bir yardımcıdan geçirirsin. Bu yardımcı adresi ayrıştırır, şemayı yalnız https ile sınırlar, adı bir kez çözer ve çözülen IP'yi özel, döngü ve bağlantı yerel aralıklara karşı denetler.

Ardından isteği aynı IP'ye atar, yönlendirmeyi kapatır ve kısa bir zaman aşımı koyar. Kod gözden geçirmesinde doğrudan bir fetch çağrısı gören ekip arkadaşın, onu bu yardımcıya yönlendirir. Böylece savunma, her geliştiricinin tek tek dikkatine değil, sınanmış tek bir bileşene dayanır.

Ağ mimarisi de ikinci bir katmandır. Dış isteklere yanıt veren sunucu, iç yönetim servislerine ve veritabanına doğrudan erişemeyecek biçimde ayrı bir bölmede (DMZ) tutulursa, SSRF'in ulaşabileceği hedef sayısı baştan daralır. İzin listesi ve ağ bölmesi birlikte çalışınca, tek bir unutulmuş kontrol bütün iç ağı açmaz.

Üstveri servisine giden yolu konteyner ağından tamamen kapatmak da aynı mantığı taşır; sıçrama sayısı bir olunca uygulama katmanı hiç ulaşamaz. Giden trafiği de süzmek gerekir: uygulamanın yalnız birkaç dış adrese bağlanmasına izin veren bir çıkış kuralı, kör SSRF'in dışarı veri sızdırma kanalını da keser.

Gerçek bir olayda bu zincir şöyle görünür. Dışa açık bir önizleme ya da içe aktarma özelliği, denetimsiz bir adres alanı taşır. Saldırgan önce iç ağı tarar, açık bir yönetim ucu ya da üstveri adresi bulur, sonra oradan kimlik bilgisi ya da iç veri çeker.

Savunma tek bir yerde durmaz: uygulama katmanında izin listesi, ağ katmanında bölme ve çıkış süzme, bulut katmanında IMDSv2 birlikte çalışır. Bir katman atlansa bile diğeri zinciri keser. Bu derinlik, SSRF'i tek bir unutulmuş kontrolün felaketi olmaktan çıkarır.

Şimdi bunu web kancasına taşı. Altay Kargo, iş ortaklarının verdiği bir adrese sipariş durumu bildirimi gönderiyor. Ortak, formu doldururken adres alanına iç yönetim panelinin adresini yazarsa, aynı zincir bu kez bildirim özelliği üstünden çalışır.

Ortağın verdiği adres de kullanıcı girdisidir; kaynağın adı değişse de kural değişmez, uygulama yine kendi ağından bir istek atar. Web kancası uçları bu yüzden SSRF'in en sık unutulan kapısıdır: adres bir ayar gibi göründüğü için denetimden kaçar.