Web güvenliğine yeni girenlerin gözünde SSRF biraz "ikinci lig" bir açık gibi durur; XSS ve SQLi kadar anlatılmaz. Oysa son yılların en ağır bulut ihlallerinin bir kısmı SSRF ile başladı. Bu rehberde SSRF'i sıfırdan, lab üzerinde deneyebileceğiniz şekilde ele alıyorum. Amacım, kavramı ezberletmek değil, "neden çalışıyor" kısmını oturtmak.
Konuda anlatılacaklar
- SSRF nedir, neden tehlikelidir?
- Çalışma mantığı ve tipik güvenlik açığı deseni
- Türleri: temel (basic), kör (blind), yarı-kör
- Bulut metadata servisleri neden kritik hedef?
- Lab ortamı ve güvenli test
- Korunma yöntemleri ve güvenli kod
- Yasal uyarı
SSRF Nedir?
SSRF (Server-Side Request Forgery / Sunucu Taraflı İstek Sahteciliği), bir saldırganın uygulama sunucusunu kendi adına istek atmaya kandırdığı bir açıktır. Yani istek sizin tarayıcınızdan değil, hedef sunucudan çıkar. Bu, saldırgan için çok değerlidir: sunucu, dışarıdan erişemeyeceğiniz iç ağ kaynaklarına (localhost, 10.x.x.x, 169.254.x.x) erişebilir.
Klasik örnek: "URL'den resim çek", "bir web sayfasının önizlemesini oluştur", "webhook'u test et", "PDF'e uzak logo ekle" gibi özellikler. Uygulama, kullanıcının verdiği URL'ye gidip içeriği getiriyorsa ve bu URL yeterince kısıtlanmamışsa SSRF doğar.
Çalışma Mantığı
Diyelim bir servis şöyle çalışıyor:
Kod:
POST /api/fetch-preview
Content-Type: application/json
{ "url": "https://example.com/logo.png" }Sunucu bu URL'ye gidip yanıtı size döndürüyor. Saldırgan url'yi değiştirirse:
Kod:
{ "url": "http://127.0.0.1:8080/admin" }
{ "url": "http://169.254.169.254/latest/meta-data/" }
{ "url": "http://localhost:6379/" }Sunucu bu iç adreslere kendi ağından ulaşabildiği için, dışarıya kapalı yönetim panelleri, Redis gibi servisler veya bulut metadata uç noktaları aniden erişilebilir hale gelir.
SSRF Türleri
1) Temel (Basic / In-band) SSRF: Sunucunun getirdiği yanıt doğrudan size döner. En kolay sömürülenidir çünkü iç kaynağın cevabını okuyabilirsiniz.
2) Kör (Blind) SSRF: Sunucu isteği atar ama yanıtı size göstermez. Burada varlığı kanıtlamak için harici bir dinleyici kullanılır. Kendi kontrolünüzdeki bir sunucuya veya Burp Collaborator benzeri bir araca istek tetiklenip tetiklenmediğine bakılır:
Kod:
{ "url": "http://benim-dinleyicim.example/ssrf-test" }DNS veya HTTP isteği geldiyse kör SSRF doğrulanmış olur.
3) Yarı-kör: Yanıtın tamamı değil ama durum kodu, yanıt süresi veya hata mesajı gibi dolaylı sinyaller döner. Bu farklarla iç portların açık olup olmadığı anlaşılabilir (bir tür zamanlama tabanlı port tarama).
Neden Bulut Metadata Servisleri Kritik?
Bulut sağlayıcılarında örnekler, kendileri hakkında bilgi almak için özel bir iç IP kullanır: 169.254.169.254. Eski (IMDSv1) yapılandırmalarda bu uç nokta kimlik doğrulaması olmadan geçici kimlik bilgilerini dönebiliyordu. SSRF ile bu uç noktaya ulaşan saldırgan, sunucunun IAM rolüne ait anahtarları çalabilir; sonrası tam bir bulut hesabı ele geçirmeye kadar gider. AWS tarafında çözüm IMDSv2'yi (token zorunlu) kullanmaktır.
Lab Ortamı
SSRF'i güvenle denemek için hazır zafiyetli uygulamalar birebir. Kendi makinenizde Docker ile kurabilirsiniz:
Kod:
# OWASP Juice Shop
docker run --rm -p 3000:3000 bkimminich/juice-shop
# PortSwigger Web Security Academy ücretsiz SSRF lab'ları (tarayıcı üzerinden)
# https://portswigger.net/web-security/ssrfBurada kritik kural: yalnızca kendi kurduğunuz lab ortamında veya açıkça izin verilen bug bounty kapsamında test edin.
Korunma Yöntemleri
- Allowlist (beyaz liste): Kullanıcıdan gelen URL'yi serbest bırakmak yerine, yalnızca izin verilen alan adları/şemalar kabul edin. Blacklist yaklaşımı (127.0.0.1'i engelle) kolayca atlatılır (ör. 127.1, 0.0.0.0, ondalık IP, DNS rebinding).
- Şema kısıtı: Sadece http/https'e izin verin; file://, gopher://, dict:// gibi şemaları reddedin.
- İç ağ bloklama: Çözümlenen IP'yi kontrol edin; özel aralıkları (RFC 1918), loopback'i ve 169.254.0.0/16'yı reddedin. Çözümlemeyi yönlendirme sonrası tekrar yapın (DNS rebinding'e karşı).
- Yönlendirmeleri takip etmeyin ya da her adımda yeniden doğrulayın.
- IMDSv2 ve en az yetki (least privilege) IAM rolleri kullanın.
- Ağ segmentasyonu: İstek atan servisin iç yönetim ağına erişimini kısıtlayın.
Örnek bir Python kontrolü (basitleştirilmiş fikir):
Kod:
import ipaddress, socket
from urllib.parse import urlparse
ALLOWED_SCHEMES = {"http", "https"}
def is_safe(url):
p = urlparse(url)
if p.scheme not in ALLOWED_SCHEMES:
return False
ip = ipaddress.ip_address(socket.gethostbyname(p.hostname))
if ip.is_private or ip.is_loopback or ip.is_link_local:
return False
return TrueNot: Bu örnek eğitim amaçlıdır; gerçek hayatta TOCTOU ve DNS rebinding için istek anında da IP doğrulaması yapan, olgun bir kütüphane kullanmak gerekir.
Sonuç
SSRF'i tehlikeli yapan şey, tek başına bir açıktan çok bir köprü olması: dış dünyadan iç dünyaya. Bu yüzden savunmada da tek bir satır değil, katmanlı bir yaklaşım gerekir. Siz üretimde SSRF'i nasıl engelliyorsunuz, allowlist mi yoksa proxy katmanı mı tercih ediyorsunuz, yorumlarda konuşalım.
Yasal Uyarı
Bu rehber yalnızca kendi sistemlerinizde veya açıkça yetkilendirildiğiniz (yazılı izin, bug bounty kapsamı) ortamlarda uygulanmalıdır. İzinsiz sistemlere yönelik testler TCK 243-245 kapsamında suçtur.
Görsel: TurkTeam özgün kapak görseli
İmza
TurkTeam Yonetim | Bilgi ozgurdur, etik yon verir. | Beyaz sapkayi hic cikarma.