SSRF Nedir? Sunucuyu Kandırmak

Bir uygulama "logonun adresini yapıştır, biz çekelim" diyorsa, dikkat edilmesi gereken bir kapı açmış demektir. Sunucu o adrese senin yerine gider. Adres bir CDN'deki görsel olabilir. Ama sunucunun iç ağındaki bir yönetim paneli ya da bulutun kimlik bilgisi dağıtan servisi de olabilir. Sunucu farkı sormazsa saldırgan onun gözüyle iç ağa bakar.

Bu yazı SSRF'i kavram, gerçek vaka ve savunma üzerinden anlatıyor. Çalışan saldırı dizgisi yok. Zafiyetli deseni ve düzeltilmiş kodu göreceksin.

SSRF nedir?

SSRF, sunucunun kullanıcıdan aldığı bir adrese istek atarken o adresin nereye çıktığını denetlememesinden doğan açıktır. Türkçede sunucu taraflı istek sahteciliği denir. MITRE kataloğunda CWE-918 numarasını taşır.

Tehlike, isteğin kaynağından gelir. İstek internetten değil uygulamanın kendi sunucusundan çıkar. Güvenlik duvarı bu isteği güvenilir bir iç makineden gelmiş sayar. PortSwigger Web Security Academy iki ana hedefi ayırır:

• Sunucunun kendisi: Uygulama kendine, döngü adresine istek atar. Yalnız yerelden açılan yönetim arayüzleri böyle görünür hâle gelir.
• Arka uç sistemler: Özel IP aralığındaki veritabanı panelleri, iç API'ler ve izleme araçları çoğu zaman kimlik doğrulamasızdır.

Bir de kör SSRF var. Sunucu isteği atar ama yanıtı kullanıcıya göstermez. Saldırgan sonucu göremese de iç servislerde yan etki yaratabilir. Tespiti daha zordur.

SSRF hangi özelliklerde ortaya çıkar?

SSRF, sunucunun dışarıdan adres alıp onu kendisi çektiği her özellikte ortaya çıkabilir. Sık görülen yerler şunlar:

• Bağlantı önizlemesi: sohbet ve sosyal ağlardaki kart görünümü.
• Adresten görsel ya da logo çekme.
• Webhook: "olay olunca şu adrese haber ver" ayarı.
• HTML'den PDF üreten servisler.
• Adresten dosya içe aktarma.
• İçinde dış adres taşıyan XML gibi veri biçimleri.
• Bazı analiz araçlarının işlediği Referer başlığı.

PortSwigger, adresin tamamı yerine bir parçasının alındığı durumlara da dikkat çeker. Uygulama yalnız bir yol ya da dosya adı alıp tam adresi kendisi kurar. Bu durumda da hedef kayabilir.

Bulut metadata servisi neden en büyük hedef?

Bulut sanal makineleri, kendileri hakkındaki bilgiyi bağlantı yerel bir adresten öğrenir ve bu adres yalnız makinenin içinden erişilebilir. AWS, Azure ve Google Cloud'da bu adres 169.254.169.254'tür. Servis makinenin kimliğini, ağ ayarını ve en önemlisi ona bağlı rolün geçici kimlik bilgisini verir.

SSRF olan bir uygulama bu adrese istek atabilirse, saldırgan rolün anahtarını ele geçirebilir. Rol ne kadar geniş yetkiliyse zarar o kadar büyür. Sağlayıcılar bu yüzden üstveri servisini ek koşullara bağladı. Google Cloud'un belgelerine göre istekte Metadata-Flavor: Google başlığı yoksa sunucu isteği reddeder. Microsoft'un belgelerine göre Azure, Metadata: true başlığını zorunlu tutar ve X-Forwarded-For taşıyan isteği kabul etmez. AWS'nin cevabı ise IMDSv2 oldu.

Capital One 2019'da ne oldu?

Capital One olayı, SSRF ile bulut üstveri servisinin birleştiğinde ne kadar büyük bir sızıntı doğurabileceğini gösteren en bilinen vakadır. Şirketin resmî açıklamasına göre yetkisiz erişim 22 ve 23 Mart 2019'da yaşandı. Açığı bir dış araştırmacı 17 Temmuz 2019'da şirketin sorumlu ifşa programına bildirdi. Şirket olayı 19 Temmuz'da tespit etti.

Capital One'ın açıkladığı rakamlar şöyle:

• ABD'de yaklaşık 100 milyon, Kanada'da yaklaşık 6 milyon kişi etkilendi.
• Yaklaşık 140 bin ABD sosyal güvenlik numarası açığa çıktı.
• Yaklaşık 80 bin bağlantılı banka hesap numarası etkilendi.
• Kanada'da yaklaşık 1 milyon sosyal sigorta numarası sızdı.

Şirket, saldırganın bir yapılandırma açığını kullandığını söyledi. KrebsOnSecurity'nin Ağustos 2019'da yayımladığı analiz zinciri ayrıntılandırdı. Yanlış yapılandırılmış bir web uygulama güvenlik duvarı, SSRF ile isteği üstveri servisine iletti. Servis, duvara bağlı rolün geçici kimlik bilgisini verdi. Rol gereğinden geniş yetkiliydi: depolama kovalarını listeleyip içlerini okuyabiliyordu.

Olayın düzenleyici bir bedeli de oldu. ABD'nin banka denetçisi OCC, 6 Ağustos 2020'de Capital One'a 80 milyon dolar para cezası verdi. Gerekçe, buluta geçmeden önce etkili risk değerlendirmesi yapılmamasıydı. Ders net: tek bir açık değil, üç zayıflığın üst üste binmesi bu sonucu doğurdu. SSRF, korumasız üstveri servisi ve fazla yetkili rol.

IMDSv2 SSRF'e karşı neyi değiştirdi?

AWS, 19 Kasım 2019'da IMDSv2'yi duyurdu ve üstveri servisine oturum jetonu zorunluluğu getirdi. Eski sürümde basit bir GET isteği yetiyordu. Yeni sürümde akış şöyle işler:

1. Yazılım önce bir PUT isteğiyle oturum başlatır ve gizli bir jeton alır.
2. Jeton en çok altı saat geçerlidir.
3. Sonraki her istek bu jetonu bir başlıkta taşır.
4. Duyuruya göre jetonu taşıyan paketin varsayılan atlama sınırı 1'dir. Jeton makineden dışarı yönlenemez.
5. X-Forwarded-For başlığı taşıyan isteğe jeton verilmez. Ters vekil üzerinden gelen istek böylece elenir.

Çoğu SSRF yalnız GET isteği attırabilir ve başlık ekleyemez. Bu yüzden IMDSv2 yaygın SSRF zincirini kırar. AWS bugün hesap düzeyinde IMDSv2'yi varsayılan yapma ve zorunlu tutma ayarı sunuyor. imds-support değeri v2.0 olan imajlardan açılan makineler de yalnız IMDSv2 ile çalışır. Kendi hesabında bu ayarı her bölge için ayrı açman gerekir. Konteyner çalıştıran makinelerde AWS atlama sınırını 2 yapmayı önerir.

OWASP Top 10'da SSRF nerede duruyor?

SSRF, OWASP Top 10 2021'de A10 olarak ayrı bir madde idi ve OWASP Top 10:2025'te A01 Bozuk Erişim Denetimi kategorisine katıldı. 2021'de madde, OWASP'ın topluluk anketinde birinci çıktığı için listeye girmişti. Veride görülme oranı yüzde 2,72'ydi ve tek bir zayıflığa, CWE-918'e eşleniyordu.

2025 sürümünde SSRF, CSRF ile birlikte A01'in öne çıkan zayıflıkları arasında anılıyor. MITRE'nin 15 Aralık 2025'te yayımladığı CWE Top 25 listesinde CWE-918 yirmi ikinci sırada.

SSRF yalnız bulutta görülmez. Microsoft, 2 Mart 2021'de Exchange Server'daki CVE-2021-26855 açığını SSRF olarak tanımladı. HAFNIUM grubu bu açıkla sunucu adına istek atıp kimlik doğrulamayı aştı, ardından başka açıklarla sunuculara kalıcı erişim kurdu. CISA'nın istismar edilen açıklar kataloğu bu açığı fidye yazılımı kampanyalarında kullanılmış olarak işaretliyor. Olay, ProxyLogon adıyla bilinir.

SSRF'e karşı nasıl savunma kurulur?

SSRF savunması, uygulama katmanında izin listesi ile ağ katmanında çıkış kısıtının birlikte kurulmasıdır; ikisi de tek başına yetmez. OWASP'ın SSRF önleme rehberi kara listelerin kolay atlatıldığını açıkça yazar. Adresin onaltılık, sekizlik ya da ondalık yazımları ve IPv6 biçimleri bunun nedenidir.

Önce zafiyetli desen:

# ZAFİYETLİ: kullanıcının verdiği adres olduğu gibi çekiliyor
def logo_onizle(url):
    yanit = requests.get(url, timeout=5)   # iç ağa ve üstveri servisine de gider
    return yanit.content                    # ham yanıt kullanıcıya dönüyor

Düzeltilmiş hâli hedefi izin listesine bağlar, adı bir kez çözer ve çözülen IP'yi denetler:

import ipaddress, socket
from urllib.parse import urlsplit
IZINLI_HOSTLAR = {"cdn.altaykargo.example", "logo.altaykargo.example"}
def hedefi_dogrula(url):
    p = urlsplit(url)
    if p.scheme != "https" or p.hostname not in IZINLI_HOSTLAR or p.port not in (None, 443):
        raise ValueError("izinli olmayan hedef")
    adresler = {ai[4][0] for ai in socket.getaddrinfo(p.hostname, 443)}
    for a in adresler:
        if not ipaddress.ip_address(a).is_global:   # özel, döngü ve bağlantı yerel blokları reddet
            raise ValueError("iç adrese çözülüyor")
    return p.hostname, sorted(adresler)[0]   # çözülen IP sabitlenir, ikinci çözümleme yok
# İsteği bu sabit IP'ye at, Host başlığına adı yaz.
# Yönlendirme takibini kapat, zaman aşımı ve boyut sınırı koy.
# Ham yanıtı değil, yalnız doğrulanmış görseli döndür.

Katmanların her biri farklı bir kapıyı kapatır:

OWASP iki durumu ayırır. Uygulama yalnız bilinen birkaç servise gidiyorsa sıkı izin listesi kullan. Webhook gibi hedefin önceden bilinmediği durumda ise kullanıcı adresini doğrudan çekme. Adı genel bir çözümleyiciyle çöz, yalnız genel yönlendirilebilir IP'lere izin ver. URL çeken işi ayrı bir ağ bölütündeki, iç ağa çıkışı kapalı bir servise taşı. 169.254.169.254'e giden her isteği kayıt altına al ve alarma bağla.

DNS rebinding izin listesini nasıl atlatır?

DNS rebinding, uygulamanın adı denetlerken bir IP'ye, isteği atarken başka bir IP'ye çözmesinden yararlanan bir zamanlama hilesidir. Saldırgan kendi alan adını önce zararsız bir genel IP'ye çözdürür. Denetim geçer. Çok kısa yaşam süreli kayıt sayesinde ikinci çözümlemede aynı ad iç bir adrese döner. Uygulama bu kez iç adrese bağlanır.

Buna kontrol ile kullanım arasındaki yarış, kısaca TOCTOU denir. Çözümü yukarıdaki koddadır. Adı bir kez çöz, çözülen IP'yi denetle ve bağlantıyı yalnız o IP'ye kur. OWASP rehberi de bağlantının yalnız doğrulanmış adreslere açılmasını ister.

SSRF'i uygulamalı nasıl öğrenirsin?

Kavramı kayıt ve kod üzerinde görmek en kalıcı yoldur. Web Uygulama Güvenliği yolunun sunucu tarafı istek modülünde Logo Diye Çekilen Kimlik labı var. Bir fatura önizleme servisi logo çekerken üstveri adresine istek atmış. Giden istek kaydından, erişim kaydından ve kaynak koddan kara listenin nasıl aşıldığını ve IMDSv2'nin yolu neden kapattığını gösterirsin.

Bulut tarafını derinleştirmek istersen Bulut ve Konteyner Güvenliği yolundaki üstveri servisi, SSRF ve IMDSv2 dersine geç. Rol yetkisinin neden kritik olduğunu bulut güvenliği yazısında anlattık. Tarayıcı taraflı kardeş açık için CSRF nedir yazısını oku.

Türkiye açısından iki not ekleyelim. SSRF ile kişisel veri sızarsa olay KVKK kapsamında ihlal bildirimi gerektirebilir. Testi ise yalnız kendi sisteminde, lab ortamında ya da bug bounty kapsamında yap. İzinsiz deneme TCK 243-245 kapsamında suçtur.

Kaynaklar

• OWASP Cheat Sheet Series: Server Side Request Forgery Prevention
• OWASP Top 10:2021, A10 Server-Side Request Forgery
• OWASP Top 10:2025, A01 Broken Access Control
• PortSwigger Web Security Academy: SSRF
• AWS Security Blog: IMDSv2 duyurusu (19 Kasım 2019)
• Capital One: 2019 Cyber Incident
• OCC: Capital One'a 80 milyon dolar ceza (2020)
• Microsoft: HAFNIUM targeting Exchange Servers (2021)