SSRF (Sunucu Taraflı İstek Sahteciliği) Nedir?

Sunucu neden başkası adına istek atar?

Modern web uygulamalarının pek çok özelliği, kullanıcının verdiği bir adresi sunucu tarafında çağırır: bağlantı önizlemesi üreten sohbet uygulamaları, “URL'den görsel yükle” alanları, bir sayfadan PDF üreten servisler, kullanıcının tanımladığı webhook adreslerine bildirim gönderen sistemler, bir siteyi tarayıp rapor çıkaran analiz araçları. Bu özelliklerin hepsinde istek, kullanıcının tarayıcısından değil, uygulamanın sunucusundan çıkar.

Sorun da tam burada başlar. Sunucu çoğu zaman internetten görünmeyen bir ağın içindedir; localhost üzerinde dinleyen bir yönetim arayüzüne, iç ağdaki bir Redis veya Elasticsearch kurulumuna, bulut sağlayıcının 169.254.169.254 adresindeki metadata servisine erişebilir. Hedef adres doğrulanmadan çağrılırsa, saldırgan kendi bilgisayarından asla ulaşamayacağı bu kaynaklara sunucuyu aracı yaparak ulaşır. Bulut metadata servisi özellikle kritiktir, çünkü bazı yapılandırmalarda sunucuya atanmış geçici erişim anahtarlarını döndürür.

CSRF ile aynı şey değil

İsimler benzese de iki açık farklı tarafı kandırır. CSRF'te kandırılan, oturumu açık olan kullanıcının tarayıcısıdır: tarayıcı, kullanıcının haberi olmadan onun çerezleriyle bir istek gönderir. SSRF'te kandırılan ise sunucunun kendisidir ve istek, sunucunun ağ konumunun ve yetkilerinin tamamını taşır. OWASP Top 10'un 2021 sürümünde SSRF ayrı bir kategori (A10) olarak yer alıyordu; 2025 sürümünde ise CWE-918 olarak Bozuk Erişim Kontrolü (A01) kategorisinin altına alındı. Etiket değişse de risk aynıdır.

Riskli desen ve daha güvenli hali

Aşağıdaki ilk satır, sorunun en sade halidir: kullanıcının gönderdiği adres hiçbir kontrol yapılmadan çağrılıyor.

// Riskli: kullanıcının verdiği adres olduğu gibi çağrılıyor
const res = await fetch(req.query.url);

// Daha güvenli: adres ayrıştırılıyor ve izin listesine göre kontrol ediliyor
const target = new URL(req.query.url);
if (target.protocol !== "https:") throw new Error("Yalnızca HTTPS");
if (!ALLOWED_HOSTS.has(target.hostname)) throw new Error("İzin verilmeyen alan adı");
const res = await fetch(target, { redirect: "error", signal: AbortSignal.timeout(5000) });

İkinci blok bir başlangıçtır, tam çözüm değildir. Sağlam bir savunmada şu katmanlar birlikte bulunur:

• İzin listesi (allowlist): Hedefler biliniyorsa yalnızca onlara izin verin. Yasaklı adres listesi (denylist) tutmak cazip gelir ama IP adreslerinin farklı yazım biçimleri ve URL ayrıştırıcıları arasındaki farklar yüzünden kolayca delinir; OWASP de bu nedenle izin listesini önerir.
• Çözümlenen IP'nin kontrolü: Herkese açık URL'leri kabul etmek zorunda olan araçlarda alan adının DNS ile çözüldüğü tüm A ve AAAA kayıtları kontrol edilmeli; özel ağ aralıkları, loopback ve link-local adresler reddedilmeli, istek de doğrulanan IP'ye gönderilmelidir. Aksi halde doğrulama anında masum görünen bir alan adı, istek anında iç ağdaki bir adrese çözülebilir.
• Yönlendirmeleri takip etmemek: İlk adres doğrulansa bile sunucu bir yönlendirmeyi körü körüne izlerse kontrol anlamsızlaşır. Yönlendirme gerekiyorsa her adım aynı doğrulamadan geçmelidir.
• Sınırlar: Zaman aşımı, yanıt boyutu sınırı ve yalnızca http/https şemaları. Yanıtın ham halini kullanıcıya döndürmemek de sızabilecek bilgiyi azaltır.

Ağ katmanında ikinci savunma hattı

Uygulama kodundaki kontroller bir gün bir hata yüzünden atlanabilir; bu yüzden ağ tarafında da önlem almak gerekir. Dışarıya istek atan bileşeni ayrı bir servise veya konteynere taşımak ve bu servisin çıkış trafiğini bir güvenlik duvarı kuralıyla iç ağa kapatmak, kod tarafındaki bir hatanın etkisini büyük ölçüde sınırlar. Bulut ortamında metadata servisinin oturum token'ı isteyen sürümünü (AWS'de IMDSv2) zorunlu kılmak ve sunucuya yalnızca gerçekten ihtiyaç duyduğu yetkileri vermek, yani en az yetki ilkesini uygulamak, SSRF başarılı olsa bile ele geçirilebilecek şeyi küçültür.

Açığın izini sürmek

SSRF'i bulmanın en verimli yolu, kod tabanında “kullanıcıdan URL, alan adı veya IP alan her yeri” listelemektir: içe aktarma formları, entegrasyon ayarları, webhook tanımları, görsel işleme kütüphaneleri, XML ve SVG ayrıştırıcıları. Üretimde ise uygulama sunucusundan iç ağ aralıklarına veya metadata adresine giden beklenmedik bağlantılar, loglarda ve çıkış trafiği izlemesinde alarm üretecek şekilde takip edilmelidir. Yetkili bir sızma testi de bu tür özellikleri özellikle hedef alır.