SSRF nedir?

SSRF (Server-Side Request Forgery), saldırganın bir web uygulamasını kullanarak sunucu tarafından istenmeyen bir adrese istek göndermesini sağlamasıdır. Uygulama kullanıcıdan bir URL alıyor ve bu URL'yi sunucuda açıyorsa, saldırgan dışarıdan erişilemeyen iç ağ servislerini, yerel yönetim arayüzlerini veya bulut metadata uç noktalarını hedefletebilir. Sorun, isteğin kullanıcının tarayıcısından değil, uygulamanın çalıştığı sunucudan çıkmasıdır.

SSRF nasıl çalışır?​

Bir uygulamanın resim içe aktarma, URL'den dosya indirme, webhook doğrulama veya uzaktaki XML/JSON kaynağını okuma özelliği olduğunu varsayalım. Uygulama şu tür bir istek kabul ediyor olsun:


Sunucu bu değeri alıp HTTP istemcisiyle çağırır ve sonucu işler. Uygulama yalnızca herkese açık alan adlarına istek gönderecek şekilde tasarlanmadıysa saldırgan URL'yi iç ağdaki bir hedefe yönlendirmeyi deneyebilir. Örneğin uygulama, normal bir dış adres yerine şirket ağındaki bir yönetim servisine veya sunucunun kendi yerel adresine bağlanabilir.

Buradaki temel risk, uygulamanın erişim yetkisidir. Sunucu bir kaynağa erişebiliyor, fakat normal kullanıcı o kaynağa doğrudan erişemiyorsa SSRF bu ağ ayrımını kötüye kullanabilir. İstek sonucunun kullanıcıya gösterilmesi şart değildir; bazı durumlarda yalnızca iç servise istek gönderilebilmesi bile etkili olur.

Somut örnek ve sonucu yorumlama​

Bir görsel içe aktarma özelliği yalnızca bir resim URL'si bekliyor olsun. Uygulama URL'yi doğrulamadan sunucuda indirirse saldırgan, dışarıdan görünmeyen bir servise istek gönderilmesini sağlayabilir. Sonuç uygulama yanıtında görünüyorsa iç servisin yanıtı sızabilir. Sonuç görünmüyorsa bile zaman aşımı, durum kodu veya yanıt süresi gibi davranışlar iç ağ hakkında bilgi verebilir.

Bu nedenle yalnızca kullanıcıya dönen gövdeyi filtrelemek yeterli değildir. Güvenlik kararı, isteğin gönderilmesinden önce verilmelidir. URL'nin biçimsel olarak geçerli olması veya alan adının güvenilir görünmesi tek başına güvenlik kanıtı değildir.

SSRF riskini azaltma adımları​

1. İhtiyacı netleştirin. Özellik yalnızca sabit ve önceden bilinen birkaç servise bağlanacaksa kullanıcıdan tam URL almayın; izin verilen hedefi uygulama yapılandırmasından seçtirin.
2. Hedefi izin listesiyle sınırlandırın. Şema, alan adı, port ve yol için beklenen değerleri ayrı ayrı doğrulayın. Kullanıcı girdisindeki alan adını yalnızca metin karşılaştırmasıyla güvenilir kabul etmeyin.
3. Alan adını çözdükten sonra oluşan IP adreslerini kontrol edin. Yerel ana makine, özel ağ, bağlantı-yerel, yayın, döngü ve diğer ayrılmış adres aralıklarına bağlantıyı engelleyin. DNS çözümlemesi ile bağlantı arasındaki değişim ihtimalini de tasarımda dikkate alın.
4. HTTP istemcisinde yönlendirmeleri varsayılan olarak kapatın veya her yönlendirme hedefini aynı kurallarla yeniden doğrulayın. Aksi halde güvenli görünen ilk URL, isteği yasaklı bir hedefe taşıyabilir.
5. Uygulamanın ağ çıkışını daraltın. Sunucunun yalnızca gerçekten ihtiyaç duyduğu dış servislere bağlanmasına izin veren güvenlik duvarı, proxy veya egress kuralları ekleyin.
6. Yanıt boyutu, bağlantı süresi ve indirme türlerini sınırlayın. Bu kontroller SSRF'yi tek başına çözmez; kötüye kullanımın iç ağ taramasına veya kaynak tüketimine dönüşmesini azaltır.
7. İstekleri kaydedin ve izleyin. Hedef alan adı, çözümlenen adres, bağlantı sonucu ve reddetme nedeni tanılamaya yardımcı olur; hassas yanıt gövdelerini gereksiz yere günlüklere yazmayın.

Sunucu tarafı isteklerinin güvenlik düzeyi, özelliğin amacına göre seçilmelidir. Aşağıdaki karar, gereksiz yere geniş bir URL erişimi açmayı önler.


Bağlantı öncesi yalnız bir DNS yanıtını kontrol edip istemcinin tekrar başka IP çözmesine izin vermeyin; gerçek bağlanılan adres ve TLS hostname doğrulaması birlikte korunmalıdır. IPv6, IPv4-mapped adresler ve yönlendirmelerin tüm hedefleri değerlendirilir. URL’de kullanıcı adı/parola kabul etmeyin; bir kaynaktaki Authorization/cookie bilgisini farklı hosta otomatik taşımayın. İç ağ servisi gerçekten gerekiyorsa serbest URL yerine sabit dar hedef ve ayrı yetkili servis akışı kullanın. Bulut metadata korumaları ek katmandır; genel egress/URL kontrolünün yerine geçmez.

Sık yapılan hatalar​

Yalnızca localhost'u engellemek: SSRF hedefleri tek bir yazımla sınırlı değildir. Farklı adres gösterimleri, DNS çözümlemesi ve yönlendirmeler hesaba katılmadan yapılan tekil bir metin filtresi aşılabilir.

Alan adını kontrol edip IP'yi kontrol etmemek: Güvenilir görünen bir alan adı yasaklı bir adrese çözümlenebilir veya çözümleme sonradan değişebilir. İzin kararı bağlantının gerçek hedefi için uygulanmalıdır.

İç servisin kimlik doğrulamasına güvenmek: Ağ içinde bulunabilen bir servis, özel kimlik bilgisi gerektirmeyebilir; ayrıca SSRF bazı ortamlarda sunucunun sahip olduğu kimlik bilgileriyle yapılan isteklerden yararlanabilir. Ağ kısıtlaması ve uygulama doğrulaması birlikte kullanılmalıdır.

Yanıtı gizlemenin yeterli olduğunu sanmak: Yanıt gövdesini kullanıcıya vermemek bilgi sızıntısını azaltabilir, ancak sunucunun iç hedefe istek göndermesini durdurmaz. Asıl kontrol, bağlantı kurulmadan önceki hedef doğrulaması ve ağ çıkış kısıtlamasıdır.

Kaynaklar​

• OWASP: SSRF Prevention

Sık sorulan sorular​

SSRF yalnızca HTTP servislerini mi etkiler?​

Hayır. Risk, uygulamanın desteklediği protokollere ve istemci kitaplıklarına göre farklı ağ protokollerine de uzanabilir. İhtiyaç olmayan protokolleri kapatmak ve yalnızca gereken şemaları kabul etmek gerekir.

SSRF ile CSRF aynı şey midir?​

Hayır. CSRF'de kurban kullanıcının tarayıcısı üzerinden yetkili bir işlem yaptırılmaya çalışılır. SSRF'de ise istek, uygulama sunucusunun ağ konumundan gönderilir; temel risk iç kaynaklara erişimdir.

Bir URL'nin dış alan adına ait olması SSRF riskini ortadan kaldırır mı?​

Hayır. DNS yanıtı, yönlendirme veya ağ yapılandırması nedeniyle istek beklenmeyen bir adrese ulaşabilir. Hedef doğrulaması bağlantı kurulmadan önce ve yönlendirmeler boyunca sürdürülmelidir.