SSRF Nedir? Sunucuyu Kendine Karşı Kullanmak

Giriş

2019’da Capital One bankası, 100 milyondan fazla insanın kişisel verisini tek bir saldırıda kaybetti. Arkasında ne aylarca süren karmaşık bir operasyon vardı ne de pahalı bir sıfırıncı-gün (zero-day) açığı. Saldırgan, bankanın kendi koruma katmanını (yanlış yapılandırılmış bir WAF) kandırıp ona iç ağdaki gizli bir adrese istek attırdı; sunucu, kendi attığı bu isteğe körü körüne güvendiği için kapıyı açtı. Bu tekniğin adı SSRF (Server-Side Request Forgery — Sunucu Taraflı İstek Sahteciliği). Sızan geçici kimlik bilgileriyle (credentials) saldırgan 700’den fazla depolama kovasına (S3 bucket) ulaştı, yaklaşık 30 GB veri ve 140.000 sosyal güvenlik numarası sızdırdı. Banka için fatura ağırdı: ABD Para Birimi Denetim Ofisi (OCC) 80 milyon dolar idari ceza kesti, ardından Capital One mağdur müşterilerle yapılan toplu davayı 190 milyon dolar ödeyerek sonuçlandırdı — toplamda 270 milyon doları bulan bir maliyet.

İşin sarsıcı tarafı şu: bu, dahiyane bir tek seferlik numara değildi. SSRF, web uygulamalarında düşündüğünden çok daha yaygın bir zafiyet ve OWASP tarafından da ayrı bir risk kategorisi (A10:2021) olarak listeleniyor. Üstelik mantığı, daha önce işlediğimiz IDOR ile aynı kökten besleniyor: kullanıcı girdisine körü körüne güvenmek.

Beni en çok şaşırtan, milyarlık bir güvenlik altyapısının tek bir URL parametresiyle devre dışı kalmasıydı — karmaşıklık değil, ihmal kazandı.

SSRF Tam Olarak Ne?

Temelde SSRF çok basit bir fikre dayanır: uygulama, kullanıcının verdiği bir URL’ye sunucunun adına gidip içeriği getiriyorsa ve bu URL’yi denetlemiyorsa, saldırgan sunucuyu istediği adrese yönlendirebilir.

Bunu günlük örneklerle düşün: “şu linkten resmi indir”, “şu sayfanın önizlemesini getir”, “bu URL’den PDF oluştur” gibi özelliklerin hepsi, arka planda sunucunun senin verdiğin bir adrese istek atmasıyla çalışır. Sen “kedi.jpg” beklerken, saldırgan oraya bambaşka bir adres yazarsa ne olur?

POST /resim-onizleme
{ "url": "https://site.com/kedi.jpg" }     <- normal kullanım

{ "url": "http://169.254.169.254/..." }    <- SSRF saldırısı

Burada anlaşılması gereken kritik ayrım şu: dış istek vs iç istek. Normalde sen bir web sitesine dışarıdan istek atarsın ve uygulama, kim olduğunu, neye erişebileceğini sorgular. Ama SSRF’te isteği atan sen değil, sunucunun ta kendisidir. İç ağdaki diğer servisler ise “bu istek bizim sunucumuzdan geliyor” diye düşünüp onu güvenilir sayar — çünkü iç ağ, dışarıya kapalı olduğu varsayımıyla kurulmuştur. Saldırgan tam da bu güveni istismar eder: kendi ulaşamadığı kapıyı, sunucuya açtırır.

IDOR yazısındaki “authentication (kimlik doğrulama) vs authorization (yetkilendirme)” ayrımını hatırla. Orada uygulama “bu kullanıcı bu veriye erişebilir mi?” sorusunu unutuyordu. SSRF’te ise uygulama “bu URL’ye gitmem güvenli mi?” sorusunu unutuyor.

SSRF Türleri

SSRF’i ikiye ayırmak, nasıl test edeceğini de belirler:

Basic (Klasik) SSRF: Sunucunun gittiği adresten dönen yanıt, sana geri yansıtılır. Yani sunucuyu iç bir adrese yönlendirdiğinde, oradan gelen içeriği doğrudan ekranında görürsün. Saldırı sonucu anında elindedir.

Blind (Kör) SSRF: Sunucu isteği atar ama yanıtı sana dönmez. Ekranda hiçbir şey değişmez; saldırının gerçekleşip gerçekleşmediğini doğrudan göremezsin. Bu, IDOR’daki “Blind” türüne çok benzer: değişiklik arka planda olur, sen sonucu dolaylı yoldan ispatlamak zorundasın. Burada işin püf noktası, isteği kendi kontrol ettiğin bir sunucuya attırmaktır — istek sana düşerse, zafiyetin var demektir.

SSRF Neyi Hedefler?

SSRF bir kez mümkün olduğunda, saldırganın önünde birkaç hedef açılır:

• İç ağ servisleri: localhost, 127.0.0.1 ve dışarıya kapalı iç IP’ler. Yönetim panelleri, sağlık kontrolü uçları, dahili API’ler… Hepsi “nasıl olsa dışarıdan erişilemez” diye korunmasız bırakılmış olabilir.
• Cloud metadata adresleri — en kritik hedef: AWS, GCP, Azure gibi bulut sağlayıcılarında her sunucunun eriştiği özel bir “metadata” adresi vardır: 169.254.169.254. Bu, internette gezen normal bir IP değil; sanal makine ile altyapı arasındaki dahili iletişimi sağlayan bir “yerel bağlantı adresi”dir (link-local address). Tehlikeli kılan şey ise şu: bu adres, sunucuya tanımlanmış geçici kimlik bilgilerini (IAM credentials) barındırır. Capital One’da çalınan o credentials işte tam buradan, bu adres üzerinden alındı. SSRF, saldırganın bu kapıya sunucunun ağzından ulaşmasını sağlar.
• Port taraması: Saldırgan, sunucuyu bir tarama aracı gibi kullanıp iç ağdaki hangi portların açık olduğunu, hangi servislerin çalıştığını haritalandırabilir.

Neden Tehlikeli ve Neden Bu Kadar Yaygın?

SSRF’in en sinsi tarafı, çoğu zaman masum görünen özelliklerin içinde saklanıyor olmasıdır. “URL’den resim çek”, “link önizlemesi”, “webhook gönder”, “sayfayı PDF’e çevir” — bunların hepsi, geliştiricinin kullanıcıya bir kolaylık sunmak için eklediği, tamamen iyi niyetli özelliklerdir. Ama her biri, denetlenmediğinde birer SSRF kapısına dönüşür.

Modern mimariler bu riski katlıyor. Mikroservis ve bulut tabanlı sistemlerde onlarca iç servis birbiriyle sürekli konuşur ve birbirine güvenir. Bu güven ağında tek bir SSRF açığı, saldırgana bütün iç ağı dolaşabileceği bir geçiş kartı verir. Dışarıdaki bir kale duvarını aşmak yerine, saldırgan içerideki bir kuryeyi kandırıp tüm kapıları ona açtırır.

Artık bir sitede “URL’den resim yükle” gördüğümde ilk düşüncem “acaba bunu test ettiler mi?” oluyor — masum bir özellik, potansiyel bir kapı.

SSRF Nasıl Test Edilir?

SSRF testinin temeli, uygulamanın bir URL aldığı her noktayı bulup o URL’yi manipüle etmektir. Yaygın olarak göz atılacak parametreler: url=, image=, webhook=, callback=, path=. Pratikte izlenen yol şudur:

1. Trafiği yakala: Burp Suite (Community Edition yeterli) ile uygulamanın arka planda nereye istek attığını gör. Bir özelliğin gövdesinde dahili bir adres geçiyorsa, orası iyi bir adaydır.
2. İç adresleri dene: Parametreyi http://localhost/admin, http://127.0.0.1, ya da bulut ortamıysa http://169.254.169.254/... ile değiştir. Dışarıdan kapalı bir uç, sunucu üzerinden açılıyorsa zafiyet ortaya çıkar.
3. Blind SSRF için dinle: Yanıt geri dönmüyorsa, isteği Burp Collaborator’a veya kendi sunucuna attır. İstek sana düşüyorsa, sunucu senin verdiğin adrese gerçekten gidiyor demektir.

Bu mantığı somut görmek için PortSwigger Web Security Academy’nin ücretsiz “Basic SSRF against the local server” labı birebir uygundur. Lab, dışarıdan erişilemeyen bir admin paneline (http://localhost/admin) sunucu üzerinden ulaşmayı gösterir: bir ürünün “stok kontrol” özelliği arka planda dahili bir adrese istek atar; o adresi localhost/admin ile değiştirdiğinde, dışarıdan kapalı olan panel sunucunun ağzından açılır. Bizzat denediğinde, tekniğin ne kadar etkili ve temiz işlediğini görüyorsun — tek bir parametreyi değiştirmek, koca bir iç kapıyı açmaya yetiyor.

/admin‘e tarayıcıdan gitmeye çalıştığımda “erişim yok” aldım; stockApi parametresini http://localhost/admin yapınca panel önüme açıldı. Sunucunun kendi isteğine bu kadar körü körüne güvenmesi, güvenliğin sadece dışarıdan değil içeriden de düşünülmesi gerektiğini somutlaştırdı.

SSRF Nasıl Önlenir?

SSRF’e karşı tek bir sihirli önlem yoktur; savunma katman katman kurulur:

• Allowlist (izin listesi) kullan: Kullanıcının gidebileceği adresleri sınırlı bir beyaz listeyle tanımla. “Şunlar yasak” demek (blocklist) yerine “yalnızca şunlara izin var” demek çok daha güçlüdür, çünkü saldırganın bypass yöntemlerini büyük ölçüde kapatır.
• İç adresleri ve metadata uçlarını engelle: İç IP aralıklarına ve özellikle 169.254.169.254 metadata adresine giden istekleri kapat.
• URL şemasını denetle: Yalnızca http/https‘e izin ver. file:// (sunucunun yerel dosyalarını, örneğin /etc/passwd‘yi okuyabilir) ve gopher:// (iç veritabanlarına ham TCP paketi gönderip komut çalıştırmaya kadar gidebilir) gibi şemaları engelle.
• Yanıtı olduğu gibi döndürme: Sunucunun çektiği içeriği kullanıcıya ham haliyle yansıtmazsan, Basic SSRF’in etkisini ciddi biçimde kısarsın.
• Bulut tarafını sertleştir: Burada Capital One’ın dersi netleşiyor: banka, kimlik doğrulaması istemeyen eski metadata sürümünü (IMDSv1) kullanıyordu. AWS bu saldırı kalıbını engellemek için IMDSv2’yi çıkardı; IMDSv2 önce bir oturum tokenı alınmasını, sonra bu tokenın özel bir HTTP başlığıyla gönderilmesini zorunlu kılar. SSRF saldırılarında genelde özel başlık eklemek mümkün olmadığından, bu önlem saldırıyı pratikte bitirir.

IDOR yazısındaki “tek bir savunma hattı çökerse her şey çöker” mantığı burada da geçerli: kod tarafında allowlist yazmak güzeldir, ama altyapı tarafında IMDSv2 gibi bir katman olmadan eksik kalır.

Sonuç

• SSRF, sunucuyu kandırıp onun adına istek attırma zafiyetidir; kökeninde kullanıcı girdisine körü körüne güvenmek yatar.
• En yıkıcı etkisini bulut ortamlarında, metadata adresi (169.254.169.254) üzerinden kimlik bilgilerini sızdırarak gösterir — Capital One bunun canlı kanıtıdır.
• “Resim önizleme, webhook, PDF oluşturma” gibi en masum özellikler bile birer SSRF kapısı olabilir; bu yüzden URL alan her nokta denetlenmelidir.
• Savunma katmanlıdır: allowlist, iç adres engelleme, şema kontrolü ve bulut tarafında IMDSv2 birlikte çalışmalıdır.

Bana en ilginç gelen, saldırının “dışarıdan içeri” değil “içeriden içeri” çalışması — güvenlik duvarı tamamen devre dışı, çünkü istek zaten içeriden geliyor.

Kaynakça

1. OWASP — Server-Side Request Forgery: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery
2. OWASP Top 10:2021 — A10 SSRF: https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/
3. PortSwigger Web Security Academy — SSRF: https://portswigger.net/web-security/ssrf
4. OWASP — SSRF Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html
5. AWS — Instance Metadata Service (IMDSv2): https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html
6. U.S. DOJ — Paige Thompson davası (Capital One saldırganı): https://www.justice.gov/usao-wdwa/pr/former-hacker-sentenced-stealing-computer-power-mine-cryptocurrency-and-stealing
7. OCC — Capital One’a 80 milyon dolarlık idari para cezası bildirisi: https://www.occ.gov/news-issuances/news-releases/2020/nr-occ-2020-101.html
8. The Washington Post — Capital One’ın 190 milyon dolarlık toplu dava uzlaşması (Aralık 2021): https://www.washingtonpost.com/business/economy/capital-one-financial-agreed-to-pay-190-million-to-settle-customer-lawsuit-over-cyberattack/2021/12/23/fa69348c-63e8-11ec-bf70-58003351c627_story.html
9. Capital One Data Breach Settlement — resmi uzlaşma sitesi (190M dolarlık fon, mahkeme onayı 13 Eylül 2022): https://www.capitalonesettlement.com/en

İleri okuma (opsiyonel): Orange Tsai — “A New Era of SSRF: Exploiting URL Parser in Trending Programming Languages” (Black Hat USA 2017). Resmi sunum slaytları: https://blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf