Sunucu Taraflı İstek Sahteciliği (SSRF): Web ve Bulut Altyapılarında Görünmez Tehlike
Modern web ekosistemi, on yıl öncesine kıyasla tanınmayacak kadar karmaşık bir hal aldı. Artık uygulamalarımız sadece tek bir sunucuda çalışan monolitik yapılar değil; mikro hizmetler (microservices), sunucusuz (serverless) fonksiyonlar, üçüncü taraf API etkileşimleri ve bulut yerel servislerin iç içe geçtiği devasa bir ağ yapısıdır. Bu evrim, “hız ve ölçeklenebilirlik” getirse de beraberinde siber saldırganlar için kritik bir istismar alanı oluşturdu: SSRF (Server-Side Request Forgery).
SSRF, temel olarak bir saldırganın, savunmasız bir sunucu üzerinden ağ istekleri başlatmasına ve bu sunucuyu bir vekil (proxy) gibi kullanarak normalde dış dünyaya kapalı olan iç ağlara (LAN), bulut meta veri servislerine (IMDS) veya sunucunun yerel dosya sistemine ulaşmasına olanak tanır. 2024 ve 2025 yılları arasındaki istatistikler, SSRF saldırılarının sıklığının %452 oranında arttığını gösteriyor. Bu artışın temelinde, saldırganların otomatize edilmiş araçlar ve yapay zeka destekli tarama tekniklerini kullanarak “güven ilişkilerini” hedef alması yatıyor.
Neden Bu Rehber?
Bu yazı, basit bir blog metninden öte, kurumsal güvenlik mimarlarının ve siber güvenlik öğrencilerinin başucu kaynağı olması için tasarlandı. İçeride sadece “ne olduğu” değil, “nasıl engelleneceği” de teknik parametrelerle anlatılmaktadır.
- DNS Rebinding’in matematiksel mantığı
- Gopher üzerinden Redis suistimali
- AWS, Azure ve GCP meta veri korumaları
- Parser Differentials (Libcurl vs. Urllib)
1. SSRF Zafiyetinin Teknik Doğası ve Taksonomik Sınıflandırması
SSRF, bir web uygulamasının kullanıcıdan aldığı bir URL’yi veya girdi verisini, sunucu tarafında yeterli doğrulama yapmadan bir ağ isteği oluşturmak için kullanmasıyla tetiklenir. Bu mekanizma, güven ilişkilerinin bir istismarıdır; çünkü hedef sistem, isteğin saldırgandan değil, güvenilir bir uygulama sunucusundan geldiğini varsayar. Bu “güvenli kimlik”, saldırganın dışarıdan asla ulaşamayacağı veritabanı portlarına (3306, 5432) veya yönetim panellerine (8080) erişmesini sağlar.
1.1. Geri Bildirim Niteliğine Göre Türler
Bir siber güvenlik analizinde, SSRF’i üç ana kategoriye ayırmak sömürü stratejisini belirleyen en kritik adımdır:
- Temel (Basic) SSRF: Uygulama, hedef kaynağın yanıtını (HTML, JSON, resim vb.) doğrudan kullanıcıya döndürür. Bu, saldırganın iç ağı “okumasını” sağlar.
- Yarı-Kör (Semi-Blind) SSRF: Yanıt içeriği görünmez ancak meta veriler (yanıt süresi, HTTP durum kodları – 200 vs 404, yanıt boyutu) mevcuttur. İç ağ haritalama için idealdir.
- Kör (Blind) SSRF: Uygulama hiçbir doğrudan yanıt döndürmez. Burada saldırgan, “Bant Dışı” (Out-of-Band – OOB) teknikler kullanarak sunucunun isteği yapıp yapmadığını kendi kontrolündeki bir sunucu (Burp Collaborator, Interact.sh) üzerinden doğrular.
1.2. Programlama Dili Kütüphaneleri ve Riskler
SSRF sadece bir mantık hatası değil, aynı zamanda kullanılan kütüphanelerin URL’leri nasıl yorumladığıyla da ilgilidir. Örneğin PHP’deki curl_exec(), Python’daki requests.get() veya Node.js’teki axios kütüphaneleri farklı varsayılan ayarlara sahiptir. Bir kütüphanenin yönlendirmeleri (redirects) otomatik takip etmesi, saldırganın filtreleri aşmak için bir “Open Redirect” zafiyetini SSRF ile zincirlemesine olanak tanır.
2. Gelişmiş Bypass Teknikleri: Filtreleri Atlatma Sanatı
Uygulama geliştiricileri genellikle 127.0.0.1 veya localhost gibi bilinen adresleri kara listeye (blacklist) alarak çözüm üretmeye çalışırlar. Ancak siber saldırganlar, ağ protokollerinin esnekliğini kullanarak bu filtreleri saniyeler içinde aşabilirler.
2.1. Alternatif IP Temsilleri ve Sayısal Manipülasyon
Bilgisayar sistemleri IP adreslerini sadece nokta ile ayrılmış dörtlü diziler olarak değil, birçok farklı formatta yorumlayabilir. İşte filtreleri aşmak için kullanılan bazı temsiller:
| Format | Temsil (127.0.0.1) | Açıklama |
|---|---|---|
| Decimal (Ondalık) | 2130706433 | Noktaların kaldırılıp sayının tek bir tamsayıya dönüştürülmüş hali. |
| Hexadecimal (Onaltılık) | 0x7f000001 | IP’nin onaltılık tabanda yazımı; çoğu parser bunu IP olarak kabul eder. |
| Octal (Sekizlik) | 017700000001 | Başına 0 eklenerek oluşturulan sekizlik format. |
| Kısaltılmış Versiyonlar | 127.1 | Bazı işletim sistemleri ve kütüphaneler bunu otomatik olarak 127.0.0.1’e tamamlar. |
2.2. DNS Yeniden Bağlama (DNS Rebinding): Zamanla Yarış
DNS Rebinding, bir güvenlik kontrolü (Check) ile gerçek kullanım anı (Use) arasındaki zaman boşluğunu hedefleyen sofistike bir saldırıdır (TOCTOU). Saldırgan, kontrol ettiği bir alan adının TTL (Time To Live) süresini 0 saniye olarak ayarlar.
Uygulama önce alan adını sorgular, DNS “güvenli” bir IP (örneğin 1.1.1.1) döndürür ve uygulama isteği onaylar. Ancak milisaniyeler sonra gerçek istek yapıldığında DNS bu kez “yasaklı” bir iç IP (örneğin 169.254.169.254) döndürür. Bu teknik, modern tarayıcıların ve uygulama sunucularının aynı kaynak politikasını (SOP) aşmak için kullandığı en ölümcül yöntemlerden biridir.
2.3. URL Çözümleyici Farklılıkları (Parser Differentials)
Gelişmiş SSRF saldırılarında, farklı kütüphanelerin bir URL dizgisini nasıl yorumladığı arasındaki tutarsızlıklar suistimal edilir. Örneğin, bir web uygulaması URL doğrulaması için Python’un urllib kütüphanesini kullanırken, gerçek isteği yapmak için libcurl kütüphanesini kullanıyor olabilir.
http://[email protected]/ gibi bir yapı, bir çözümleyici tarafından trusted-host üzerinden giden güvenli bir istek olarak görülüp onaylanırken, bir diğeri @ işaretinden sonrasını asıl hedef (evil-host) olarak kabul ederek isteği oraya gönderebilir.
3. Bulut Altyapılarında SSRF ve IMDSv2 Savaşı
Bulut bilişim geçişiyle birlikte (AWS, Azure, GCP), SSRF zafiyetinin etkisi çarpan etkisiyle artmıştır. Bunun temel nedeni, bulut sağlayıcıların sanal makinelerin kendi yapılandırmalarına erişebilmesi için sunduğu Instance Metadata Service (IMDS) adlı dahili API’dir.
3.1. AWS IMDSv2: Neden Devrim Niteliğinde?
AWS tarafında IMDSv1, basit bir HTTP GET isteğiyle çalışır ve hiçbir kimlik doğrulama gerektirmez. Bir saldırgan SSRF üzerinden http://169.254.169.254/latest/meta-data/iam/security-credentials/[rol-adi] adresine ulaştığında, o sunucuya atanmış olan IAM rolünün geçici erişim anahtarlarını düz metin olarak ele geçirebilir.
2019’daki büyük sızıntılardan sonra AWS, IMDSv2‘yi devreye almıştır. IMDSv2, basit bir SSRF ile aşılması imkansız olan “token tabanlı” bir mekanizma getirir:
- Saldırgan önce bir PUT isteği ile sunucudan geçici bir oturum token’ı almak zorundadır.
- Gerçek meta veri isteği, bu token’ın bir HTTP başlığı (
X-aws-ec2-metadata-token) olarak eklenmesini gerektirir.
Çoğu SSRF vektörü sadece GET isteklerine izin verdiği ve özel başlık eklenmesine imkan tanımadığı için, IMDSv2 bulut güvenliğinde devasa bir koruma sağlar. Ancak hala birçok eski altyapıda IMDSv1’in açık unutulması, siber saldırganlar için büyük bir fırsattır.
HttpTokens=required parametresini aktif ederek IMDSv1’i tamamen kapatın. Bu, SSRF saldırılarını meta veri seviyesinde %99 oranında engeller.
4. Pentest Metodolojileri: SSRF’den RCE’ye (Uzaktan Kod Çalıştırma)
Bir penetrasyon testinde SSRF’in varlığını tespit etmek sadece başlangıçtır. Gerçek etki, bu zafiyetin diğer servislerle nasıl zincirlendiğiyle ölçülür. SSRF, saldırganın iç ağdaki HTTP dışı servislerle de konuşmasını sağlayabilir.
4.1. Gopher Protokolü: “İsviçre Çakısı”
Eğer sunucu tarafındaki kütüphane destekliyorsa, gopher:// protokolü siber saldırganlar için bir “İsviçre çakısı” gibidir. Bu protokol, ham TCP paketleri göndermeye izin verir. İç ağda parola koruması olmayan bir Redis sunucusu bulunduğunda, saldırgan Gopher üzerinden Redis’e komutlar göndererek:
- Sunucuya bir Web Shell yazabilir.
- SSH yetkilendirme dosyalarını manipüle edebilir.
- Crontab üzerinden Reverse Shell tetikleyebilir.
4.2. PDF Jeneratörleri ve Dosya Sızıntısı
Rapor, fatura veya kimlik kartı oluşturmak için kullanılan PDF motorları (wkhtmltopdf, Headless Chrome vb.), sunucu tarafında bir HTML şablonunu işleyerek PDF belgesine dönüştürür. Eğer bir saldırgan kullanıcı girişini bu HTML şablonuna dahil edebiliyorsa (HTML Injection), sunucuyu yerel dosya sistemindeki dosyaları okumaya (<iframe src="file:///etc/passwd">) veya iç ağdaki meta verilere erişmeye zorlayabilir.
5. Modern Altyapılarda SSRF Önleme ve Savunma-i Derinlik
SSRF zafiyetini tek bir filtreyle engellemeye çalışmak, dinamik saldırı vektörleri karşısında başarısız olmaya mahkumdur. 2026 siber güvenlik vizyonunda etkili bir savunma, uygulama katmanından ağ katmanına kadar uzanan bir “Derinlemesine Savunma” (Defense-in-Depth) stratejisini gerektirir.
5.1. Uygulama Katmanı: İzin Verilenler Listesi (Allowlisting)
Kara listeler kolayca bypass edilebilir; bu nedenle en sağlam savunma, sadece güvenilen hedeflere izin veren bir “izin verilenler listesi” (allowlist) oluşturmaktır.
- URL Normalizasyonu: Kullanıcı girişi alınırken mutlaka protokol şeması (sadece http/https) doğrulanmalı;
file://,gopher://gibi tehlikeli şemalar yasaklanmalıdır. - DNS Pinning: Uygulama, alan adını çözümlerken elde edilen IP’nin özel bir ağ aralığında (RFC 1918) olup olmadığını kontrol etmeli ve gerçek isteği doğrulanmış IP üzerinden yapmalıdır.
5.2. Ağ Katmanı ve Segmentasyon
- Egress (Çıkış) Filtreleme: Uygulama sunucularının dış dünyaya veya iç ağa yapabileceği istekler, “deny-by-default” (varsayılan olarak engelle) politikasıyla kısıtlanmalıdır.
- Mikro-Segmentasyon: Web sunucuları ile kritik dahili servisler (veritabanları, Redis vb.) farklı ağ segmentlerinde bulunmalı ve aradaki iletişim sıkı güvenlik duvarı kurallarıyla yönetilmelidir.
6. Sık Sorulan Sorular (SSS)
SSRF zafiyeti sadece web sitelerinde mi olur?
Hayır. URL’leri, resimleri veya harici API’leri işleyen herhangi bir uygulama (mobil uygulamalar, masaüstü yazılımları, arka plan işleyicileri) SSRF’e karşı savunmasız olabilir.
WAF (Web Application Firewall) SSRF’i durdurur mu?
Basit saldırıları durdurabilir ancak DNS Rebinding veya karmaşık URL çözümleyici farklarını hedef alan saldırılar genellikle WAF kurallarını atlatır. En iyi çözüm kod seviyesindeki doğrulamadır.
Localhost’u engellemek yeterli mi?
Kesinlikle hayır. Saldırganlar 127.0.0.1 yerine 0.0.0.0, [::], 127.1 veya DNS Rebinding gibi onlarca farklı bypass yöntemini kullanarak localhost engellerini aşabilirler.
SSRF ile sistem ele geçirilebilir mi?
Evet. Özellikle iç ağda savunmasız servisler (Redis, Jenkins, Docker API vb.) varsa, SSRF bu servislerle konuşarak sunucu üzerinde kod çalıştırılmasına (RCE) yol açabilir.
Dijital altyapınızın güvenliğini test etmek ve siber risklerinizi minimize etmek için profesyonel destek alın.
Nesil Teknoloji İletişime Geç
