Post cover image

July 26, 2026

SSRF (Sunucu Tarafı İstek Sahteciliği)

Bir kuryenin, elindeki paketi kendisine söylenen her adrese teslim ettiğini düşünün, o adresi kimin verdiğine ya da adresin gerçekten…

By MuharremAltmisoglu

13 min read

Bir kuryenin, elindeki paketi kendisine söylenen her adrese teslim ettiğini düşünün, o adresi kimin verdiğine ya da adresin gerçekten güvenli olup olmadığına hiç bakmadan sadece paket teslimine odaklanmış bir kurye. SSRF de tam olarak bu güven zafiyetini sömürür: sunucu, kendisine verilen adresin güvenilir olup olmadığını sorgulamadan oraya gider. İşte bu, SSRF (Server-Side Request Forgery) zafiyetinin özünde yatan mantık.

Bu yazıda SSRF'in ne olduğunu, kaç farklı türe ayrıldığını, hangi durumlarda ve nerelerde karşımıza çıktığını, gerçek dünyada ne gibi sonuçlara yol açabildiğini ve geliştiricilerin bu açığı nasıl kapatabileceğini adım adım ele alacağız; anlattıklarımızı bir PortSwigger lab örneğiyle de destekleyeceğiz.

SSRF Nedir?

SSRF (Server-Side Request Forgery), bir saldırganın sunucuyu kandırarak kendi belirlediği bir adrese istek göndermeye zorlamasıdır. Yani saldırgan hedefe doğrudan erişmiyor; bunun yerine sunucuyu, sunucunun adına ve sahip olduğu yetkilerle istek gönderen bir tür "vekil" (proxy) olarak kullanıyor.

Daha teknik bir ifadeyle SSRF, bir web uygulaması dış kaynaklardan bir URL veya IP adresi aldığında ve bu kaynağa sunucu seviyesinde bir HTTP isteği gönderdiğinde ortaya çıkar. Uygulama, kullanıcı tarafından sağlanan bu adresi yeterince doğrulamadan veya temizlemeden işlerse, saldırgan sunucuyu iç ve dış ağlardaki herhangi bir hedefe istek göndermesi için manipüle edebilir. Bu da sunucunun güvenlik duvarının arkasındaki hassas sistemlere bir erişim kapısı açar.

Örneğin bir web sitesi başka bir siteden bir görselin URL'sini alıp kendi sayfasında gösteriyorsa ve bu URL girdisi düzgün filtrelenmiyorsa, saldırgan http://127.0.0.1/admin gibi sunucunun kendi üzerindeki bir adresi vererek, sunucunun kendi yönetim paneline istek yapmasını sağlayabilir. Bunun neden bu kadar tehlikeli olduğunu aşağıdaki "Sunucunun kendisine karşı SSRF" bölümünde detaylıca ele alacağız.

Teknik literatürde bu zafiyet CWE-918 olarak kodlanmıştır ve OWASP Top 10 listesinde ayrı bir kategori olarak yer alır. CSRF (Cross-Site Request Forgery) ile karıştırılmamalıdır: CSRF, bir kullanıcının kimliğini kötüye kullanarak onun adına işlem yaptırır; SSRF ise doğrudan sunucunun kendisini hedef alır ve sunucunun kimliğiyle istek gönderilmesini sağlar.

None

Basit Bir Örnek: URL Önizleme Özelliği

Birçok uygulamada "bir link yapıştır, önizlemesini görelim" tarzı bir özellik bulunur (Slack, Discord, birçok e-ticaret sitesi gibi). Geliştiricinin yazdığı basit bir akış şöyle işler:

  1. Kullanıcı bir URL girer.
  2. Sunucu bu URL'ye bir HTTP isteği gönderir.
  3. Gelen yanıtı (başlık, resim, açıklama) alıp kullanıcıya önizleme olarak gösterir.

Sorun şurada: sunucu, kullanıcının girdiği URL'nin nereye gittiğini kontrol etmez. Kullanıcı normal bir web sitesi linki yerine http://169.254.169.254/ (bulut sağlayıcıların her sunucu için tanımladığı, sadece o sunucunun kendisinden erişilebilen bir iç adres sunucu buraya baktığında kendi erişim anahtarlarını/kimlik bilgilerini öğrenir) ya da http://localhost:8080/admin (sunucunun kendi üzerinde, farklı bir portta çalışan yönetici paneli) gibi bir adres girerse, sunucu bu isteği de aynı güvenle gönderir çünkü isteği gönderen sunucunun kendisidir, dışarıdan bakan bir firewall bunu "sunucudan gelen normal bir istek" olarak görür ve engellemez.

SSRF Türleri

Yukarıdaki örnek, aslında SSRF'in yalnızca bir türüydü. Bu zafiyeti, saldırganın sonucu görüp göremediğine ve isteğin nereye gittiğine göre birkaç farklı şekilde sınıflandırabiliriz.

Temel SSRF

Yukarıdaki URL önizleme örneğinde olduğu gibi, saldırgan sunucuyu belirlediği bir adrese istek göndermeye zorlar ve sonucu doğrudan ekranında görür. Örneğin 169.254.169.254 adresini girer, sunucu isteği gönderir ve dönen içeriği (kimlik bilgileri, sayfa içeriği ne ise) doğrudan saldırgana gösterir. Bu, en yaygın ve en kolay istismar edilen türdür çünkü sonucu görmek, doğrulamayı ve devamını getirmeyi kolaylaştırır.

Kör SSRF

Bu türde sunucu isteği yine gönderir, ama sonucu saldırgana hiç göstermez ne başarılı ne başarısız olduğuna dair ekranda hiçbir değişiklik olmaz. Saldırgan, isteğin gerçekten gönderilip gönderilmediğini anlamak için genellikle kendi kontrolündeki başka bir sunucuyu kullanır: sunucuyu, o kendi adresine bir istek göndermeye zorlar, kendi sunucusunda bu isteğin gelip gelmediğine bakarak SSRF'in çalıştığını doğrular. Sonucu göremediği için istismarı daha zordur, ama yine de iç ağı taramak, dahili servisleri tetiklemek ve bazı durumlarda sunucu üzerinde kod çalıştırmak (RCE) gibi ciddi sonuçlara yol açabilir.

Hedefine Göre: İç Ağa Yönelik ve Dış Sistemlere Yönelik SSRF

SSRF ayrıca, sunucunun hangi yöne istek göndermeye zorlandığına göre de ikiye ayrılabilir:

  • İç ağa yönelik (internal) SSRF: Saldırgan, sunucuyu kendi iç ağındaki (firewall'ın arkasındaki) servislere yönetici panelleri, veritabanı arayüzleri, metadata servisi gibi istek göndermeye zorlar. En sık karşılaşılan ve en kritik SSRF türü budur, çünkü hedef normalde dışarıdan hiç erişilemeyen bir kaynaktır.
  • Dış sistemlere yönelik (external) SSRF: Saldırgan burada başkasının sunucusunu kullanarak, kendisinin ulaşamadığı ya da ulaşmak istemediği başka bir sisteme (üçüncü bir tarafa) istek attırıyor. Bunu yapmasının iki temel amacı var:

1. Kimliğini gizlemek (o sunucuyu bir çeşit "araç" gibi kullanmak): Diyelim saldırgan bir bankaya saldırmak istiyor ama kendi bilgisayarından direkt saldırırsa yakalanabilir, IP'si ortaya çıkar. Bunun yerine açık bulduğu bir sunucuya gidip "sen şu bankanın sitesine şu isteği gönder" diyor. O sunucu bu isteği kendi gönderiyor, banka tarafında bakıldığında saldırı o sunucudan geliyormuş gibi görünüyor. Yani gerçek saldırgan hiç görünmüyor, günahı o sunucu yüklenmiş oluyor.

2. Üçüncü tarafın o sunucuya olan güvenini kötüye kullanmak: Bazı sistemler "bu istek tanıdığım/güvendiğim bir yerden geliyorsa kabul et" mantığıyla çalışıyor (örneğin sadece belirli IP'lere izin veriyor). Eğer açık bulunan sunucu zaten o sistemin güvendiği IP'lerden biriyse, saldırgan onu bir "anahtar" gibi kullanıyor. Kendisi o sisteme normalde hiç giremezken, o sunucu üzerinden sırf ona güvenildiği için korumalı sisteme girmiş oluyor.

SSRF Hangi Durumlarda Ortaya Çıkar?

1. URL Önizleme / Link Fetch Özellikleri Yukarıdaki örnekte olduğu gibi, kullanıcının verdiği bir linki sunucunun ziyaret edip içeriğini getirdiği her özellik (link önizleme, RSS feed okuyucu, "resmi URL'den yükle" gibi) potansiyel bir SSRF noktasıdır.

2. Avatar/Resim Yükleme (URL'den Dosya Çekme) Birçok uygulama, kullanıcının bir resmi bilgisayarından yüklemek yerine, doğrudan bir URL vererek yüklemesine izin verir örneğin "profil fotoğrafı için bir link yapıştır" özelliği. Sunucu bu durumda kullanıcının verdiği adrese gidip resmi indirir ve kendi sisteminde saklar. Eğer sunucu bu adresin gerçekten bir resim sunucusuna mı yoksa iç ağdaki başka bir servise mi gittiğini kontrol etmiyorsa, kullanıcı resim linki yerine iç ağdaki bir adresi (http://192.168.0.5/admin gibi) verebilir. Sunucu bunu da aynı şekilde "indirmeye" çalışır bu da klasik bir SSRF anıdır. Bu yazının başındaki giriş örneği tam olarak bu senaryodur.

3. Webhook ve Entegrasyon Ayarları Birçok uygulama, kullanıcının kendi sunucusuna bildirim gönderilmesi için bir "webhook URL'si" girmesine izin verir. Sunucu bu URL'ye düzenli olarak istek atar. Eğer kullanıcı buraya iç ağdaki bir adresi yazarsa, sunucu her tetiklendiğinde o iç adrese istek göndermeye devam eder.

4. PDF/Belge Oluşturucular Bazı uygulamalar, kullanıcının girdiği bir HTML içeriğini PDF'e çevirme özelliği sunar — örneğin bir faturayı veya raporu "PDF olarak indir" butonu. Bu dönüştürme işlemini yapan servis, HTML içindeki veya gibi etiketleri okur ve bu etiketlerin içindeki adreslere kendisi istek gönderip içeriği getirir, tıpkı bir tarayıcının sayfayı render etmesi (HTML içeriğini işleyip görüntülenebilir hâle getirmesi) gibi. Saldırgan, bu HTML'i kendisi oluşturabildiği için, resim adresi yerine iç ağdaki bir servisin adresini yazabilir. PDF oluşturma motoru bu adrese de aynı güvenle gider; bu da servisi bir SSRF aracına dönüştürür.

<img src="…"> ne yapar?

Bu, bir web sayfasına resim eklemek için kullanılan HTML etiketidir. src özelliği, resmin nereden geleceğini belirtir:

< img  src = "https://ornek.com/logo.png" >

Servis bu satırı okuduğunda, src içindeki adrese gidip o resmi indirir ve sayfada gösterir. Yani etiketi kendi başına resmi içermez; sadece "git, şuradan bir resim getir ve burada göster" der. Saldırgan src="https://ornek.com/logo.png" yerine src="http://localhost/admin" yazarsa, PDF oluşturma servisi bu adrese de aynı güvenle gider.

Bu da bir HTML etiketi, ama resim değil, başka bir web sayfasını mevcut sayfanın içine gömmek için kullanılır sayfa içinde küçük bir "pencere" gibi düşünebilirsin (YouTube video gömme, harita gömme gibi özelliklerin arkasında genelde iframe vardır):

<iframe src= "https://ornek.com/harita.html" > </iframe>

Servis, src içindeki adrese gidip o sayfanın tamamını indirir ve mevcut sayfanın içine bir çerçeve içinde yerleştirir. Bu yüzden 'den bile daha tehlikeli olabilir: sadece bir resim dosyası bekler, ama tam bir HTML sayfasının içeriğini getirip gömer. Saldırgan src="http://localhost/admin" yazarsa, sadece "admin sayfası var mı yok mu" bilgisini değil, admin panelinin tüm içeriğini elde edebilir. PDF'i indirdiğinde, admin panelinin görünümünü birebir okuyabilir hale gelir.

Özetle, sadece bir resim dosyası getirir, tam bir sayfanın içeriğini getirir bu yüzden <iframe>, SSRF senaryosunda genelde daha fazla bilgi sızdırma potansiyeline sahiptir.

5. Kötü Yönetilen API'ler Harici kaynaklara veri göndermek veya harici kaynaklardan veri almak için tasarlanmış API endpoint'leri de sık karşılaşılan bir SSRF noktasıdır. Örneğin bir API'ye "şu adresteki veriyi bana getir" veya "sonucu şu webhook adresine gönder" şeklinde bir parametre veriliyorsa ve API bu adresi filtrelemeden doğrudan kullanıyorsa, sorun aynıdır: API, saldırganın verdiği adrese sunucunun kimliğiyle istek gönderir. Bu tür endpoint'ler genellikle "entegrasyon", "içe/dışa aktarma" veya "veri senkronizasyonu" gibi işlevlerde bulunur ve URL filtrelemesi çoğunlukla ya hiç yapılmaz ya da yalnızca yüzeysel bir format kontrolüyle (geçerli bir URL mi?) sınırlı kalır; adresin nereye gittiği hiç sorgulanmaz.

6. Sunucunun Kendisine Karşı SSRF (Loopback Saldırıları) Bazı SSRF saldırıları, iç ağdaki başka bir makineyi değil, doğrudan sunucunun kendisini hedef alır. Saldırgan, sunucuyu kendi kendine (127.0.0.1 veya localhost üzerinden) istek göndermeye zorlar.

Bunun neden tehlikeli olduğunu bir örnekle açıklayalım. Bir e-ticaret sitesinde, bir ürünün stokta olup olmadığını gösteren bir özellik düşünelim. Uygulama bu bilgiyi başka bir arka uç (back-end) sunucudan REST API üzerinden çekiyor. Kullanıcı bir ürüne baktığında, tarayıcı sunucuya şöyle bir istek gönderiyor olsun:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1

stockApi parametresinin değeri, sunucunun stok bilgisini almak için gideceği adres. Sunucu bu adrese kendi tarafından bir istek gönderir ve dönen sonucu kullanıcıya gösterir. Saldırgan, bu isteği kendisi gönderdiği için stockApi parametresini istediği gibi değiştirebilir:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://localhost/admin

Sunucu, /admin adresinin içeriğini alır ve olduğu gibi kullanıcıya geri gönderir. Normalde bu admin paneline dışarıdan giriş yapmadan erişilemez. Ama bu istek sunucunun kendisinden geldiği için, uygulama isteğin güvenilir bir konumdan geldiğini varsayar ve admin işlevlerine tam erişim sağlar. Böylece saldırgan, /admin sayfasındaki standart erişim kontrolünü hiç kimlik doğrulaması yapmadan atlatmış olur.

**Peki uygulamalar neden localhost'tan gelen isteklere bu kadar güveniyor?**Bunun birkaç yaygın sebebi vardır:

  • Erişim kontrolü genelde başka bir yerde yapılır: Kullanıcı girişi kontrolü çoğunlukla uygulamanın önündeki ayrı bir bileşende (reverse proxy, WAF gibi) yapılır. Sunucu kendi kendine bir istek gönderdiğinde, bu istek o dış bileşenden hiç geçmez, dolayısıyla kontrol de hiç çalışmaz.
  • "Acil durum" erişimi: Sistem yöneticisi şifresini kaybettiğinde sistemi kurtarabilsin diye, geliştiriciler bazen "sunucunun kendisinden gelen isteklere, giriş yapmadan da admin erişimi ver" gibi bir istisna tanımlar. Bu istisna, normalde sadece güvenilir bir yöneticinin sunucuya fiziksel/doğrudan erişimi olduğu varsayımına dayanır.
  • Farklı port, "gizli" sanılan arayüz: Admin paneli bazen ana uygulamadan farklı bir portta çalışır ve "dışarıdan zaten erişilemiyor" varsayımıyla ekstra bir kimlik doğrulama eklenmemiş olabilir.

Bu üç durumun ortak noktası şu: "localhost'tan gelen istek = güvenilir istek" varsayımı. SSRF, saldırganın sunucuyu kendi kendine istek göndermeye zorlayarak bu varsayımı sıfır maliyetle kötüye kullanmasına imkân tanır.

7. Bulut Metadata Servislerine Erişim Bu, SSRF'in en kritik ve en sık karşılaşılan sonucudur. AWS, Azure, GCP gibi bulut sağlayıcıları, her sunucu örneğine 169.254.169.254 gibi sabit bir "link-local" adresten erişilebilen bir metadata servisi sunar. Bu servis, o sunucunun geçici kimlik bilgilerini (IAM credentials), yapılandırma bilgilerini ve bazen SSH anahtarlarını döndürür.

169.254.169.254 nedir, neden bu sayı? Bu adres, 169.254.0.0/16 adı verilen "link-local" ağ bloğunun bir parçasıdır, yani hiçbir sunucu veya yerel ağla çakışmayacağı garanti edilen, resmi olarak ayrılmış özel bir bloktur. Bulut sağlayıcılar bu güvenli, çakışma riski olmayan bloğu meta veri servisleri için "uç nokta" (endpoint) olarak seçmiştir. AWS, GCP, Azure gibi neredeyse tüm büyük bulut sağlayıcılarında bu adres birebir aynıdır, çünkü asıl amaç gizlilik değil, her sunucunun kendi kendine "ben kimim, hangi yetkilere sahibim" sorusunu sorabileceği standart, öngörülebilir bir adres sağlamaktır.

Eğer bir uygulama SSRF'e açıksa, saldırgan sunucuyu şu adrese istek göndermeye zorlayabilir:

http://169.254.169.254/latest/meta-data/iam/security-credentials/

Bu tek istek, saldırgana o sunucunun bulut hesabına erişim sağlayan geçici kimlik bilgilerini verebilir, yani SSRF, doğrudan bir "sunucu ele geçirme"den, tüm bulut hesabının ele geçirilmesine kadar uzanabilir. 2019'daki Capital One veri ihlali, tam olarak bu senaryo üzerinden gerçekleşmiştir: yanlış yapılandırılmış bir web application firewall (WAF), SSRF ile istismar edilerek AWS metadata servisinden kimlik bilgileri çalınmış ve milyonlarca müşteri kaydına erişilmiştir.

8. İç Ağ Tarama (Port Scanning) Sunucu, dış dünyaya kapalı olan iç ağdaki diğer makinelere erişebilir durumdadır. Saldırgan, SSRF'i kullanarak sunucuyu iç ağdaki farklı IP/port kombinasyonlarına istek göndermeye zorlar. Bağlantı süresi, hata mesajı ya da yanıt farkına bakarak hangi portların açık/kapalı olduğunu, hatta iç ağda hangi servislerin çalıştığını tespit edebilir; dışarıdan hiç erişemeyeceği bir ağın haritasını böyle çıkarır.

9. Yanıtın Görünmediği Senaryolar (Blind SSRF Durumu) Bazı özelliklerde sunucu isteği gönderir, ama sonucu kullanıcıya hiç yansıtmaz (bkz. yukarıdaki "SSRF Türleri" bölümü); arka planda bir bildirim gönderme, log kaydı düşürme veya webhook tetikleme gibi fonksiyonlar tam olarak bu şekilde çalışır. Böyle bir durumda saldırgan ekranda hiçbir değişiklik göremez, ama isteğin gerçekten gönderilip gönderilmediğini out-of-band (bant dışı) tekniklerle doğrulayabilir.

Bant dışı (Out-of-Band / OOB), ana iletişim veya veri kanalından tamamen bağımsız, alternatif bir kanal veya yöntem kullanılması anlamına gelir. SSRF bağlamında bu şu şekilde işler: saldırgan kendi kontrolündeki ayrı bir sunucunun adresini test ettiği alana yazar, uygulamayı normal şekilde kullanır, ardından o sunucunun loglarına bakar. Eğer bir istek düşmüşse, yanıtı hiç görmese bile SSRF'in çalıştığını anlamış olur.

Bu tür özellikler, SSRF açısından gözden kaçması en kolay noktalardır çünkü test ederken uygulama arayüzünde hiçbir görsel ipucu yoktur; zafiyet varlığını sadece dışarıdaki bir kanal üzerinden ele verir.

Pratik ipucu: SSRF mi, XSS mi olduğunu nasıl ayırt ederim?

Bazen bir zafiyetin SSRF mi yoksa XSS mi olduğu net değildir çünkü ikisinde de kendi domainine bir isteğin düştüğü görülebilir. Kesin ayrımı yapmanın basit bir yolu var: Collaborator'a (ya da kendi dinleyici sunucuna) düşen isteğin IP adresine bak. Eğer istek senin kendi tarayıcının/bilgisayarının IP'sinden geliyorsa, bu bir XSS'tir, çünkü kod kurbanın tarayıcısında çalışıp oradan istek atmıştır. Eğer istek hedef uygulamanın sunucusunun IP'sinden geliyorsa, bu bir SSRF'tir, çünkü isteği sunucunun kendisi göndermiştir. Kısacası, istek kimin IP'sinden geldiyse zafiyet oradadır.

10. DNS Rebinding ile Filtre Atlatma Bazı uygulamalar SSRF'e karşı bir kontrol mekanizması kurar: kullanıcının verdiği domain'i çözümler (IP adresine çevirir), bu IP erişime kapalı olması gereken bir aralıktaysa (örneğin iç ağ veya metadata adresi gibi) isteği engeller. Sorun şu ki, kontrolün yapıldığı an ile isteğin gerçekten gönderildiği an aynı değildir; aralarında geçen sürede domain'in gerçek IP'si değişebilir.

Bunu adım adım görelim:

  1. Saldırgan kendi domain'ini (saldirgan-domaini.com) hazırlar ve bu domain'in DNS ayarında çok kısa bir TTL (Time To Live DNS kaydının ne kadar süre geçerli sayılacağını belirten değer) tanımlar, örneğin 1 saniye.
  2. Domain'i önce erişime kapalı olmayan, sıradan bir genel IP'ye yönlendirir (yani uygulamanın kontrolünü rahatça geçecek, kısıtlı bir aralıkta olmayan bir adrese).
  3. Saldırgan bu domain'i uygulamaya verir. Uygulama kontrol yapar: "saldirgan-domaini.com hangi IP'ye çözümleniyor?" → sıradan, izin verilen bir IP görür → kontrolü geçer.
  4. Kontrol geçtikten hemen sonra, saldırgan arka planda DNS kaydını erişime kapalı olması gereken bir adrese (169.254.169.254 gibi) değiştirir. TTL değeri çok kısa olduğu için (1 saniye), bu değişiklik neredeyse anında geçerli olur.
  5. Uygulama şimdi asıl isteği gönderir. Ama domain'i tekrar çözümler (çünkü önbellekteki TTL süresi çoktan dolmuştur), bu sefer erişime kapalı olması gereken IP'yi alır ve isteği doğrudan oraya gönderir.

Sonuç: uygulama "bu domain'e izin var" diye kontrolü geçmiş bir adrese istek gönderdiğini sanır, ama gerçekte istek tamamen farklı, erişime kapalı olması gereken bir adrese gitmiştir. Bu tekniğe DNS rebinding denir. Mantığı, önceki anlattığım konu olan race condition örnekleriyle birebir aynıdır, kontrol anı ile kullanım anı arasında bir boşluk vardır (TOCTOU — Time-Of-Check to Time-Of-Use) ve saldırgan bu boşluğu istismar eder. Buradaki tek fark, boşluğun bir veritabanı satırında değil, DNS'in önbellek süresinde olmasıdır.

PortSwigger Web Security Academy Üzerinden Örnek;

Buraya kadar SSRF'i teorik olarak ve varsayımsal senaryolarla ele aldık. Şimdi ise bu zafiyeti canlı, çalışan bir web uygulaması üzerinden göstermek istiyorum. Bu bölümde, PortSwigger'ın kasıtlı olarak güvenlik açıkları barındıran eğitim amaçlı platformu Web Security Academy üzerinde, Blind SSRF with out-of-band detection adlı lab'ı çözerek gerçek bir SSRF örneğini adım adım inceleyelim.

Örnek: Blind SSRF with out-of-band detection

Lab'ı açtığımızda karşımıza standart bir Web Security Academy e-ticaret sitesi çıkıyor. Adres çubuğunda lab'a özel benzersiz subdomain'i görüyoruz: 0a4f00b7037fcd7d8051eeef00c900b5.web-security-academy.net

None

Herhangi bir ürünün altındaki "View details" kısmına basıyorum ve isteği yakalıyorum, request/response kısmına bakıyorum. Burada dikkatimi Referer header'ı çekiyor:

Bu header, tarayıcının "hangi sayfadan geldim" bilgisini otomatik olarak sunucuya ilettiği kısımdır. Normalde sunucunun bu değeri sadece kaydetmesi gerekir, ziyaret etmesi değil. Merak ettiğim şey şu: acaba bu uygulama sadece kaydetmekle mi yetiniyor, yoksa arka planda gerçekten bu adrese bir istek mi atıyor? Eğer atıyorsa ve bu değeri ben belirleyebiliyorsam, sunucuyu kendi kontrolümdeki bir adrese istek atmaya zorlayabilirim demektir.

None

Bunu test etmek için isteği Repeater'a alıyorum ve Referer değerinin yerine Burp Collaborator'dan aldığım URL'yi yapıştırıp isteği gönderiyorum

Yanıt yine 200 OK olarak dönüyor ve sayfa hiçbir farkla karşılaşmadan normal şekilde görüntüleniyor; herhangi bir hata mesajı ya da görsel ipucu yok. Yani uygulama tarafında baktığımızda açığın var olup olmadığını anlayamıyoruz.

None

Bunun üzerine Collaborator sekmesini kontrol ediyorum ve isteği gönderdikten hemen sonra 3 yeni interaction düştüğünü görüyorum:

Kayıtlardan birine tıkladığımda, Collaborator sunucusunun xeffi4sbdenqffosyxn9zk91nstkhg55.oastify.com için bir DNS sorgusu aldığını, ardından da bir HTTP isteği geldiğini görüyorum. Ayrıca bu isteğin geldiği kaynak IP adresi de benim değil, hedef sunucuya ait yani isteği ben değil, sunucu kendisi atmış. Bu sonuç, sunucunun benim verdiğim Referer URL'sini arka planda gerçekten ziyaret ettiğinin kanıtı. Yani yanıt içeriğinde hiçbir fark olmamasına rağmen, uygulama sunucu tarafında bizim kontrolümüzdeki bir adrese istek atıyor. Böylece, yanıtta hiçbir iz olmasa da, bu SSRF açığını out-of-band kanal üzerinden başarıyla kanıtlamış oluruz.

None

Nasıl Kapatılır? Genel Önlemler

Tek bir kural SSRF'i kapatmaya yetmez. Gerçek çözüm üç katmanlı olmalıdır: sunucunun nereye gidebileceğini baştan sınırlamak, bunu ağ seviyesinde de garanti altına almak ve bu iki katmanı atlatmayı başaran bir saldırı denemesi olursa bunu fark edecek bir göz bulundurmak. Aşağıdaki altı yöntem, tam olarak bu üç katmanı kuruyor.

1. Allowlist (İzin Listesi) Kullanımı (Katman 1 — Uygulama Seviyesinde Sınırlama)

En sağlam savunma, "şu adreslere gitme" (denylist/blacklist) değil, "sadece şu adreslere git" (allowlist/whitelist) mantığıdır. Denylist yaklaşımı her zaman eksik kalır çünkü saldırgan, aynı IP adresini onlarca farklı şekilde (ondalık, onaltılık, oktal gösterim, IPv6 varyantları gibi) yazarak filtreyi atlatabilir. Allowlist'te ise uygulama sadece önceden tanımlı, güvenilen domain/IP'lere istek gönderebilir; listede olmayan hiçbir yere gidemez.

2. Çözümlenen IP'yi Doğrulamak (DNS Rebinding'e Karşı) (Katman 1 — Uygulama Seviyesinde Sınırlama)

Sadece girilen domain adını kontrol etmek yeterli değildir, çünkü domain adı zararsız görünüp arkasında tehlikeli bir IP'ye çözümlenebilir. Doğru yöntem: domain'i bir kere çözümleyip elde edilen IP adresini allowlist'e karşı doğrulamak, ardından isteği o doğrulanmış IP'ye göndermek ve domain'i tekrar tekrar çözümlememek. Ayrıca yönlendirmeleri (redirect) otomatik takip etmemek ya da her yönlendirme adımında IP'yi yeniden doğrulamak gerekir.

3. Kullanıcı Girdisini URL'nin Tamamına Değil, Sadece Güvenli Kısımlara Sokmak (Katman 1 — Uygulama Seviyesinde Sınırlama)

Mümkünse kullanıcının kontrol ettiği kısım, URL'nin sadece path veya query parametresi olmalı, hostname/scheme kısmı sabit ve geliştirici tarafından belirlenmiş olmalıdır. Örneğin https://api.güvenilirservis.com/ + kullanıcının girdiği path şeklinde bir yapı, kullanıcının tüm URL'yi (http:// + hostname + path) serbestçe belirleyebildiği bir yapıdan çok daha güvenlidir.

4. Ağ Seviyesinde Segmentasyon ve Egress Kontrolü (Katman 2 — Ağ Seviyesinde Garanti Altına Alma)

Uygulama katmanındaki doğrulama tek başına yeterli değildir; ağ seviyesinde de savunma olmalıdır:

  • "Deny by default" firewall/egress kuralları: Sunucunun sadece ihtiyaç duyduğu adreslere giden trafiğe izin verilmeli, geri kalan tüm giden bağlantılar varsayılan olarak engellenmelidir.
  • Private/link-local IP aralıklarının engellenmesi: 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 ve 169.254.0.0/16 gibi aralıklara giden trafik, gerçekten gerekmiyorsa ağ seviyesinde (proxy/NAT/gateway üzerinde) engellenmelidir. Böylece uygulama katmanındaki bir doğrulama atlatılsa bile, ağ bu isteğin fiilen ulaşmasını engeller.

5. Bulut Metadata Servisini Sıkılaştırmak (Katman 2 — Ağ Seviyesinde Garanti Altına Alma)

  • IMDSv2 zorunlu kılınmalı (AWS): IMDSv1, basit bir GET isteğiyle kimlik bilgilerini döndürebilirken, IMDSv2 özel bir oturum token'ı (PUT isteğiyle alınan) gerektirir, bu da SSRF üzerinden basit bir GET isteğiyle metadata çalınmasını büyük ölçüde engeller.
  • Metadata servisine erişim, host/node seviyesinde de kısıtlanmalı: Hem IPv4 hem IPv6 metadata uç noktaları (169.254.169.254, fd00:ec2::254 gibi) engellenmelidir.
  • En az yetki prensibi: Dış kaynaklara istek atan servis, mümkün olduğunca az yetkiye sahip bir kimlikle (IAM role) çalıştırılmalıdır; böylece SSRF başarılı olsa bile ele geçirilecek kimlik bilgisinin değeri düşük kalır.

6. İzleme ve Anomali Tespiti (Katman 3 — Kaçanı Fark Etmek)

Doğrudan zafiyeti kapatmasa da, sunucudan private/internal IP aralıklarına ya da metadata adreslerine giden anormal istekleri loglayıp uyarı üretmek, hem saldırı denemelerinin erken tespitini sağlar hem de savunmadaki bir boşluğun fark edilmesine yardımcı olur.

Sonuç

SSRF, ilk bakışta "sadece bir URL girme alanı" gibi masum görünen bir özelliğin, sunucunun tüm iç ağına ve bulut kimlik bilgilerine açılan bir kapıya dönüşebildiği bir zafiyettir. Zafiyetin kökeni her zaman aynıdır: sunucunun, kullanıcının belirlediği bir adrese, o adresin nereye gittiğini yeterince doğrulamadan istek göndermesi. Savunma tarafında da çözüm nettir: kullanıcı girdisine asla doğrudan güvenmemek, sadece önceden tanımlı adreslere (allowlist) istek gönderilmesine izin vermek ve bunu hem uygulama hem ağ seviyesinde katmanlı şekilde uygulamak, üstüne bir de olası bir atlatma girişimini yakalayacak bir izleme mekanizması eklemek.

Kaynak