SSRF: sunucuyu istek atmaya zorlamak

Bazı uygulamalar senin verdiğin adresten içerik çeker. Uzaktan görsel indirme, web kancası testi, bağlantı önizlemesi, belge dönüştürme. Bu isteği senin bilgisayarın değil, sunucu gönderir.

Fark kritiktir: sunucu iç ağın içindedir ve senin erişemediğin yerlere kendi konumundan ulaşır. Sunucu tarafı istek sahteciliği, kısaca SSRF, uygulama bu adresi denetlemediğinde doğar. Bu derste açığın neden sunucunun ağ konumundan güç aldığını, bulut üstverisinin neden ilk hedef olduğunu, kör biçimin nasıl kanıtlandığını ve savunmanın neden beyaz listeyle kurulduğunu göreceksin.

Uygulama senin verdiğin adresi doğrulamadan çağırdığında, istek atma yetkisini sana devretmiş olur. Senin tarayıcın iç ağdaki yönetim arayüzüne ulaşamaz, çünkü o servisler dışarıya kapalıdır. Ama sunucu aynı ağın içindedir; onun için o adresler bir komşu kadar yakındır. SSRF'in değeri tam buradadır.

Saldırgan, sunucuyu bir vekil gibi kullanır ve kendi ulaşamadığı hedeflere onun ağından erişir. İç servisler çoğu zaman kimlik doğrulaması bile istemez, çünkü iç ağ güvenli sayılır. Bu varsayım tek bir SSRF ile geçersiz kalır. Sunucunun konumu, saldırgana kiralanan asıl değerdir.

SSRF'in değeri çoğu zaman zincirde ortaya çıkar. Tek başına bir iç sayfayı getirmek küçük görünür. Aynı açık üstünden bir yönetim arayüzüne ulaşırsın; oradan bir yapılandırma ya da kimlik bilgisi okunur; o bilgiyle bulut hesabına geçilir.

Zincirin her halkası ayrı bir varsayımı boşa çıkarır ve toplamda risk kritik seviyeye taşınır. Bu yüzden bir SSRF bulgusunu tek adımda değerlendirmezsin. Nereye kadar uzandığını, hangi iç servislere dokunabildiğini haritalarsın. Ama bu haritayı yetkili testte dizginlersin: erişilebilirliği kanıtlar, veriyi çoğaltmaz ve kritik bulguyu beklemeden bildirirsin.

Şemadaki zincir tek adımda bitmez ve her halka ayrı bir varsayımı boşa çıkarır. İlk halka uygulamanın kendisidir: senin verdiğin adresi doğrulamadan çağırır.

İkinci halka sunucunun ağ konumudur; istek oradan çıktığı için iç ağdaki adreslere ulaşır. Üçüncü halka ise hedeftir: bulut üstverisi, yönetim paneli ya da kimlik doğrulaması istemeyen bir iç servis. Zincirin gücü, saldırganın kendisinin hiç ulaşamadığı bir yere sunucuyu vekil gibi kullanmasından gelir. Aşağıdaki örnekte bu ilk halkayı, yani doğrulanmayan adresi, sen kuracaksın.

Bulut ortamında klasik hedef, bağlantı yerel aralıktaki üstveri adresidir: 169.254.169.254. Bu adres yalnız sunucunun kendisinden görünür ve örnek hakkında bilgi döner. Eski sürümlerde bu uçtan geçici kimlik bilgileri de okunabiliyordu; işte SSRF'i kritik seviyeye taşıyan basamak buydu.

Yeni sürüm, üstveri servisine erişmeden önce bir oturum jetonu ister ve basit SSRF'i kırar. Yetkili testte bu ucun eriştiğini kanıtlaman yeter; dönen kimlik bilgisini kullanmaz, çıktıyı maskeleyerek kaydeder ve müşteriye acil bildirim maddesiyle haber verirsin. Amaç açığı ispatlamaktır, ondan yararlanıp kapsamı aşmak değil.

Her SSRF yanıt gövdesini sana göstermez. Kör SSRF'te uygulama, çektiği içeriği ekrana basmaz. O zaman dolaylı kanıta geçersin. Kendi kontrolündeki bir adrese istek attırır ve o adrese bir çağrının ulaşıp ulaşmadığını izlersin.

Sunucunun senin adını çözmek için yaptığı bir ad çözümleme isteği bile, girdinin işlendiğini kanıtlar. Bu kanal her zaman senin altyapın olmalı; müşterinin iç bilgisini üçüncü taraf bir hizmete taşımak, kapsam belgesinde yazmıyorsa veri aktarımı sorunu doğurur. Kör SSRF, yanıt görünmese bile açığın orada durduğunu ortaya koyar.

Bu açığın gerçek dünyadaki bedeli ağırdır. 2019'da büyük bir finans kuruluşunda yanlış yapılandırılmış bir bileşen bir SSRF'e açıldı. Saldırgan sunucunun üstveri ucundan geçici kimlik bilgisi okudu ve bulut depolamasındaki verilere ulaştı. Yüz milyondan fazla kişinin kaydı etkilendi.

Ders açık: iç ağ güvenli sayıldığı için korumasız bırakılan servisler, tek bir SSRF ile erişilebilir olur. Üstveri servisinin oturum jetonlu sürümü ve ağ bölümlemesi, bu zincirin en zayıf halkalarını kapatır. Tek bir kod hatasının bütün bir hesabı açması, katmanlı savunmanın neden gerektiğini gösterir.

Açığı doğuran satırı gördün; şimdi bu satırın en çok hangi hedefe yöneldiğini pekiştir. Bulut ortamında ilk durak, yalnız sunucunun kendisinden görünen üstveri adresidir. Bu adresi ezbere bilmek, bir SSRF bulgusunu saniyeler içinde doğrulamana yarar. Aynı bilgi savunma tarafında da işe yarar.

Bu adres bağlantı yerel aralıktadır ve normal bir uygulamanın iş trafiğinde hiç görünmez. Bu yüzden çıkış trafiğini izleyen bir ekip için, sunucudan bu adrese giden tek bir istek bile güçlü bir alarm sinyalidir. Önce adresi kendin tanı, sonra onu bir gösterge olarak kullan. Aşağıdaki boşluğa o adresi yaz.

Savunmayı bir engel listesiyle kurmak hızlı ama kırılgandır. Uygulama yalnız localhost sözcüğünü ya da tek bir yazımı engellerse, aynı adrese ulaşmanın başka biçimleri açık kalır. Bir adres, ondalık ya da farklı bir sayı tabanıyla yazılabilir; kısaltılmış biçimleri aynı yere çözülür. Saldırgan kendi alan adını iç bir adrese çözecek biçimde de tanımlayabilir.

DNS yeniden bağlama denen yöntem ise denetim anı ile istek anı arasındaki zaman farkını kullanır: kontrol sırasında adres güvenli, istek sırasında iç adres görünür. Bu yüzden engel listesi tek başına dayanmaz. Kalıcı çözüm, neyin yasak olduğunu değil, neyin izinli olduğunu tanımlamaktır.

Protokol yüzeyi de etkiyi belirler. Uygulama yalnız HTTP adreslerini çağırıyorsa alan dardır. Ama adres şeması denetlenmiyorsa, dosya okuma ya da başka servislerle konuşma şemaları açık kalabilir. O zaman istek, iç ağdaki farklı servislere de uzanabilir.

Adres ayrıştırma farkları da yol açar: uygulamanın gördüğü konak adı ile isteği atan kütüphanenin gördüğü ad birbirinden farklı olabilir. İki katmanın adresi aynı okumaması, denetimi boşa çıkarır. Bu yüzden savunma, çözülen gerçek adrese bakmak zorundadır, metnin göründüğü biçimine değil.

SSRF en sık, kullanıcıdan adres alan özelliklerde görülür. Web kancası kurulumu, içe aktarma, bağlantı önizlemesi, uzak görsel işleme ve belge üretimi aynı aileye girer. Bu özelliklerin ortak yanı, uygulamanın kullanıcının verdiği bir adrese gitmesidir.

Yeni bir özellik eklerken sorulacak soru net: bu adres nereye çözülüyor ve gerçekten oraya gitmeli miyiz? Adres denetimi bu özelliklerin tasarımına en baştan girmezse, açık sonradan kapatılması zor bir borç olur.

SSRF tespiti çıkış trafiğini izlemekle başlar. Uygulama sunucusunun normalde konuşmadığı bir iç adrese ya da üstveri ucuna istek atması güçlü bir sinyaldir. Çıkış istekleri bir vekil üstünden geçirilip kaydedilirse, beklenmedik hedefler alarma bağlanabilir.

Kör SSRF bile bu katmanda iz bırakır: sunucudan çıkan olağan dışı bir ad çözümleme isteği, saldırının denendiğini gösterir. Savunma yalnız girdiyi denetlemek değil, çıkışı da gözlemektir. Önce hangi iç hedeflerin gerçekten risk taşıdığını ayırt et.

İç hedefleri tanımak saldırı yüzeyini anlamana yarar; ama asıl soru bu yüzeyi nasıl kapattığındır. Engel listesi hızlı kurulur ve çabuk aşılır; izin listesi ise neyin serbest olduğunu tek tek sayar. İkisi arasındaki fark bir örnekle netleşir.

Engel listesi localhost sözcüğünü kesse bile, saldırgan aynı adrese ondalık yazımla ya da yerel bir adrese çözülen kendi alan adıyla ulaşır. İzin listesi ise yalnız senin saydığın birkaç adrese gider; dışındaki her istek, nasıl yazılırsa yazılsın, en baştan reddedilir. Bu yüzden savunmayı yasakların üstüne değil, izinlerin üstüne kurarsın. Bir sonraki soruda, listelenen yaklaşımların hangisinin gerçekten dayanıklı olduğunu seç.

Sağlam savunma tek katman değildir. İlk kural beyaz listedir: izin verilen alan adları önceden sabitlenir, dışındaki her adres reddedilir. İkinci kural, adı çözüp gerçek adresi denetlemektir; ad güvenli görünse bile çözülen adres iç aralıktaysa istek durur. Üçüncü kural, yönlendirme takibini kapatmaktır, çünkü güvenli bir adres iç bir adrese yönlendirebilir.

Dördüncü kural ağ katmanındadır: uygulama sunucusunun çıkış trafiği yalnız gerekli adreslere açılır ve iç yönetim arayüzleri ayrı bir ağ bölümünde durur. Böylece koddaki bir hata tek başına iç ağa dönüşmez. Bulguyu raporlarken hangi iç adrese ulaştığını yazar, yanıtın bir bölümünü maskeleyerek eklersin. Somut adres olmadan ekip etkinin boyutunu göremez.

Aynı mantık konteyner ve fonksiyon tabanlı ortamlarda da geçerlidir. Orkestratör arayüzü, dahili kuyruk ve yapılandırma servisi de kimlik doğrulaması istemeyen iç uçlar olabilir. Sunucudan çıkan her istek, önce çözülen adresin izin verilen listede olup olmadığı sorusundan geçmelidir.

Savunmayı tek bir maddeye indirgemek yanıltır; beyaz liste, adres denetimi, kapatılmış yönlendirme ve ağ bölümlemesi birlikte çalışır. Tek katman er geç aşılır, üst üste katman ise saldırganın önüne art arda kapı koyar. Her yeni özellik eklenirken bu katmanların da gözden geçirilmesi gerekir; yoksa güvenli sanılan bir uygulama, tek bir yeni adres alanıyla iç ağa yeniden açılır.

SSRF'in listedeki yeri de değişti. Bulut mimarileri yaygınlaştıkça açık yeterince sık görüldü ve 2021 sürümünde topluluk anketiyle ayrı bir madde olarak listeye girdi. 2025 sürümünde ise SSRF, bozuk erişim denetimi başlığının altına katıldı; çünkü özünde bu da bir erişim denetimi sorunudur.

Sunucu, ulaşmaması gereken bir kaynağa senin adına ulaşır. Sınıflandırmanın değişmesi tekniğin önemini azaltmaz; aksine SSRF'i erişim denetimi ailesinin bir parçası olarak görmek, savunmayı doğru yere koymana yardım eder. Aynı listede enjeksiyon A05 başlığıdır ve XSS de bu başlığın altında durur.

Sınıflandırmayı yerine oturtmak, savunmayı doğru başlığa bağlamana yarar. Son olarak kör biçimin neden göz ardı edilemeyeceğini pekiştir. SSRF'in yalnız yanıt ekrana basıldığında sömürülebildiği sanılır; oysa yanıt hiç görünmese bile dışarı çıkan tek bir istek açığı ele verir. Tespit tarafı da buna dayanır.

Sunucunun daha önce hiç konuşmadığı bir adrese yaptığı ad çözümleme isteği, çıkış günlüğünde tek başına bir ipucudur. Bu yüzden kör SSRF, hem saldırı hem savunma açısından, görünmez sanılan ama iz bırakan bir açıktır.