Bölüm 21

Server-Side Request Forgery (SSRF)

16 dk okuma3.330 kelimePHP 8.1+

Ön koşul

Bölüm 1 (güven sınırı, en az yetki), Bölüm 10 (XXE→SSRF), Bölüm 18 (TOCTOU/DNS rebinding), Bölüm 4 (kanonikleştirme). İleri referanslar: Bölüm 25 (sırlar), Bölüm 27/29 (ağ/altyapı).

Bu bölümün kazanımı

SSRF'i, "saldırganın, sunucuyu kendi seçtiği bir hedefe istek yaptırması" olarak kavrayacak; sunucunun neden değerli bir proxy olduğunu (iç ağ, bulut metadata); URL doğrulamanın neden bu kadar zor olduğunu (DNS rebinding); ve en az yetkinin (Capital One dersi) neden SSRF'in etkisini belirlediğini göreceksiniz. Bu, Kısım IV'ü kapatan bölümdür.

1. Giriş

SSRF, bulut çağının en tehlikeli açık sınıfıdır. CSRF'in (Bölüm 17) kurbanın tarayıcısını kandırmasına karşılık, SSRF sunucunun kendisini kandırır: saldırgan, uygulamaya, kendi seçtiği bir hedefe HTTP (veya başka protokol) isteği yaptırır. Sunucu, saldırganın erişemeyeceği yerlere — iç ağdaki servislere, localhost'taki yönetim panellerine, bulut metadata servisine — erişebildiği için, sunucuyu bir proxy gibi kullanmak devasa güç sağlar.

SSRF'in bulutla yükselişinin nedeni, bulut altyapısının bir "sır kutusu" barındırmasıdır: instance metadata servisi (AWS'de 169.254.169.254). Bu uç nokta, o makineye atanmış IAM rolünün geçici kimlik bilgilerini döndürür. Bir sunucuyu bu uç noktaya istek yaptırabilen saldırgan, bulut kimlik bilgilerini çalar ve oradan tüm bulut hesabına yayılır. 2019'daki Capital One ihlali (Bölüm 11) tam olarak buydu: bir WAF'taki SSRF, metadata servisinden IAM kimlik bilgilerini çekti ve 106 milyon kaydın çalınmasına yol açtı — sıfır-gün veya kimlik bilgisi hırsızlığı olmadan, yalnızca bir SSRF + aşırı yetkili bir rolle.

Bu bölümün iki merkezî mesajı vardır. Birincisi: URL doğrulama, SSRF'i tek başına çözmenin çok zor olduğu bir alandır — DNS rebinding, kodlama, yönlendirme gibi atlatmalar yüzünden. İkincisi: SSRF'in etkisini en az yetki belirler — Capital One'da felaketi yaratan SSRF değil, WAF rolünün S3'e erişebilmesiydi.

2. Temel Teori

Kök neden. SSRF, uygulamanın kullanıcı-kontrollü bir hedefe ağ isteği yapmasıyla oluşur. Uygulama "bu URL'i getir" der ve URL'i (tümüyle veya kısmen) saldırgan belirler. Sunucu isteği yaptığında, kaynak sunucunun kendisidir — güven sınırının (Bölüm 1) içinden çıkar.

Neden bu kadar güçlü? Çünkü sunucu, saldırganın doğrudan erişemeyeceği yerlere erişebilir:

Hedef	Neden değerli
Bulut metadata (`169.254.169.254`)	IAM kimlik bilgileri, user-data, SSH anahtarları (crown jewel)
localhost / 127.0.0.1	Yönetim panelleri, debug uç noktaları, iç API'ler
İç ağ (`10.x`, `172.16-31.x`, `192.168.x`)	Kimlik doğrulamasız iç servisler (Redis, Elasticsearch, DB)
`file://`	Yerel dosya okuma (traversal gibi)
`gopher://` / `dict://`	Protokol kaçakçılığı (iç servislere ham komut)

İç servisler çoğu zaman "ağ zaten güvenli" varsayımıyla kimlik doğrulamasız çalışır. SSRF bu varsayımı çökertir: istek içeriden geldiği için o servisler saldırgana açılır.

SSRF nerede doğar? Sunucunun bir URL getirdiği her özellik: - Webhook'lar, URL önizleme/açma (link unfurl), URL'den görüntü/PDF çekme, "URL'den içe aktar", RSS okuyucular, PDF üreteçleri (headless tarayıcı), profil resmi URL'i, ödeme/harici API çağrıları. - Ayrıca XXE (Bölüm 10, harici varlık bir URL'i işaret eder) ve open redirect zincirleri.

Blind (kör) SSRF. Yanıt saldırgana dönmese bile SSRF değerlidir: iç port tarama (zamanlama farkıyla), yan etkili iç uç noktaları tetikleme, ve OOB (bant-dışı) doğrulama. Görünür yanıt olmaması güvenlik sağlamaz (Bölüm 10, kör XXE ile aynı mantık).

Neden savunması zor? — DNS rebinding (TOCTOU). SSRF savunmasının en sinsi yanı, "URL'i doğrula, sonra getir" kalıbının bir yarış koşulu (Bölüm 18) içermesidir: saldırganın alan adı, doğrulama anında izinli bir IP'ye, getirme anında iç bir IP'ye (169.254.169.254) çözülebilir. Bu DNS rebinding'dir — kontrol ile kullanım arasında DNS değişir. Çözüm: alan adını bir kez çöz, çözülen IP'yi doğrula, sonra o sabitlenmiş (pinned) IP'ye bağlan.

3. Mimarisel Bakış

 SSRF AKIŞI (bulut metadata):
   Saldırgan → { url: "http://169.254.169.254/latest/meta-data/iam/security-credentials/ROL" }
        ↓  ╳ güven sınırı (uygulama içeriden istek yapar)
   Uygulama → GET 169.254.169.254/...  (sunucu erişebilir, saldırgan erişemez)
        ↓
   Metadata → geçici IAM kimlik bilgileri döner
        ↓
   Saldırgan → çalınan kimlikle bulut API'sine (S3) → veri sızdırma
        ✗ EN AZ YETKİ olsaydı, kimlik işe yaramazdı (Capital One dersi)

 DNS REBINDING (doğrulamayı atlatma — TOCTOU):
   url = "http://saldirgan-alan.com/"
   T1 (doğrulama): saldirgan-alan.com → 1.2.3.4 (izinli IP) → geçer
   T2 (getirme):   saldirgan-alan.com → 169.254.169.254 (iç IP) → SSRF
        ✗ Çözüm: bir kez çöz + IP'yi doğrula + SABİTLENMİŞ IP'ye bağlan

 GÜVENLİ (beyaz liste + IP pinning + iç aralık engeli):
   url → çöz → IP izinli mi & iç aralıkta değil mi → o IP'ye bağlan
        → metadata/iç ağ erişilemez

Kritik gözlem: SSRF savunması iki katmanlıdır — uygulama (URL/IP doğrulama, IP pinning) ve altyapı/kimlik (metadata sertleştirme + en az yetki). Capital One, ikinci katmanın (en az yetki) neden belirleyici olduğunu gösterdi.

4. Güvensiz Kod

Gerçekçi bir "URL'den görüntü çek / webhook" özelliği:

<?php
// ⚠️ GÜVENSİZ — SSRF
declare(strict_types=1);

// 1) Kullanıcı bir URL veriyor, uygulama getiriyor
$url = $_POST['image_url'];              // "http://169.254.169.254/..." olabilir
$data = file_get_contents($url);          // sunucu, saldırganın hedefine istek yapar
file_put_contents('/tmp/avatar', $data);

// 2) "Kara liste" savunması (atlatılabilir)
if (str_contains($url, 'localhost') || str_contains($url, '127.0.0.1')) {
    exit('Yasak');
}
// 169.254.169.254, 0.0.0.0, [::], ondalık IP (2130706433), DNS adı → hepsi geçer
$data = file_get_contents($url);

// 3) Webhook — yönlendirme takibi açık
$ch = curl_init($_POST['webhook_url']);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);   // iç hedefe yönlendirilebilir
curl_exec($ch);

5. Açığın Analizi

file_get_contents($_POST['image_url']) — Ders kitabı SSRF. Kullanıcı URL'i tümüyle kontrol ediyor; uygulama körü körüne getiriyor. http://169.254.169.254/... ile bulut kimlik bilgileri, http://10.0.0.5:6379/ ile iç Redis, file:///etc/passwd ile yerel dosya erişilebilir. Ayrıca file_get_contents PHP wrapper'larını (file://, php://) da işler — şema kısıtı yok.

Kara liste (localhost/127.0.0.1) — Bölüm 4'teki kara liste kusuru, SSRF'te özellikle zengin atlatmalarla: 169.254.169.254 (metadata — hiç engellenmemiş!), 0.0.0.0, [::], 127.0.0.1'in ondalık gösterimi (2130706433), sekizlik/onaltılık IP, kısaltılmış IP (127.1), saldırganın kontrol ettiği bir DNS adı (iç IP'ye çözülen), ve DNS rebinding. Kara liste burada neredeyse hiç işe yaramaz.

Webhook + CURLOPT_FOLLOWLOCATION — Yönlendirme takibi açık. Saldırgan, izinli görünen bir URL verir; o URL bir 302 ile 169.254.169.254'e yönlendirir. İlk URL doğrulansa bile, yönlendirme iç hedefe gider. Her yönlendirme hop'u yeniden doğrulanmalı ya da takip kapatılmalı.

Eksik: IP pinning. Hiçbir yerde alan adı çözülüp IP doğrulanmıyor; DNS rebinding'e (Bölüm 18) tümüyle açık.

Kök sorun: kullanıcı hedefi kontrol ediyor, doğrulama kara liste temelli/eksik ve çözülen IP sabitlenmiyor. En kritiği, bu SSRF'in etkisini altyapı belirler — metadata sertleştirmesi ve en az yetki yoksa, felaket (Capital One).

6. Hacker Bakış Açısı

Saldırgan SSRF'i nasıl arar ve istismar eder?

URL getiren özellikleri haritalar. Webhook, "URL'den içe aktar", link önizleme, PDF/görüntü üretimi, profil resmi URL'i, RSS — sunucunun bir hedefi getirdiği her yer. Kısmen kontrollü URL'ler (yalnızca yol/host'un bir kısmı) bile hedeftir.

İç hedefleri sırayla dener. Onaylanırsa, saldırganın ilk hedefi neredeyse her zaman bulut metadatadır (169.254.169.254 — AWS; metadata.google.internal — GCP; Azure'un uç noktası). Buradan IAM/servis kimlik bilgileri gelir. Sonra localhost yönetim panelleri, iç IP aralıkları (Redis/Elasticsearch/DB — çoğu kimlik doğrulamasız), ve file://.

Kara listeyi atlatır. Engel varsa: alternatif IP gösterimleri (ondalık, onaltılık, kısaltılmış), 0.0.0.0, IPv6 ([::1], [::ffff:127.0.0.1]), kendi DNS adı (iç IP'ye çözülen), yönlendirme zinciri, ve DNS rebinding (doğrulama sonrası IP değiştirme).

Kör SSRF'i istismar eder. Yanıt dönmese bile: zamanlama farkıyla iç port tarar, OOB kanalıyla (kendi sunucusuna gelen istek) doğrular, yan etkili iç uç noktaları tetikler.

Etkiyi düşünür. Kimlik bilgisi çaldığında, o rolün ne yapabildiğini keşfeder. Capital One'da WAF rolü S3'e erişebildiğinden, SSRF bir veri ihlaline dönüştü. Rol dar yetkili olsaydı, çalınan kimlik işe yaramazdı.

Savunmacı dersi: Saldırgan sunucuyu bir proxy olarak görür ve iç dünyaya açılan her kapıyı dener. Savunma hem kapıları (URL/IP doğrulama) hem de kapı ardındaki değeri (en az yetki, metadata sertleştirme) korumalıdır.

7. Exploit Mantığı

Bu bölüm çalıştırılabilir saldırı içermez. SSRF'in neden bu kadar yıkıcı olduğu kavramsaldır:

Sunucu = güvenilir proxy. İstek sunucudan çıktığı için, iç ağın "dışarıdan erişilemez" varsayımını çökertir. Saldırgan, kendi erişemediği her şeye sunucu aracılığıyla ulaşır.
Metadata = bulut anahtarları. IMDSv1 gibi kimlik doğrulamasız metadata servisleri, tek bir SSRF isteğiyle geçici bulut kimlik bilgileri verir. Bu, SSRF'i "iç istek" seviyesinden "bulut hesabı devri" seviyesine sıçratır.
En az yetki, etkiyi belirler. SSRF'in varlığı kötüdür; ama etkisi, çalınan kimliğin/erişilen servisin yetkisi kadardır. Capital One'da felaket, SSRF'ten değil, aşırı yetkili IAM rolünden geldi (Bölüm 1, 14).
Kör olsa da tehlikeli. Görünür yanıt olmadan bile iç tarama, yan etki tetikleme ve OOB sızdırma mümkündür.

Araştırmacının çerçevesi: (a) sunucu kullanıcı-kontrollü hedefe istek yapıyor mu, (b) hedef doğrulama beyaz liste + IP pinning mi (yoksa atlatılabilir mi), (c) metadata/iç servisler erişilebilir mi, (d) çalınabilecek kimliğin yetkisi ne. Savunma (b) ve (c)'yi kapatır, (d)'yi en az yetkiyle sınırlar.

8. Güvenli Kod

Beyaz liste + IP pinning + iç aralık engeli + şema kısıtı:

<?php
// ✅ GÜVENLİ — SSRF savunması (uygulama katmanı)
declare(strict_types=1);

/**
 * Güvenli getirme: şema kısıtı + alan adını ÇÖZ + IP'yi doğrula +
 * SABİTLENMİŞ IP'ye bağlan (DNS rebinding'i kapatır) + yönlendirme kapalı.
 */
function safeFetch(string $url): string
{
    $parts = parse_url($url);
    // 1) Şema beyaz listesi (yalnızca http/https)
    if (!in_array($parts['scheme'] ?? '', ['http', 'https'], true)) {
        throw new RuntimeException('İzin verilmeyen şema');
    }
    $host = $parts['host'] ?? '';

    // 2) İsteğe bağlı: alan adı beyaz listesi (en sağlam)
    $allowedHosts = ['images.example.com', 'cdn.example.com'];
    if (!in_array($host, $allowedHosts, true)) {
        throw new RuntimeException('İzin verilmeyen host');
    }

    // 3) Alan adını ÇÖZ ve her IP'yi doğrula (iç aralıkları engelle)
    $ips = gethostbynamel($host) ?: [];
    if (!$ips) { throw new RuntimeException('Çözülemedi'); }
    foreach ($ips as $ip) {
        if (isPrivateOrReserved($ip)) {       // metadata/iç ağ/loopback
            throw new RuntimeException('İç adres yasak');
        }
    }
    $pinnedIp = $ips[0];                        // SABİTLE (rebinding'i kapat)

    // 4) Sabitlenmiş IP'ye bağlan; Host başlığını koru; yönlendirme KAPALI
    $ch = curl_init($url);
    curl_setopt_array($ch, [
        CURLOPT_RESOLVE        => ["$host:80:$pinnedIp", "$host:443:$pinnedIp"],
        CURLOPT_FOLLOWLOCATION => false,        // yönlendirme takibi yok
        CURLOPT_PROTOCOLS      => CURLPROTO_HTTP | CURLPROTO_HTTPS,
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_TIMEOUT        => 5,
        CURLOPT_MAXFILESIZE    => 5_000_000,
    ]);
    $body = curl_exec($ch);
    if ($body === false) { throw new RuntimeException('Getirme başarısız'); }
    curl_close($ch);
    return $body;
}

/** RFC 1918 + loopback + link-local (169.254/16 = metadata!) + reserved */
function isPrivateOrReserved(string $ip): bool {
    return !filter_var($ip, FILTER_VALIDATE_IP,
        FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE);
}

Altyapı/kimlik katmanı (uygulama savunmasını tamamlar):

- IMDSv2 kullan: metadata servisine token'lı erişim → basit SSRF çekemez (AWS)
- Metadata'yı ağ seviyesinde engelle / hop-limit düşür
- Egress (giden) filtreleme: getirme servisi iç ağa/metadata'ya erişemesin (Böl. 27, 29)
- EN AZ YETKİ: instance/servis rolü yalnızca gerekene erişsin (Capital One dersi, Böl. 1, 14)

Öne çıkan modern kalıplar: - Beyaz liste (şema + host): Yalnızca ihtiyaç duyulan şema (http/https) ve host. En sağlam uygulama savunması. - Çöz + doğrula + IP pinning: Alan adını bir kez çöz, çözülen IP'yi iç aralıklara karşı doğrula, sonra o IP'ye bağlan (CURLOPT_RESOLVE). DNS rebinding'i (Bölüm 18) kapatır. - İç aralık engeli: FILTER_FLAG_NO_PRIV_RANGE|NO_RES_RANGE ile RFC 1918, loopback, link-local (169.254/16 — metadata dahil) engellenir. Kara liste değil, aralık-tabanlı. - Yönlendirme kapalı / hop doğrulama: CURLOPT_FOLLOWLOCATION = false veya her hop'u yeniden doğrula. - Şema/protokol kısıtı: CURLOPT_PROTOCOLS ile yalnızca HTTP/HTTPS; file://, gopher://, dict:// yok. - IMDSv2 + metadata engeli + en az yetki: Altyapı katmanı; SSRF olsa bile metadata çekilemez ve çalınan kimlik işe yaramaz.

9. Patch Analizi

Neden işe yarar? Beyaz liste, kullanıcının hedef seçme özgürlüğünü daraltır. İç aralık engeli, metadata (169.254.169.254) ve iç servisleri kapatır. IP pinning, DNS rebinding yarışını (Bölüm 18) kapatır: doğrulanan IP ile bağlanılan IP aynıdır. Yönlendirme kapatma, iç hedefe atlamayı önler. Ama en kritik katman altyapıdadır: IMDSv2 + en az yetki, SSRF başarılı olsa bile etkiyi yok eder — metadata token gerektirir ve çalınan rol hiçbir hassas kaynağa erişemez. Bu, derinlemesine savunmadır (Bölüm 1): uygulama katmanı düşse de altyapı tutar.

Savunmaların karşılaştırması:

Savunma	Katman	Not
Kara liste (`localhost`)	Uygulama	Zayıf; sayısız atlatma
Şema + host beyaz listesi	Uygulama	Güçlü; en sağlam uygulama savunması
İç aralık engeli (`NO_PRIV_RANGE`)	Uygulama	Metadata/iç ağ kapatır
IP pinning (`CURLOPT_RESOLVE`)	Uygulama	DNS rebinding'i kapatır
Yönlendirme kapatma	Uygulama	Redirect-to-internal önler
IMDSv2	Altyapı	Metadata'yı SSRF'ten korur (AWS)
Egress filtreleme	Ağ	Getirme servisini izole eder
En az yetki	Kimlik	Etkiyi belirler (Capital One)

Performans: DNS çözümü ve IP kontrolü küçük bir gecikme ekler (önbelleklenebilir); güvenlik kazancı çok büyüktür. IMDSv2 ve egress filtreleme'nin uygulama performansına etkisi yoktur.

10. Gerçek Hayat Senaryosu

Kurgu — bir SaaS "PDF rapor üreteci". Kullanıcılar bir HTML/URL veriyor, sunucu bunu headless bir tarayıcıyla render edip PDF üretiyor. Bu, klasik bir SSRF yüzeyidir: render motoru, kullanıcının verdiği URL'i (ve içindeki <img src>, fetch gibi alt kaynakları) sunucudan getirir. Bir saldırgan, rapor içine 169.254.169.254 metadata uç noktasını gömer; sunucu bunu getirip PDF'e basar veya render sırasında kimlik bilgilerini sızdırır. Bulut rolü (rapor servisinin gerçekte ihtiyaç duymadığı) S3/DB'ye erişebiliyorsa, saldırgan tüm müşteri verisine ulaşır — Capital One'ın SaaS versiyonu. Dersler: (1) sunucunun URL getirdiği her özellik (PDF/görüntü/webhook) bir SSRF yüzeyidir; (2) metadata sertleştirme (IMDSv2) ve en az yetki, uygulama savunması aşılsa bile felaketi önler; (3) render motorları alt kaynakları da getirir — kısıtlama tüm istekleri kapsamalı.

11. Gerçek Vaka Analizi — Capital One İhlali (2019, ~106 milyon kayıt)

ABD federal iddianamesi, Krebs on Security, ACM TOPS akademik analizi ve AWS açıklamalarıyla doğrulanmıştır. SSRF'in ders kitabı vakasıdır.

Özet. Mart 2019'da (Temmuz'da keşfedildi), eski bir AWS mühendisi olan Paige Thompson, Capital One'ın AWS ortamındaki bir SSRF açığını kullanarak yaklaşık 106 milyon kredi kartı başvuru kaydını (ABD'de ~100M, Kanada'da ~6M; ~140.000 SSN, ~80.000 banka hesabı, ~1M Kanada SIN'i) çaldı. Sonuç: OCC'den 80 milyon dolar ceza + 190 milyon dolar toplu dava uzlaşması; Thompson mahkûm edildi. Bu ihlal, endüstri çapında AWS IMDSv2 benimsemesinin doğrudan tetikleyicisi oldu.

Teknik neden — SSRF + metadata + aşırı yetki zinciri. Zincir dört adımdı: 1. Yanlış yapılandırılmış WAF (ModSecurity), bir EC2 örneğinde çalışıyordu ve internete açıktı. Bu WAF'ta bir SSRF açığı vardı (istekleri kullanıcı-kontrollü hedeflere iletebiliyordu). 2. Metadata servisine SSRF. Thompson, WAF'ı http://169.254.169.254/latest/meta-data/iam/security-credentials/ISRM-WAF-Role uç noktasına istek yaptırdı. Capital One IMDSv1 kullanıyordu — bu sürüm, basit bir HTTP isteğine kimlik doğrulamasız yanıt verip geçici IAM kimlik bilgilerini döndürüyordu. 3. Aşırı yetkili IAM rolü. ISRM-WAF-Role adlı rol, S3 kovalarını listeleme ve okuma yetkisine sahipti. Oysa bir WAF'ın veri deposuna erişmesi için hiçbir neden yoktu — bu, en az yetki (Bölüm 1, 14) ilkesinin ağır ihlaliydi. 4. Veri sızdırma. Çalınan kimlikle Thompson 700'den fazla S3 kovasını listeleyip indirdi (~30 GB). Veri şifreliydi ama rolün KMS çözme yetkisi de olduğundan çözülebildi.

Kritik ders şudur: felaketi yaratan SSRF'in kendisi değil, arkasındaki aşırı yetkiydi. Krebs ve akademik analiz (ACM TOPS) bunu net vurgular: rol dar yetkili olsaydı (yalnızca WAF'ın ihtiyacı kadar), çalınan kimlik S3'e erişemez ve SSRF "iç istek" seviyesinde kalırdı. Ayrıca hiçbir izleme alarmı tetiklenmedi — istekler "yetkili bir servisten gelen normal AWS API çağrıları" gibi göründü (Bölüm 31 izleme boşluğu).

Etki. 106 milyon kayıt; bulutun "geleneksel güven sınırlarını bulanıklaştırdığının" ders kitabı örneği — bir EC2 örneği hem bir güvenlik kontrolü (WAF) hem bir saldırı vektörü (metadata erişimi) olabiliyordu.

Çıkarılacak dersler: 1. SSRF'in etkisini en az yetki belirler. IAM rolüne yalnızca gerekli yetkiyi verin; bir WAF veri deposuna erişmemeli (Bölüm 1, 14). 2. Metadata servisini sertleştirin. IMDSv2 (token'lı) basit SSRF ile metadata çekilmesini engeller; AWS bunu tam bu saldırıya yanıt olarak çıkardı. 3. Bulut, güven sınırlarını değiştirir. Sunucu-tarafı istekler iç güvenin varsayımlarını çökertir; derinlemesine savunma (uygulama + ağ + kimlik) şarttır. 4. İzleme kritik. Alarm olmadığından ihlal aylarca sürdü; anormal API çağrıları izlenmeliydi (Bölüm 31).

12. Detection

Kod incelemede: Kullanıcı-kontrollü URL'e giden istekleri arayın:

grep -rnE '(file_get_contents|curl_init|fopen|readfile|get_headers)\(.*\$_(GET|POST|REQUEST)' src/
grep -rn  'CURLOPT_FOLLOWLOCATION' src/   # yönlendirme takibi açık mı?
grep -rnE 'str_contains.*localhost|127\.0\.0\.1' src/   # kara liste (atlatılır)

Kontroller: hedef beyaz listeden mi? İç aralıklar engelli mi (NO_PRIV_RANGE)? IP pinning var mı? Yönlendirme kapalı mı? Şema kısıtlı mı?

SAST: SSRF (CWE-918) için taint kuralları; kullanıcı girdisinden ağ-istek sink'ine izi bulur. DNS rebinding gibi çalışma-zamanı davranışlarını statik yakalamak zordur.

DAST: OOB (bant-dışı) tekniklerle SSRF'i tespit eder: uygulamayı, saldırganın kontrol ettiği bir sunucuya istek yaptırmayı deneyip gelen isteği gözlemler. Kör SSRF için standart yöntem budur.

Loglar/SIEM — güçlü sinyaller: Uygulama sunucusundan iç IP'lere/metadata'ya (169.254.169.254) giden istekler; olağandışı giden bağlantılar; ve Capital One'da atlanan asıl sinyal: beklenmeyen bir servisten gelen bulut API çağrıları (bir WAF'ın S3 listelemesi gibi). Bulut denetim logları (CloudTrail) ve giden ağ izleme, SSRF sonrası kimlik kötüye kullanımını yakalar. Metadata uç noktasına yapılan uygulama istekleri için özel alarm kurulmalıdır.

13. Prevention

Beyaz liste (şema + host): Sunucunun yalnızca ihtiyaç duyduğu hedefler; kara liste değil.
İç aralık engeli: RFC 1918, loopback, link-local (169.254/16) çözülen IP'de engellenir.
IP pinning: Çöz + doğrula + sabitlenmiş IP'ye bağlan (DNS rebinding'i kapatır, Bölüm 18).
Yönlendirme kapalı / hop doğrulama: Redirect-to-internal önlenir.
Şema/protokol kısıtı: Yalnızca HTTP/HTTPS; file:///gopher:// yok.
IMDSv2 + metadata sertleştirme: Bulutta metadata'yı SSRF'ten koru (AWS).
Egress filtreleme + segmentasyon: Getirme servisi iç ağa/metadata'ya erişemesin (Bölüm 27, 29).
En az yetki: Instance/servis rolü yalnızca gerekene erişsin — SSRF'in etkisini belirleyen katman (Bölüm 1, 14).
İzleme: Metadata/iç isteklere ve anormal bulut API çağrılarına alarm (Bölüm 31).

14. Mitigation

Acil: URL getiren uç noktaya beyaz liste + iç aralık engeli + yönlendirme kapatma ekle; IMDSv2'yi zorunlu kıl / metadata'yı ağ seviyesinde engelle.
Geçici: Bulut denetim loglarından (CloudTrail) SSRF sonrası kimlik kötüye kullanımını belirle; sızmış olabilecek geçici kimlikleri döndür; aşırı yetkili rolleri daralt (en az yetki).
Kalıcı: Uygulama katmanında IP pinning + beyaz liste; altyapıda IMDSv2 + egress filtreleme + en az yetki; metadata/anormal API alarmları ekle; testler.

15. Checklist

[ ] Sunucunun URL getirdiği her özellik (webhook, PDF, görüntü, içe aktarma) belirlendi mi?
[ ] Hedef beyaz listeden mi (şema + host), kara liste değil mi?
[ ] Çözülen IP iç aralıklara (RFC 1918, loopback, 169.254/16) karşı doğrulanıyor mu?
[ ] IP pinning var mı (DNS rebinding kapalı)?
[ ] Yönlendirme takibi kapalı veya her hop doğrulanıyor mu?
[ ] Yalnızca HTTP/HTTPS şemasına izin veriliyor mu?
[ ] Bulutta IMDSv2 zorunlu / metadata ağ seviyesinde engelli mi?
[ ] Instance/servis rolü en az yetkili mi (SSRF etkisini sınırlar — Capital One)?
[ ] Metadata/iç isteklere ve anormal bulut API çağrılarına alarm var mı?

16. Laboratuvar

Lab 21.1 — Temel SSRF. İzole ortamda file_get_contents($_POST['url']) kur; kendi kurduğun bir iç servise (ör. yerel bir HTTP dinleyici) istek yaptır ve sunucunun proxy'ye dönüştüğünü gözlemle. Beyaz liste + iç aralık engeliyle düzelt.

Lab 21.2 — Kara liste atlatma. localhost/127.0.0.1 engelleyen bir kara liste yaz; ondalık IP (2130706433), 0.0.0.0, 127.1 ve IPv6 ile atlat. Aralık-tabanlı (FILTER_FLAG_NO_PRIV_RANGE) doğrulamaya geç.

Lab 21.3 — DNS rebinding (kavramsal). Doğrulama ile getirme arasında farklı IP'ye çözülen bir senaryoyu (kendi kontrol ettiğin bir DNS ile) modelle; IP pinning (CURLOPT_RESOLVE) ile kapat. TOCTOU (Bölüm 18) ile ilişkisini açıkla.

Lab 21.4 — Yönlendirme. CURLOPT_FOLLOWLOCATION=true ile izinli bir URL'in iç hedefe yönlendirilebildiğini gözlemle; takibi kapatıp düzelt.

17. Quiz

SSRF'in tek cümlelik tanımı nedir? CSRF'ten (Bölüm 17) farkı nedir (kimin isteği)?
Sunucu neden değerli bir "proxy"dir? Hangi hedeflere saldırgandan farklı erişebilir?
Bulut metadata servisi (169.254.169.254) neden SSRF'in en değerli hedefidir?
Kara liste (localhost engeli) neden SSRF'te özellikle zayıftır? En az üç atlatma sayın.
DNS rebinding nedir ve "doğrula-sonra-getir" kalıbındaki hangi yarışı (Bölüm 18) istismar eder?
IP pinning DNS rebinding'i nasıl kapatır?
Kör (blind) SSRF neden hâlâ tehlikelidir?
Capital One'da felaketi yaratan SSRF miydi? En az yetki nasıl bir rol oynadı?
IMDSv2, IMDSv1'e göre SSRF'e karşı neyi değiştirir?
Neden SSRF savunması iki katmanlıdır (uygulama + altyapı/kimlik)?
Bir PDF/görüntü üreteci neden bir SSRF yüzeyidir?
SIEM'de SSRF sonrası kimlik kötüye kullanımını gösteren sinyal nedir (Capital One'da atlanan)?

18. Kaynakça

OWASP, Server-Side Request Forgery Prevention Cheat Sheet; SSRF (WSTG); Top 10:2021 — A10 SSRF.
MITRE, CWE-918: Server-Side Request Forgery (SSRF).
ABD Adalet Bakanlığı, United States v. Paige Thompson iddianamesi; Krebs on Security, What We Can Learn from the Capital One Hack (2019).
ACM Transactions on Privacy and Security, A Systematic Analysis of the Capital One Data Breach.
AWS, Instance Metadata Service Version 2 (IMDSv2) dokümantasyonu ve duyurusu.
PHP Manual, curl_setopt (CURLOPT_RESOLVE, CURLOPT_PROTOCOLS, CURLOPT_FOLLOWLOCATION), filter_var (FILTER_FLAG_NO_PRIV_RANGE) referansları.