Sunucu Tarafı İstek Sahteciliği (SSRF), bir saldırganın web uygulamasını kullanarak sunucunun kendi adına istek göndermesini sağladığı bir güvenlik zafiyetidir. Eğer sunucu bir URL’yi kullanıcı girdisinden alıp doğrudan istek yapıyorsa, saldırgan o URL’yi iç ağa veya özel servis adreslerine yönlendirebilir; sunucu bu adrese bağlanır ve dönen cevabı saldırgana döndürebilir veya saldırgan başka yollarla elde edebilir. Yani kısaca bir web sitesini ziyaret ettiğimizde o sayfadaki Kullanıcıdan alınan URL’nin doğrulanmadan sunucu tarafından isteğe dönüştürülmesi durumunda SSRF zafiyeti oluşabilir.

En sık erişilen ve tehlikeli olan kaynaklar şunlardır:

• Cloud Metadata Servisleri: AWS, Google Cloud veya Azure gibi sistemlerde sunucunun kendi kimlik bilgilerini tuttuğu özel bir adres vardır (169.254.169.254 adresi). Saldırgan buraya erişirse, sunucunun sahip olduğu tüm yetkileri (IAM rolleri, şifreler, tokenlar) ele geçirebilir.
• Yerel Servisler (Loopback): Uygulamanın çalıştığı makinede sadece içeriden erişilebilen yönetim panelleri, debug arayüzleri veya admin sayfaları bulunur. http://127.0.0.1 veya http://localhost adresleri üzerinden erişilen bu sayfalar, dışarıdan şifre istese bile “içeriden” gelindiği için bazen şifresiz giriş imkanı tanır.
• İç Ağdaki Diğer Cihazlar: Şirketlerin iç ağında bulunan ve internete kapalı olan veritabanları, dosya sunucuları veya API’ler. Saldırgan, dışarıdan ulaşamadığı 192.168.x.x veya 10.x.x.x gibi özel IP bloklarındaki cihazlara sunucu üzerinden ulaşabilir.
• Veritabanı ve Kritik Portlar: Redis, Elasticsearch, MongoDB gibi sistemler bazen parola gerektirmeden çalışır çünkü sadece “güvenli iç ağda” olduklarını varsayarlar. Saldırgan bu servislere SSRF ile erişerek veri çalabilir veya değiştirebilir.
• Geliştirici (Debug) Sayfaları: Yazılımcıların hata ayıklamak için açık bıraktığı /debug, /config veya /admin gibi sayfalar, sistemin nasıl çalıştığına dair kritik bilgiler (veritabanı şifreleri, sistem yolları, ortam değişkenleri) sızdırabilir.

Bazı durumlarda sunucu, ulaştığı iç servisten aldığı veriyi size doğrudan göstermez (Blind SSRF). Ancak saldırgan, sunucunun verdiği tepkilerden içeride ne olduğunu anlayabilir. Örneğin; sunucu “Sayfa bulunamadı” hatası veriyorsa o port kapalıdır, ama “Erişim engellendi” veya uzun süren bir yükleme ekranı geliyorsa orada bir servis çalıştığı anlaşılır. Yani sunucunun hata mesajları, cevap verme hızı veya yönlendirme şekli, saldırgana önemli bilgiler verebilir.

DNS Tabanlı Sızıntı (DNS Exfiltration): En sinsi yöntemlerden biridir. Saldırgan, sunucuyu bilinmeyen.saldirgan.com gibi var olmayan bir subdomain adrese gitmeye zorlar. Bu noktada şu zincirleme reaksiyon gerçekleşir:

1. Hedef sunucu, kendisine iletilen alan adının (örneğin saldirgan.com) IP karşılığını bulmak için önce kendi yerel DNS önbelleğini kontrol eder.
2. Yerel servis adresi bulamazsa, sorguyu internetteki ana sunuculara iletir.
3. En sonunda bu soru, saldirgan.com’un yetkili sahibi olan saldırganın kendi sunucusuna kadar ulaşır.

Saldırganın buradaki temel amacı her zaman bir IP adresi döndürmek değil, sunucunun yaptığı DNS sorgularını kendi kontrolündeki sunucu üzerinden izleyerek iç ağdaki yapılandırmalar veya servislerin varlığı hakkında veri elde etmektir; örneğin, sorgulanan alt alan adları üzerinden iç ağdaki sunucu isimleri, yazılım versiyonları bu yolla analiz edilebilir.

İç Ağdaki Güven İlişkisi ve Riskler

SSRF zafiyetinin bu kadar kritik olmasının temel nedeni, birçok sistem mimarisinin “içeriden gelen istek her zaman güvenilirdir” varsayımı üzerine kurulmuş olmasıdır. Bu durum şu teknik açıkları doğurur:

1. Erişim Kontrolü İhlali: Güvenlik kısıtlamaları genellikle uygulamanın en dış katmanında (WAF veya Firewall) yapılır. Sunucunun kendi içinden (localhost) başlattığı bir istek bu dış koruma katmanlarını atladığı için, sistem bu isteği “zaten doğrulanmış” kabul edebilir.
2. Yetkisiz Yönetici Erişimi: Bazı uygulamalar, bakım veya acil müdahale durumları için sunucunun bizzat kendisinden gelen bağlantılara parola sormadan tam yetki verecek şekilde yapılandırılmıştır. SSRF açığı sayesinde saldırgan, sunucuya bu isteği kendi adına yaptırarak doğrudan yönetici haklarına sahip olabilir.
3. Dışarıya Kapalı Portlar: Yönetici panelleri veya veri tabanı yönetim arayüzleri genellikle dış internete kapalı olan farklı portlar (örneğin 8080, 9000) üzerinden çalışır. Bir saldırgan dışarıdan bu portlara ulaşamazken, sunucunun içindeki SSRF açığını kullanarak bu dahili servisleri sorgulayabilir ve yönetebilir.

Sunucu hedefli bir saldırıda temel amaç, uygulamayı dışarıdaki bir siteye değil, kendi üzerindeki (localhost) yerel adreslere istek göndermeye zorlamaktır.

Örnek Senaryo: Bir e-ticaret sitesi, ürünlerin stok durumunu kontrol etmek için arka planda bir API kullanıyor olsun. Normal şartlarda uygulama, stok bilgisini şu şekilde bir URL üzerinden çeker:
http://stock.example.net:8080/urun/check?id=123

Saldırgan, bu URL parametresini değiştirerek sunucuyu kendi yerel yönetim paneline yönlendirir: https://example-shop.com/check-stock?stockApi=http://127.0.0.1/admin veya
https://example-shop.com/check-stock?stockApi=http://localhost/admin

Sunucu bu isteği kendi içinden başlattığı için, dışarıdan erişime kapalı olan yönetim arayüzü bu bağlantıyı “güvenilir” kabul eder. IP tabanlı kısıtlamalar veya dış katmandaki kimlik doğrulama kontrolleri devre dışı kalır. Böylece saldırgan, normalde asla göremeyeceği yönetimsel içerikleri veya hassas verileri doğrudan sunucudan çekmiş olur.

Başka bir örnek senaryo:
Bir e-ticaret uygulamasında, bir ürünün stok durumunu sorgulamak için arka uç API’sinin URL’sini kullanan bir yapı düşünelim. Normal bir kullanımda sistem şu adrese istek atar:
stockApi=http://stock.myShop.net:8080/product/stock/check?productId=6
Ancak saldırgan, bu parametreyi değiştirerek uygulamayı iç ağdaki (Intranet) korumasız bir cihaza yönlendirebilir:
stockApi=http://192.168.0.68/admin
Uygulama bu isteği sunucu üzerinden gerçekleştirdiğinde, dışarıdan erişimi kapalı olan 192.168.0.68 adresindeki yönetim arayüzü veya hassas veri noktaları saldırgana açılabilir. İç ağdaki bu servisler, ağ topolojisi gereği dış tehditlere kapalı kabul edildiği için genellikle kimlik doğrulama mekanizmaları daha zayıf yapılandırılmıştır. SSRF, bu izolasyonu aşarak doğrudan iç servislerle etkileşime geçilmesine imkan tanır.
Çoğu uygulama bu tür saldırıları engellemek için 127.0.0.1, localhost veya /admin gibi kelimeleri yasaklayan “Kara Liste” (Blacklist) filtreleri kullanır. Fakat saldırganlar bu savunmaları bazı tekniklerle aşabilir:

1. 1. 1. Alternatif IP Formatları:Eğer 127.0.0.1 yasaklıysa, aynı adresi ondalık (2130706433), sekizlik (017700000001) veya kısaltılmış (127.1) versiyonlarıyla yazarak filtreyi yanıltabilirler.
      2. Encoding: Güvenlik filtreleri genellikle “yasaklı kelimeler” listesine bakar. Örneğin filtre admin kelimesini engelliyorsa, saldırgan bu kelimeyi URL encode yöntemiyle (%61%64%6d%69%6e) yazabilir. Filtre bu anlamsız görünen karakter dizisini geçerli sayarken, sunucu bu kodları çözdüğünde doğrudan yasaklı olan admin sayfasına gider. Ayrıca bazı filtreler sadece küçük harfe duyarlıysa, AdMiN gibi büyük-küçük harf varyasyonları kullanılarak da bu engeller aşılabilir.

Bu teknikler nedeniyle sadece yasaklı kelimelere güvenmek yeterli değildir; sistemin güvenliği için sadece izin verilen adreslerin tanımlandığı Beyaz Liste (Whitelist) ve sıkı veri doğrulama yöntemleri şarttır.

Kanonikleştirme (Canonicalization) Nedir?

Kanonikleştirme (URL Normalizasyonu), farklı yazımlara sahip olan ancak aynı adresi işaret eden URL’leri tek ve standart bir hale getirme işlemidir. Güvenlik filtreleri genellikle doğrudan metin eşleşmesine baktığı için, saldırganlar URL’leri encode ederek veya farklı formatlarda yazarak filtreleri aşmaya çalışır. Kanonikleştirme; sunucunun gelen isteği henüz kontrol aşamasındayken tüm karmaşık yazımlardan arındırıp, onu en yalın ve standart formuna dönüştürerek doğrulama yapmasını sağlar.

Normalizasyon Süreci Şunları Kapsar:

1. 1. • URL Decode: %31%32%37%2e1 gibi encode edilmiş veriler çözülerek 127.1 haline getirilir.
      • IP Formatı Dönüştürme: Sekizlik sistemdeki 017700000001 gibi karmaşık yazımlar, standart ondalık sistemdeki 127.0.0.1 adresine dönüştürülür.
      • Standartlaştırma: EXAMPLE.COM (büyük harf) veya example.com. (sonunda nokta olan) gibi farklı yazımların aslında aynı host olduğu doğrulanır ve küçük harf/standart formata çekilir.

Eğer filtreleme işlemi bu normalizasyon adımından önce yapılırsa, saldırganlar basit yazım oyunlarıyla engelleri aşabilir. Bu nedenle güvenli bir mimaride URL önce kanonikleştirilmeli, ardından kontrol edilmelidir.

Proxy Tabanlı İstek Kontrolü (Server-Side Proxy) Nedir?

Bu yöntem, uygulamanın dış dünyaya yapacağı tüm istekleri doğrudan değil, özel olarak yapılandırılmış bir ara sunucu (proxy) üzerinden göndermesidir. Uygulama, kullanıcıdan gelen URL’ye kendisi bağlanmak yerine bu isteği proxy sunucusuna iletir. Proxy, isteği gerçekleştirmeden önce şu kritik denetimleri yapar:

• İzinli Liste (Allowlist) Kontrolü: Hedef adresin önceden belirlenmiş güvenli adresler arasında olup olmadığını kontrol eder.
• IP ve Protokol Kısıtlaması: İsteklerin sadece http/https gibi güvenli protokollerle yapılmasını sağlar ve iç ağdaki (private/loopback) adreslere giden trafiği bloklar.
• Yönlendirme (Redirect) Takibi: Saldırganların filtreleri aşmak için kullandığı zincirleme yönlendirmeleri denetler ve riskli yönlendirmelere izin vermez.
• Kaynak Yönetimi: Cevap boyutu, zaman aşımı (timeout) ve istek hızı (rate-limit) gibi sınırlandırmalarla sunucunun gereksiz yük altında kalmasını veya veri sızıntısını engeller.

Open Redirect Kullanarak SSRF Filtrelerini Atlatma

Open Redirect, bir web sitesinin URL içindeki belirli parametreler (örneğin url=, next=, redirect=) aracılığıyla kullanıcıyı başka bir adrese yönlendirmesidir. Eğer uygulama bu parametreye yazılan adresi doğrulamadan kabul ediyorsa, site üzerinden istenilen her yere yönlendirme yapılabilir.

Bazı sistemler, SSRF’i engellemek için sadece kendi alan adlarına (örneğin guvenli-site.com) giden isteklere izin veren bir filtreleme mekanizması kullanır. Saldırgan ise bu filtreyi aşmak için sitenin kendi içindeki bu yönlendirme özelliğini bir geçiş noktası olarak kullanır.

Saldırı Senaryosu:

Saldırgan, sunucuya şu parametreyi gönderir:

stockApi=https://guvenli-site.com/redirect?url=http://192.168.0.68/admin

1. 1. 1. Filtre Kontrolü: Güvenlik filtresi, iletilen URL’nin başlangıç adresini (prefix) kontrol eder. İstek https://guvenli-site.com ile başladığı için izinli listedeki (allowlist) bir adres olarak değerlendirilir ve erişim onaylanır.
      2. Sunucu İsteği: Sunucu, doğrulanmış URL’ye yönelik isteği başlatır ve kendi üzerindeki /redirect uç noktasına (endpoint) ulaşır.
      3. Yönlendirme (Bypass): Uygulama katmanında çalışan /redirect sayfası, önceden tanımlı parametreyi (url=) işleyerek sunucuya yeni bir hedef tanımı yapar.
      4. SSRF Gerçekleşmesi: Sunucu, uygulama içindeki yönlendirme talimatını takip ederek dış erişime kapalı olan http://192.168.0.68/admin adresine dahili bir istek gönderir.

Bu senaryoda güvenlik filtresi yalnızca ilk hedefi doğruladığı için atlatılmış olur. SSRF zafiyeti, sunucunun kendi üzerindeki bir yönlendirme parametresini kullanarak dahili ağdaki bir kaynağa erişmesiyle tamamlanır.

Blind (Kör) SSRF Nedir?

Blind SSRF, uygulamaya bir URL verildiğinde sunucunun bu adrese arka uç isteği yaptığı, ancak dönen cevabın kullanıcıya iletilmediği durumdur. Saldırgan yaptığı isteğin sonucunu doğrudan göremediği için bu türü sömürmek daha zordur; ancak sonuçları yine de iç servislerin tetiklenmesi, kimlik doğrulama adımlarının atlatılması ve uygun koşullarda sunucu tarafında kod çalıştırılmasına (RCE) kadar gidebilir.

Doğrudan veri okumak mümkün olmasa da, sunucu iç IP’lere veya arka uç servislerine istek atmaya zorlanarak hangi adreslerin canlı olduğu anlaşılabilir. Eğer sunucu aktif bir iç servise bağlanmaya çalışırsa istek hızlı tamamlanır, ancak kapalı bir IP’ye gitmeye çalışırsa bağlantı zaman aşımına (Timeout) uğrar. Saldırgan, bu yanıt sürelerini (Time-based) karşılaştırarak iç ağın haritasını çıkarabilir. Bu açığın varlığını kesin olarak kanıtlamak içinse genellikle out-of-band (OAST) yöntemi kullanılır; yani sunucuya saldırganın kontrolündeki benzersiz bir domain adresi verilir ve sunucunun bu dış adrese bağlantı yapıp yapmadığı (callback) saldırganın kendi loglarından izlenir.

Kör SSRF zafiyetini engellemek için sadece çıktıya güvenmek yerine; gelen tüm URL’ler kanonikleştirilip IP adresine çözülerek doğrulanmalı, 127.0.0.1 veya 192.168.x.x gibi özel ağ aralıklarına erişim kesinlikle engellenmelidir. Ayrıca, tüm dış isteklerin kısıtlayıcı kuralları olan merkezi bir proxy üzerinden geçmesi zorunlu kılınmalı, kontrolsüz yönlendirmeler sınırlanmalı ve kritik yönetim uç noktalarında sadece ağ izolasyonuna güvenilmeyip mutlaka güçlü kimlik doğrulama mekanizmaları kullanılmalıdır.

SSRF İçin Gizli Saldırı Yüzeylerini Bulma

Sunucu taraflı isteklerde SSRF zafiyeti her zaman bariz bir URL parametresi üzerinden gelmez; bazen sistemin farklı giriş noktaları bulunur. Örneğin uygulama kullanıcıdan her zaman tam bir URL beklemek yerine sadece bir host adı veya yol parçası alabilir. Sunucu bu parçayı kendi içinde tamamlayıp isteği gerçekleştirdiğinde, kontrol ettiğiniz değer URL’nin tamamı olmasa bile tehlikeli bir SSRF zinciri oluşabilir. Benzer bir risk, XML gibi veri formatlarının işlenmesi sırasında da ortaya çıkar. Bazı veri işleyiciler (parser), XML içindeki dış kaynakları otomatik olarak takip edebildiği için “XXE” (XML External Entity) zafiyeti üzerinden sunucuyu dolaylı yoldan iç ağdaki bir adrese gitmeye zorlayabilir.

Ayrıca kullanıcıların doğrudan müdahale etmediği “Referer” gibi HTTP başlıkları da ciddi bir saldırı yüzeyidir. Tarayıcı tarafından otomatik eklenen bu başlık, sunucuya “hangi adresten gelindiğini” bildirir. Analiz (analytics) veya bağlantı ön izleme (preview) yapan servisler, bu başlık içindeki üçüncü taraf bağlantılarını doğrulamak veya içerik çekmek için o adrese kendi üzerinden bir ziyaret gerçekleştirebilir. Yazılımcılar genellikle URL parametrelerini denetlese de, manuel olarak değiştirilebilen bu tarz başlıkların içindeki adreslerin sunucu tarafından otomatik olarak ziyaret edilebileceğini gözden kaçırdıkları için saldırganlara açık bir kapı bırakmış olurlar.

Örnek Senaryo:

1. Uygulama, gelen isteği inceler ve Referer: https://google.com değerini okur.
2. Uygulamanın içindeki bir servis, kaynağın geçerliliğini doğrulamak veya sitenin üst verilerini (metadata) çekmek amacıyla https://google.com adresine sunucu üzerinden bir HTTP isteği gönderir.
3. Saldırgan, bu başlığı manuel olarak manipüle ederek hedeflediği iç IP adresini yazar: Referer: http://192.168.0.68/admin
4. Uygulama bu başlığı işlediği anda sunucu, dış erişime kapalı olan kendi iç ağındaki 192.168.0.68 adresine bağlantı kurmaya çalışır ve SSRF gerçekleşir.

SSRF zafiyetinden korunmanın temel yolu, kullanıcıdan gelen hiçbir girdiye (parametre, header veya dosya içeriği) doğrudan güvenmemektir. Güvenli bir mimari için tüm URL’ler kontrol edilmeden önce kanonikleştirilmeli, sadece izin verilen adresleri içeren beyaz listeler (whitelist) kullanılmalı ve iç ağdaki hassas servislere mutlaka güçlü kimlik doğrulama katmanları eklenmelidir.