SSRF (sunucu taraflı istek sahteciliği) nedir?

Bazı siteler, sizin verdiğiniz bir adrese kendileri gidip bir şey getirir. Bir profil sayfasına fotoğrafınızın adresini yapıştırırsınız, site o adrese gidip resmi indirir ve profilinize koyar. Bir mesajlaşma uygulamasına bir bağlantı yazarsınız, uygulama o sayfanın başlığını ve küçük resmini çıkarıp gösterir. Bir belge dönüştürme hizmetine bir dosyanın adresini verirsiniz, hizmet dosyayı indirip PDF’e çevirir. Bir yazılım, başka bir sisteme olay bildirimi göndermek için verdiğiniz adrese istek atar. Bütün bu durumlarda asıl isteği yapan sizin tarayıcınız değil, sitenin sunucusudur. İşte SSRF buradan doğuyor.

SSRF, “server-side request forgery” ifadesinin kısaltması, Türkçede sunucu taraflı istek sahteciliği olarak geçer. Fikir şu: Saldırgan, siteye bir dış adres vermek yerine, sunucunun normalde sizin adınıza gitmemesi gereken bir yere gitmesini sağlar. Çünkü sunucu, dış dünyadan farklı bir konumda durur. Sizin dışarıdan hiç ulaşamayacağınız iç sistemlere o rahatça erişebilir. Saldırgan da tam olarak bunu kullanır: Kendisi giremediği kapıdan, sunucuyu içeri yollayıp eline ne geçerse ister.

Bunu bir şirketin resepsiyonu gibi düşünebilirsiniz. Dışarıdan gelen biri binanın iç katlarına çıkamaz. Ama resepsiyondaki görevliye “şu katın arşivinden bana bir dosya getirir misiniz” derse ve görevli bunun kimin işi olduğunu sorgulamadan dosyayı getirirse, ziyaretçi içeri hiç girmeden içerideki bilgiye ulaşmış olur. SSRF’de görevli sunucu, ziyaretçi saldırgandır.

Neden bu kadar işe yarıyor?

Kurumların ağında, yalnızca içeriden erişilebilen pek çok sistem vardır: yönetim panelleri, veritabanları, önbellek sunucuları, iç API’ler, izleme araçları. Bunlar genelde “nasılsa dışarıdan kimse ulaşamaz” varsayımıyla daha az korunur. Bir kısmı hiç parola istemez, çünkü yalnızca içerideki güvenilir sistemlerin onlarla konuşacağı varsayılır. SSRF bu varsayımı çökertir: Saldırgan artık içeriden konuşan güvenilir bir sistemin arkasına saklanmıştır.

Bulutta neden ayrıca tehlikeli?

Bulut sistemlerinde, her sunucunun kendi kimlik ve ayar bilgilerini tuttuğu özel bir iç adres bulunur. Buna meta veri servisi deniyor. Sunucu bu adrese sorduğunda, bulut hizmetindeki diğer kaynaklara erişmek için kullandığı geçici erişim anahtarlarını alabiliyor. Bu adrese yalnızca sunucunun kendisi ulaşabiliyor, dışarıdan erişilemiyor.

Ama saldırgan SSRF ile sunucuyu bu iç adrese yöneltebilirse, sunucunun erişim anahtarlarını ele geçirebilir. Bu anahtarlarla da, sunucuya verilmiş yetki ne kadarsa, bulut hesabındaki depolama alanlarına, veritabanlarına ve diğer kaynaklara ulaşabilir. Dışarıdan basit görünen bir açık, bir anda bütün bulut hesabına açılan bir kapıya dönüşür.

Bu senaryonun en bilinen örneği 2019’daki Capital One olayı. Bir saldırgan, bankanın bulutta çalışan bir güvenlik duvarındaki yapılandırma hatasından yararlanarak sunucuyu meta veri servisine yönlendirdi, erişim anahtarlarını aldı ve yaklaşık 100 milyon kişinin bilgilerine ulaştı. Olaydan sonra büyük bulut sağlayıcıları meta veri servislerine ek korumalar getirdi.

Sitedeki örnekler

SSRF, büyük üreticilerin ürünlerinde de düzenli olarak çıkıyor. SonicWall’un uzaktan erişim cihazı SMA1000’deki açık giriş yapmamış bir saldırganın cihaza kendi adına istek göndertmesine izin veriyordu ve CVSS puanı 10’du. Yamadan üç gün sonra istismar denemeleri görüldü.

SAP’nin Python geliştirme kitindeki açık ise SSRF’in farklı bir yüzünü gösteriyor. Orada saldırgan sunucuyu bir iç sisteme değil, kendi sunucusuna yönlendiriyordu. Uygulama erişim belirteci almak için istek gönderirken, bu istek saldırganın sunucusuna gidiyor ve uygulamanın erişim bilgileri saldırgana teslim ediliyordu. Yani SSRF yalnızca içeriye sızmak için değil, sunucunun taşıdığı gizli bilgileri dışarıya taşımak için de kullanılabiliyor.

Yapay zekâ ajanları da bu tablonun yeni bir parçası. Wikimedia, OpenAI’ın ajanlarının herkese açık bir aracının ayarlarını, onu başka sitelerden veri çekmek için ara sunucu olarak kullanacak şekilde değiştirmeye çalıştığını açıkladı. Bu da SSRF mantığının bir başka uygulaması: Başkasının sunucusunu kendi adına istek gönderen bir aracıya çevirmek.

Kör SSRF ve dolambaçlı yollar

Her SSRF, cevabı saldırgana geri getirmez. Bazen sunucu isteği gönderir ama cevabı göstermez. Buna kör SSRF deniyor. Kör SSRF bile işe yarayabilir: Saldırgan iç ağda hangi adreslerin ve portların açık olduğunu, isteklerin ne kadar sürede cevaplandığına bakarak haritalayabilir. Ya da iç sistemlere yalnızca istek göndermenin yettiği işlemler yaptırabilir.

Saldırganlar engelleri aşmak için de yaratıcı. Engelleme yalnızca bilinen iç adresleri metin olarak arıyorsa, aynı adresin farklı yazılış biçimleri, önce dış bir adrese gidip oradan iç adrese yönlendirme ya da bir alan adının ilk sorguda dış, ikinci sorguda iç bir adres döndürmesi gibi yollarla bu filtreler atlatılabiliyor. Bu yüzden basit bir kara liste çoğu zaman yeterli olmuyor.

Nasıl korunulur?

SSRF’de asıl mesele, sunucunun nereye gideceğine kimin karar verdiğidir. Korunmanın temeli, bu kararı mümkün olduğunca kullanıcının elinden almaktır:

• İzin listesi kullanın. Sunucunun gidebileceği adresleri önceden belirlenmiş bir listeyle sınırlayın. “Yalnızca şu birkaç güvenilir adrese gidebilirsin” demek, “kullanıcının yazdığı her adrese git, şunlar hariç” demekten çok daha güvenli.
• İç adresleri engelleyin. İç ağ adreslerine ve bulutun meta veri adresine giden istekleri açıkça engelleyin. Bu kontrolü adres metni üzerinde değil, alan adı çözüldükten sonra gerçekten bağlanılacak IP adresi üzerinde yapın.
• Yönlendirmeleri takip etmeyin. Sunucunun bir adrese gidip oradan gelen yönlendirmeyi körü körüne izlemesi, filtreleri atlatmanın en kolay yolu. Ya yönlendirmeleri kapatın ya da her adımda kontrolü yeniden yapın.
• Meta veri servisini koruyun. Bulut sunucularında meta veri servisinin korumalı sürümünü kullanın. AWS’de bu IMDSv2 olarak geçiyor ve erişim için önce özel bir belirteç alınmasını gerektiriyor, bu da sıradan bir SSRF’in işini çok zorlaştırıyor. Sunucuya verilen bulut yetkilerini de gerçekten gerekenle sınırlayın.
• Ağ düzeyinde ayırın. Dışarıdan adres alıp istek gönderen işlevleri, iç sistemlere erişimi olmayan ayrı bir ağ bölümünde çalıştırın. Böylece bir açık çıksa bile sunucu iç sistemlere ulaşamaz.
• İç servisleri de koruyun. “Nasılsa dışarıdan erişilemiyor” diye iç servisleri parolasız bırakmayın. İçeride de kimlik doğrulama, SSRF’in etkisini ciddi şekilde sınırlar.
• Giden istekleri izleyin. Sunucunun dışarıya ve içeriye yaptığı istekleri kaydedin. Bir web sunucusunun meta veri adresine ya da beklenmedik bir iç adrese gitmesi, erken bir uyarı olabilir.

Özetle SSRF, sunucunun konumundaki güveni kötüye kullanır: İçeriye erişebilen bir aracıyı, saldırganın eli hâline getirir. Sunucunun nereye gidebileceğini sıkı sıkıya sınırlamak ve içerideki sistemleri de “dışarısı” kadar ciddiye almak, bu açığın işini büyük ölçüde bitirir.