Post cover image

August 1, 2026

Server-Side Request Forgery (SSRF)

Web Güvenliği Serisi — Bölüm 4

By Yusufbarut

8 min read

Giriş

Bir web uygulaması kullanıcıdan aldığı URL'lere güvenerek başka sistemlere istek gönderiyorsa, bu özellik saldırganlar tarafından ciddi güvenlik risklerine dönüştürülebilir. İşte tam bu noktada karşımıza Server-Side Request Forgery (SSRF) çıkar.

Serinin önceki bölümlerinde SQL Injection ile veritabanına, CSRF ile kullanıcının tarayıcısına nasıl güvenilmeyeceğini konuşmuştuk. Bu bölümde işler biraz değişiyor: artık kandırdığımız taraf kullanıcı değil, sunucunun kendisi. Uygulamayı, kendi adına istemediği yerlere istek atan bir vekile dönüştürüyoruz.

Kulağa soyut geliyor olabilir ama pratikte SSRF, cloud altyapılarının en sevmediği zafiyetlerden biri. Çünkü doğru koşullarda bir SSRF, sadece "sunucu başka bir siteye istek attı" demek değil; AWS metadata servisine sızıp geçici erişim anahtarları çalınmasına, iç ağdaki admin panellerine dokunulmasına, hatta bazen tüm cloud hesabının ele geçirilmesine kadar gidebiliyor.

Bu yazıda SSRF'nin ne olduğunu, nasıl çalıştığını, hangi türlerinin bulunduğunu, gerçek bir senaryo üzerinden nasıl istismar edildiğini, PortSwigger'ın laboratuvarında ve Burp Suite ile pratikte nasıl test edildiğini ve son olarak nasıl korunulacağını adım adım ele alacağız.

Hazırsanız başlayalım.

SSRF Nedir?

Server-Side Request Forgery (SSRF), bir saldırganın sunucuyu kendi adına, normalde erişemeyeceği bir hedefe istek göndermeye zorlamasıdır. Yani mağdur, kullanıcı değil — bizzat sunucunun kendisidir.

Web uygulamalarında sıkça karşılaşılan bir ihtiyaç var: sunucunun başka bir kaynaktan veri çekmesi. Örnek senaryolar:

  • Bir "profil resmi URL'si ekle" özelliği
  • PDF oluşturucuların bir web sayfasını render etmesi
  • Webhook doğrulama sistemleri
  • "Link önizlemesi" gösteren sosyal medya benzeri uygulamalar
  • Dış API'lerden veri çeken entegrasyonlar

Bu özelliklerin hepsinde ortak bir nokta var: sunucu, kullanıcının verdiği bir URL'ye istek atıyor. Eğer bu URL üzerinde yeterli doğrulama yapılmazsa, saldırgan https://example.com/resim.jpg yerine http://169.254.169.254/latest/meta-data/ veya http://localhost:6379/ gibi bir adres verebilir. Sunucu bu isteği kendi yetkileriyle, kendi ağından gönderir — ve saldırgan normalde asla ulaşamayacağı bir kaynağa dolaylı yoldan erişmiş olur.

Kısacası SSRF, güvenin yanlış yerde kurulmasının bir sonucudur. Uygulama "bu URL zaten kullanıcı tarafından verildi, sorun olmaz" diye düşünür; oysa asıl soru şu olmalıdır: bu isteği benim sunucum mu, yoksa saldırgan mı yönlendiriyor?

None

SSRF Nasıl Çalışır?

None

Mekanizmayı basitleştirelim. Normal bir akışta işler şöyle yürür:

Kullanıcı  →  Web Uygulaması  →  Dış Kaynak (resim, API, vs.)

Kullanıcı bir URL verir, sunucu o URL'ye gider, veriyi alır, kullanıcıya gösterir. Sorun yok gibi görünüyor — ta ki kullanıcı yerine bir saldırgan bu URL'yi kontrol edene kadar.

Saldırgan  →  Web Uygulaması  →  İç Ağ / Localhost / Cloud Metadata
                 (güvenilir sunucu     (normalde dışarıdan
                  kimliğiyle istek       erişilemeyen kaynaklar)
                  atıyor)

Burada kritik nokta şu: istek, saldırganın kendi makinesinden değil, hedef sunucunun içinden gönderiliyor. Bu da demek oluyor ki:

  • Firewall kuralları by-pass edilebilir, çünkü istek "içeriden" geliyor.
  • IP tabanlı erişim kısıtlamaları işe yaramaz, çünkü sunucunun kendi IP'si güvenilir kabul edilir.
  • Sunucunun sahip olduğu kimlik bilgileri (cloud IAM rolleri, iç servis token'ları) saldırganın eline geçebilir.

Tipik bir istismar akışı şöyle işler:

  1. Saldırgan, URL girişi alan bir alan bulur (resim URL'si, webhook adresi, dosya import özelliği vb.).
  2. Bu alana normal bir dış URL yerine iç kaynağa işaret eden bir adres girer: http://127.0.0.1:PORT, http://169.254.169.254/..., http://internal-service.local gibi.
  3. Sunucu bu isteği kendi adına gönderir.
  4. Dönen yanıt (varsa) kullanıcıya bir şekilde geri yansıtılır — resim boyutu hatası, HTTP durum kodu, işlem süresi farkı ya da doğrudan içerik olarak.
  5. Saldırgan bu yanıttan bilgi sızdırır veya iç sistemde işlem tetikler.

SSRF Türleri

SSRF tek bir kalıba sığmaz.

None

Yanıtın nasıl geri döndüğüne göre ikiye, hedefin nerede olduğuna göre de farklı alt kategorilere ayrılır.

1. Basic (In-Band) SSRF

Sunucunun yaptığı isteğin sonucu doğrudan kullanıcıya gösterilir. Örneğin uygulama "URL'den resim getir" derken, aslında getirdiği içeriği ekranda render ediyorsa, saldırgan iç bir servisin cevabını doğrudan görebilir. Bu, tespiti ve istismarı en kolay SSRF türüdür.

2. Blind SSRF

Sunucu isteği gönderir ama sonucu hiçbir şekilde kullanıcıya geri yansıtmaz. Bu durumda saldırgan doğrudan veri göremez, ama şunları gözlemleyebilir:

  • Yanıt süresindeki farklar (zamanlama tabanlı çıkarım)
  • HTTP durum kodlarındaki farklılıklar (var/yok ayrımı)
  • Kendi kontrolündeki bir sunucuya (Burp Collaborator gibi) gelen DNS/HTTP isteği

Blind SSRF daha zor tespit edilir ama hâlâ ciddi bir risktir; özellikle port tarama veya iç ağ keşfi için kullanılabilir.

3. Hedefe Göre Ayrım

  • İç ağa yönelik SSRF: 127.0.0.1, localhost, 10.x.x.x, 192.168.x.x gibi özel IP aralıklarına veya iç DNS isimlerine istek gönderme. Amaç genelde iç ağdaki başka servisleri (admin panelleri, veritabanları, Redis, Elasticsearch gibi kimlik doğrulaması zayıf servisler) keşfetmek.
  • Cloud metadata servisine yönelik SSRF: AWS, GCP, Azure gibi bulut sağlayıcılarının her instance'a sağladığı 169.254.169.254 gibi özel bir metadata adresi vardır. Bu adrese yapılan istek, o an sunucuya atanmış geçici kimlik bilgilerini (access key, secret key, session token) döndürebilir. SSRF'nin en tehlikeli sonuçlarından biri budur.
  • Aynı sunucuya yönelik SSRF (localhost SSRF): Uygulamanın sadece localhost'tan erişilebilen bir yönetim panelini veya debug endpoint'ini hedef almak.

Aşağıdaki tablo bu türleri özetliyor:

Tür Yanıt Görünür mü? Tipik Hedef Tespit Zorluğu Basic (In-Band) Evet Dış/iç servisler, resimler, API'ler Kolay Blind Hayır İç servisler, port tarama Orta-Zor Cloud Metadata SSRF Genelde Evet (yansıtılırsa) 169.254.169.254 Orta İç Ağ Keşfi Genelde Hayır (zamanlama ile) 127.0.0.1, 10.x.x.x Zor

Gerçek Bir Senaryo

None

Teoriyi somutlaştıralım. Diyelim ki bir SaaS uygulaması, kullanıcıların profillerine dış bir URL üzerinden avatar eklemesine izin veriyor:

POST /profile/avatar
{
  "avatar_url": "https://saldirgan-sitesi.com/resim.jpg"
}

Sunucu bu URL'ye gidiyor, resmi indiriyor, işleyip kullanıcı profiline kaydediyor. Uygulama bu isteği yaparken bir cloud ortamında (örneğin AWS EC2 üzerinde) çalışıyor.

Saldırgan bu alanı normal bir resim URL'si yerine şöyle değiştirirse:

{
  "avatar_url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"
}

Sunucu, kendi bakış açısından "kullanıcının verdiği bir URL'ye" istek atıyor sadece. Ama bu adres aslında EC2 instance'ının kendi metadata servisi. Eğer uygulama dönen içeriği herhangi bir şekilde (hata mesajında, önizlemede, log'da) kullanıcıya sızdırıyorsa, saldırgan o instance'a atanmış IAM rolünün adını görür. Bir adım sonra:

http://169.254.169.254/latest/meta-data/iam/security-credentials/<rol-adi>

isteğiyle geçici AccessKeyId, SecretAccessKey ve Token değerlerini elde edebilir.

None

Bu bilgilerle saldırgan, AWS CLI üzerinden o rolün yetkisi dahilinde S3 bucket'larını listeleyebilir, EC2 instance'larını yönetebilir, hatta bazı yanlış yapılandırılmış ortamlarda tüm hesaba sızabilir.

Burada kritik olan şey: saldırgan hiçbir zaman AWS kimlik bilgilerini "çalmadı" — uygulamanın kendisi, saldırganın yönlendirdiği bir istekle bu bilgileri kendi eliyle teslim etti. SSRF'nin gerçek dünyada bu kadar korkulan bir zafiyet olmasının sebebi tam olarak bu: küçük bir doğrulama eksikliği, tüm cloud altyapısının anahtarlarını saldırgana teslim edebiliyor.

PortSwigger Laboratuvarı

None

Teoriyi elle test etmek isteyenler için PortSwigger'ın Web Security Academy'sinde SSRF konusuna ayrılmış bir dizi ücretsiz laboratuvar bulunuyor. Bunlardan biri, "Basic SSRF against the local server" senaryosu üzerinden ilerliyor. Genel akış şu şekilde:

  1. Uygulama bir "stok kontrol" (stock check) özelliği sunuyor. Bu özellik, ürün sayfasındaki bir formun arka planda dahili bir API'ye istek atmasıyla çalışıyor.
  2. Bu isteğin gövdesinde bir stockApi parametresi var ve değeri açıkça bir URL: [http://stock.weliketoshop.net:8080/product/stock/check?productId=1&storeId=1](http://stock.weliketoshop.net:8080/product/stock/check?productId=1&storeId=1.).
  3. Bu parametre doğrudan kullanıcı tarafından kontrol edilebiliyor — yani sunucu, verilen herhangi bir URL'ye istek atmaya hazır.
  4. Laboratuvarın amacı, bu parametreyi değiştirerek sunucunun localhost üzerinde çalışan gizli bir admin panelini (/admin gibi) bulup, oradan bir kullanıcıyı silmek.

Adımlar özetle:

  • İstek Burp Suite'te yakalanır.
  • stockApi parametresinin değeri http://localhost/admin olarak değiştirilir.
  • Sunucu bu isteği kendi adına gönderdiği için, dışarıdan erişilemeyen /admin sayfasının içeriği yanıt olarak döner.
  • Sayfa içeriğinde kullanıcı silme linkleri görülür (örneğin /admin/delete?username=carlos).
  • Bu link de aynı şekilde stockApi parametresi üzerinden tekrar istenerek işlem tamamlanır.

Bu laboratuvar, SSRF'nin en temel ama en öğretici formunu gösteriyor: sunucunun kendisi, dışarıdan erişilemeyen bir sayfaya erişim sağlayan bir köprüye dönüşüyor.

Burp Suite ile Test

None

Gerçek bir uygulamada SSRF ararken izlenebilecek pratik bir metodoloji şöyle:

1. URL alan noktalarını belirleyin. Proxy sekmesinde trafiği izlerken; resim URL'si, webhook adresi, PDF/rapor oluşturma linki, "link önizleme" özelliği, dosya import/export URL'si gibi kullanıcı girdisi alan her noktayı işaretleyin.

2. İsteği Repeater'a gönderin. Şüpheli bir parametre bulduğunuzda Burp Repeater'da bu isteği tekrar tekrar değiştirip gönderebilirsiniz. Öncelikle zararsız bir dış URL ile (örneğin kendi Burp Collaborator adresinizle) isteğin gerçekten sunucudan gittiğini doğrulayın.

3. Collaborator ile blind SSRF tespiti yapın. Burp Collaborator, size özel bir domain üretir. Bu domain'i şüpheli parametreye yerleştirip isteği gönderin. Eğer Collaborator sekmesinde bir DNS ya da HTTP isteği düşerse, sunucunun sizin verdiğiniz adrese gerçekten istek attığını kanıtlamış olursunuz — yanıt görünmese bile.

4. İç adresleri deneyin. Collaborator ile doğruluğu kanıtlandıktan sonra sırasıyla:

gibi hedefleri deneyerek hem açık portları hem de yanıt farklarını (durum kodu, süre, içerik uzunluğu) kaydedin.

5. Filtre bypass tekniklerini test edin. Birçok uygulama localhost veya 127.0.0.1 gibi kelimeleri filtreler. Bu noktada denenebilecek bazı teknikler:

None
  • Alternatif IP gösterimleri: http://127.1, http://0177.0.0.1 (oktal), http://2130706433 (decimal)
  • DNS rebinding: kendi domain'inizi kısa TTL ile iç bir IP'ye çözümlemek
  • Yönlendirme (redirect) zinciri: dış bir URL'nin sunucu tarafında takip edilen bir 302 ile iç adrese yönlendirilmesi
  • URL parser tutarsızlıklarından yararlanma: http://saldirgan.com@127.0.0.1/ gibi karışık formatlar

Bu adımların hepsi, uygulamanın URL doğrulamasının ne kadar "yüzeysel" olduğunu ortaya koymak için kullanılır. Sadece string eşleştirmesiyle yapılan filtreler, bu tür encoding ve format oyunlarına karşı genelde çok kırılgandır.

Korunma Yöntemleri

None

SSRF'ye karşı savunma, tek bir kontrolle değil, katmanlı bir yaklaşımla sağlanır.

🛡 1. Allowlist (izin listesi) kullanın, blocklist değil. "Şu domainlere/IP'lere gitme" demek yerine "sadece şu domainlere git" demek çok daha güvenlidir. Blocklist'ler her zaman bir bypass yöntemiyle atlatılabilir; allowlist ise varsayılan olarak reddeder.

🛡 2. DNS çözümlemesinden sonra IP kontrolü yapın. Sadece verilen hostname'e bakmak yetmez, çünkü DNS rebinding gibi tekniklerle hostname zararsız görünüp gerçek IP'de değişebilir. İsteği gönderirken çözümlenen gerçek IP'nin özel/rezerve aralıklarda (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16) olup olmadığını kontrol edin.

🛡 3. Cloud metadata servisine erişimi kısıtlayın. AWS'de IMDSv2 zorunlu hale getirilerek, basit bir GET isteğiyle metadata alınması engellenebilir (token tabanlı, hop-limit'li istekler gerektirir). GCP ve Azure'da da benzer koruma mekanizmaları mevcuttur.

🛡 4. Redirect'leri otomatik takip etmeyin. HTTP istemcinizin 3xx yönlendirmelerini otomatik takip etmesini kapatın veya her yönlendirmede hedefi yeniden doğrulayın.

🛡 5. Ağ segmentasyonu uygulayın. Dış isteklere maruz kalan uygulama sunucularının, hassas iç servislere (veritabanı, Redis, admin panelleri) doğrudan ağ erişimi olmamalı. Firewall kurallarıyla bu erişim en aza indirilmeli.

🛡 6. Yanıtı kullanıcıya olduğu gibi yansıtmayın. Sunucunun yaptığı dış isteğin ham yanıtını (header, body, durum kodu) doğrudan kullanıcıya göstermek, blind SSRF'yi bile in-band hale getirebilir. Yanıtları işleyip sadece gerekli veriyi döndürün.

🛡 7. Gereksiz protokolleri devre dışı bırakın. file://, gopher://, dict:// gibi protokoller genelde gerekli değildir ve SSRF'nin etkisini artırabilir (özellikle gopher, iç servislerle ham TCP konuşmasına izin verebilir). Sadece http:// ve https:// protokollerine izin verin.

None

Sonuç

SSRF, ilk bakışta "sunucu kullanıcının verdiği URL'ye gidiyor" kadar masum görünen bir özelliğin, doğru koşullarda tüm bir cloud altyapısının anahtarlarını saldırgana teslim edebildiği bir zafiyet sınıfı. SQL Injection'da veritabanına, CSRF'de kullanıcının tarayıcısına duyulan yanlış güveni konuşmuştuk; SSRF'de ise mesele sunucunun kendi ağına ve kendi kimliğine duyduğu güven.

Savunma tarafında tek bir "sihirli" kontrol yok — allowlist, DNS/IP doğrulaması, metadata servisi kısıtlamaları ve ağ segmentasyonunun birlikte çalışması gerekiyor. Saldırgan tarafında ise Burp Collaborator gibi araçlarla blind SSRF'leri bile ortaya çıkarmak mümkün.

Serinin bir sonraki bölümünde farklı bir başlığa geçiyoruz. Yorumlarda hangi zafiyeti görmek istediğinizi yazabilirsiniz.

Kaynaklar

  • PortSwigger Web Security Academy — Server-side request forgery (SSRF)
  • OWASP — Server Side Request Forgery Prevention Cheat Sheet
  • AWS Documentation — Instance Metadata Service (IMDSv2)
  • PayloadsAllTheThings — SSRF Injection

📚 Bu Serinin Diğer Yazıları

-✅ Web Güvenliği Serisi — Bölüm 1:Cross-Site Scripting (XSS)

  • ✅ Web Güvenliği Serisi — Bölüm 2:SQL Injection
  • ✅ Web Güvenliği Serisi — Bölüm 3:Cross-Site Request Forgery (CSRF)
  • ✅ Web Güvenliği Serisi — Bölüm 4:Server-Side Request Forgery (SSRF) (Bu Yazı)
  • ⏳Web Güvenliği Serisi — Bölüm 5:File Upload Vulnerabilities(Yakında)