SSRF101: Sunucu Taraflı İstek Sahteciliği Nedir ve Nasıl İstismar Edilir?

Merhaba. Bu yazıda SSRF zafiyetinin ne olduğunu, nasıl tespit edilebileceğini ve iki laboratuvar örneği üzerinden nasıl çalıştığını adım adım anlatacağım.

Önce temel işleyişe bakalım. Bir kullanıcı tarayıcısı üzerinden web sitesine eriştiğinde, tarayıcı sunucuya bir HTTP isteği gönderir. Sunucu isteği işler ve tarayıcıya bir HTTP yanıtı döndürür.

Ancak web sunucuları yalnızca kullanıcılardan gelen isteklere yanıt vermez. Bazı durumlarda başka sunuculara veya servislere de kendileri istek gönderir. Örneğin bir uygulama başka bir API'den veri alabilir, kullanıcının verdiği URL'deki resmi indirebilir ya da harici bir servisten içerik çekebilir.

Buradaki önemli ayrıntı şu: İsteği her zaman kullanıcının tarayıcısı göndermez. Bazı istekleri doğrudan web uygulamasının çalıştığı sunucu gerçekleştirir.

Uygulama, sunucunun hangi adrese istek göndereceğini kullanıcı girdisine göre belirliyor ve bu girdiyi yeterince doğrulamıyorsa güvenlik riski oluşabilir. Sunucu Taraflı İstek Sahteciliği (Server-Side Request Forgery, SSRF) zafiyeti bu noktada ortaya çıkar.

Bu işleyişi özetleyen bir şema aşağıda yer alıyor.

Kısaca SSRF, bir saldırganın web uygulamasını kullanarak sunucuya istenmeyen bir adrese istek göndertmesiyle ortaya çıkan zafiyettir. Bu adres, sunucunun kendisi, iç ağdaki bir servis veya uygulamanın normalde erişmemesi gereken harici bir sistem olabilir.

Yukarıdaki şemada uygulama, stok bilgisini almak için kullanıcıdan bir URL alıyor. Beklenen istek şu şekilde:

http://website.thm/stock?url=http://api.website.thm/api/stock/item?id=123

Kullanıcı, website.thm üzerindeki stok kontrol özelliğini kullanıyor. Ancak stok bilgisini ana site tutmuyor; arka plandaki API'den alıyor.

Şemada kırmızıyla gösterilen bölüm kullanıcı tarafından kontrol ediliyor.

Saldırgan, yalnızca item?id=123 bölümünü değil, uygulamanın istek göndereceği URL'nin tamamını değiştirebiliyorsa istek şu hale gelebilir:

http://website.thm/stock?url=http://api.website.thm/api/user

Bu durumda API, kullanıcı bilgilerini içeren yanıtı ana web sitesine döndürür; uygulama da bu yanıtı saldırgana gösterirse hassas bilgiler açığa çıkabilir.

Temel mantık bu şekilde özetlenebilir. Örnekte hedef, api.website.thm üzerindeki /api/user uç noktasıdır (endpoint). Ancak hedefin başka bir API uç noktası olması şart değildir. Uygulamanın yapısına ve sunucunun ağ erişimine bağlı olarak istek localhost'a, iç ağdaki sistemlere veya başka bir adrese yönlendirilebilir.

Bu örneklerden hareketle, SSRF'nin sık karşılaşılan iki kullanım senaryosunu inceleyelim.

1. Sunucunun Kendisine Yönelik SSRF

Bu senaryoda saldırgan, web uygulamasının kendi sunucusuna istek göndermesini sağlar. Bunun için çoğunlukla localhost veya 127.0.0.1 gibi loopback adresleri hedeflenir. Ancak hangi adresin kullanılacağı, uygulamanın ve sunucu ortamının yapılandırmasına bağlıdır.

Bu senaryoyu bir lab üzerinden inceleyelim.

Bir e-ticaret sitesindeyiz. Ürün sayfalarından birinde "Check stock" (stok kontrolü) seçeneği bulunuyor.

Uygulamayı incelerken, dış kaynaklarla veya kendi iç sistemleriyle iletişim kurduğu noktaları belirlemek gerekir. Ürün sayfasındaki "Check stock" butonu bu tür bir etkileşim noktasıdır.

Butona basıldığında oluşan isteği Burp Suite içindeki Repeater aracına gönderip stockApi parametresini inceleyelim:

Bu parametre uygulamanın bir URL alıp o adrese sunucu tarafından istek gönderdiğini gösteriyor. Hedef adres yeterince doğrulanmıyorsa, istek sunucunun kendi üzerinde çalışan ve normalde dışarıdan erişilemeyen bir panele yönlendirilebilir.

İsteği gönderdiğimizde yanıt olarak 200 OK durum kodunu görüyoruz. Bu kod, isteğin başarılı bir HTTP yanıtı aldığını gösterir; tek başına bir güvenlik açığını kanıtlamaz. Lab bağlamında, yanıtın içeriği hedef panele erişildiğini doğrulamaya yardımcı olur.

Labın hedefi olan admin paneline eriştikten sonra, yönergelerde istenen Carlos kullanıcısını silebiliriz.

2. Arka Uç Sistemlere Yönelik SSRF

Bir diğer yaygın senaryo, web sunucusunun bulunduğu iç ağdaki sistemlere istek gönderilmesidir. Kurum ağlarında yönetim panelleri, veritabanları ve backend servisleri çoğu zaman doğrudan internete açık değildir; bunlara yalnızca belirli ağlardan erişim izni verilmiş olabilir.

SSRF açığı bulunan bir uygulamada saldırgan, sunucunun göndereceği isteğin hedefini değiştirebilir. Böylece sunucu, 192.168.x.x, 10.x.x.x veya 172.16.x.x–172.31.x.x aralığındaki özel IPv4 adreslerinde çalışan servislere istek göndermeye zorlanabilir. Bu adres aralıklarının özel olması, tek başına hedefte mutlaka bir servis bulunduğu anlamına gelmez.

Bunu benzer yapıya sahip ikinci labda inceleyelim.

Aynı adımları uygulayıp Repeater'da stockApi parametresini incelediğimizde, uygulamanın stok bilgisini alırken belirli bir iç ağ IP adresine istek gönderdiğini görüyoruz.

Amacımız yine Carlos kullanıcısını silmek. Admin panelinin hangi IP adresinde olduğunu bilmediğimiz için labdaki Intruder aracıyla belirli bir aralıktaki adresleri kontrollü biçimde test ediyoruz.

192.168.0.225 adresine gönderilen isteğin 200 OK yanıtı verdiğini görüyoruz. Lab bağlamında bu yanıt, admin panelinin bu adreste bulunabileceğine işaret ediyor. Ardından önceki bölümdeki adımlar izlenebilir.

Gerçek sistemler genellikle lab örneklerinden daha karmaşıktır. Yönetim panellerinde kimlik doğrulama ve yetkilendirme kontrolleri bulunabilir; ayrıca işlemlere göre CSRF token'ı veya başka güvenlik kontrolleri uygulanabilir.

Yine de iç ağdaki bir yönetim panelinin mutlaka kimlik doğrulamayla korunduğunu varsaymak doğru değildir. SSRF'nin tehlikesi, bazı iç servislerin güvenlik kontrollerinin zayıf olması veya sunucudan gelen isteklere gereğinden fazla güvenmesidir.

Ayrıca kullanıcı silme gibi durum değiştiren işlemlerin her sistemde aynı HTTP yöntemiyle yapıldığını söyleyemeyiz. Güvenli tasarımda bu tür işlemler uygun yetkilendirme kontrolleriyle korunmalı; yalnızca GET isteğine veya ağ içinden gelmeye güvenilmemelidir.

Bazı durumlarda uygulama, hedef sistemden aldığı yanıtı kullanıcıya göstermez. Bu tür durumlar Blind SSRF olarak adlandırılır ve tespit edilmeleri daha zor olabilir.

Blind SSRF Nedir?

Şimdiye kadarki örneklerde sunucunun yaptığı isteğin sonucunu doğrudan görebildiğimizi varsaydık. Ancak her SSRF açığında yanıt kullanıcıya gösterilmez. Uygulama, kullanıcının verdiği adrese arka planda istek gönderse bile hedef sistemden dönen yanıtı gizleyebilir veya hiç yansıtmayabilir.

Örneğin uygulama bir URL'ye sunucu tarafından istek gönderiyor olabilir; ancak hedef sistemin yanıt gövdesi kullanıcıya iletilmez. Bu durumda yalnızca sayfada görünen yanıta bakarak isteğin gerçekleşip gerçekleşmediğini anlamak mümkün olmayabilir.

Bu nedenle Blind SSRF'yi tespit etmek daha zor olabilir. Yetkili güvenlik testlerinde, kontrollü bir test alan adı veya etkileşim izleme servisi üzerinden DNS ya da HTTP bağlantıları takip edilerek sunucunun hedefe ulaşıp ulaşmadığı doğrulanabilir. DNS sorgusunun görülmesi, tek başına hedef uygulamanın tüm isteği başarıyla tamamladığını kanıtlamaz.

SSRF'nin farklı biçimlerde ortaya çıkabilmesi, kullanıcı tarafından verilen adreslerin nasıl doğrulanması gerektiği sorusunu da beraberinde getirir.

SSRF Nasıl Tespit Edilir?

Bir uygulamada SSRF olup olmadığını araştırırken, öncelikle sunucu tarafında başka bir adrese istek gönderilen işlevler incelenir. Kullanıcının URL, IP adresi veya hostname belirleyebildiği alanlar özellikle dikkat çekicidir.

Örneğin şu tür parametreler incelenebilir:

url=https://example.com

imageUrl=https://example.com/image.png

webhook=https://example.com/callback

stockApi=https://example.com/product/1

url=https://example.com

imageUrl=https://example.com/image.png

webhook=https://example.com/callback

stockApi=https://example.com/product/1

Burada önemli olan, isteği tarayıcının mı yoksa uygulamanın backend sunucusunun mu gönderdiğidir.

İsteği backend sunucusu gerçekleştiriyor ve kullanıcı hedef adresi etkileyebiliyorsa SSRF riski söz konusu olabilir. Yine de parametrenin URL içermesi tek başına zafiyet bulunduğunu göstermez.

Test sırasında, yalnızca izin verilen laboratuvar veya test ortamında, hedef adres kontrollü biçimde değiştirilerek uygulamanın davranışı gözlemlenir. Yanıt süresi, hata mesajları veya HTTP durum kodlarındaki farklılıklar sunucunun bağlantı kurmaya çalıştığına dair ipucu olabilir; ancak bunlar tek başına kesin kanıt değildir.

Bir SSRF bulgusunu doğrulamak için sunucunun kullanıcı girdisiyle belirlenen hedefe gerçekten istek gönderdiğine dair yeterli kanıt gerekir. Testler yalnızca açıkça izin verilen sistemlerde yapılmalıdır.

SSRF Saldırılarına Karşı Nasıl Önlem Alınabilir?

SSRF'nin temelinde çoğu zaman, uygulamanın kullanıcıdan aldığı bir URL'yi veya adresi yeterince doğrulamadan sunucu tarafında kullanması bulunur. Bu nedenle savunmanın temel parçalarından biri, sunucunun hangi hedeflere erişebileceğini sınırlandırmaktır.

Bu konuda iki yaklaşım sıkça anlatılır: blacklist (engelleme listesi) ve whitelist (izin listesi).

Blacklist yaklaşımında, tehlikeli olduğu düşünülen adresler veya adres aralıkları engellenir.

Örneğin uygulama aşağıdaki adreslere veya aralıklara erişimi engelleyebilir:

127.0.0.1

localhost

192.168.0.0/16

10.0.0.0/8

127.0.0.1

localhost

192.168.0.0/16

10.0.0.0/8

Ancak blacklist yaklaşımının temel sorunu, saldırganın kullanabileceği bütün alternatif gösterimleri ve yönlendirme yollarını önceden belirlemenin zor olmasıdır.

Bu nedenle blacklist tek başına güvenilir bir koruma olarak görülmemelidir.

Örneğin uygulama yalnızca "127.0.0.1" metnini engelliyorsa, bazı URL ayrıştırıcıları aynı adresin alternatif gösterimlerini de kabul edebilir:

2130706433

017700000001

127.1

2130706433

017700000001

127.1

Uygulama IP adreslerini engelliyor ancak alan adlarına izin veriyor olabilir.

Bu durumda saldırganın kontrol ettiği bir alan adı localhost adresine çözümlenebilir. Ayrıca yönlendirmeler veya DNS çözümlemesindeki değişiklikler de yalnızca ilk URL'yi kontrol eden filtrelerin atlatılmasına yol açabilir.

Whitelist yaklaşımında ise uygulama yalnızca önceden belirlenmiş ve güvenilir hedeflere istek gönderilmesine izin verir.

Örneğin uygulamanın yalnızca api.example.com adresine istek göndermesi gerekiyorsa, kullanıcı girdisinin gerçekten bu izinli hedefe karşılık geldiği doğrulanmalıdır. Yalnızca metnin bu alan adını içerip içermediğine bakmak yeterli değildir.

SSRF açısından whitelist genellikle daha güçlü bir başlangıç noktasıdır; çünkü izin verilen hedefleri baştan sınırlar. Ancak doğru URL ayrıştırma, DNS çözümlemesi ve bağlantı sırasında hedef IP'nin kontrolü gibi ek önlemler de gerekir.

Whitelist kontrolü URL'nin gerçek hostname bilgisini güvenilir bir URL ayrıştırıcısıyla doğrulamak yerine basit metinsel karşılaştırmalarla yapılırsa, URL'nin yapısı bu kontrolün yanlış sonuç vermesine neden olabilir.

Örnek olarak:

https://expected-host:fakepassword@evil-host

https://expected-host:fakepassword@evil-host

Bu URL ilk bakışta expected-host adresine gidiyormuş gibi görünebilir. Ancak URL kurallarına göre @ karakterinden önceki bölüm kullanıcı bilgisi (userinfo) olarak yorumlanır.

Bu örnekte expected-host kullanıcı adı, fakepassword parola; gerçek hostname ise evil-host'tur. Dolayısıyla bağlantı evil-host adresine kurulur.

Buradaki sorun whitelist yaklaşımının kendisi değil, izin kontrolünün hatalı uygulanmasıdır.

Blacklist ve whitelist yöntemlerinin hiçbiri tek başına her senaryoda tam koruma sağlamaz. URL ayrıştırma kütüphaneleri kullanılmalı; izin verilen şema, hostname, port ve çözümlenen IP adresi kontrol edilmeli; yönlendirmeler doğrulanmalı veya gerekmiyorsa kapatılmalı; ağ seviyesinde de erişim sınırlandırılmalıdır.

Gerçek Hayatta SSRF Neden Tehlikelidir?

Bu yazıda SSRF'yi basit örneklerle ele aldık. Gerçek sistemlerde riskin boyutunu, uygulama sunucusunun hangi kaynaklara erişebildiği ve bu kaynakların hangi hassas verileri ya da işlemleri sunduğu belirler.

SSRF, özellikle bulut ortamlarında ciddi sonuçlara yol açabilir. Bulut sunucuları, altyapı servisleriyle ve kimlik bilgileri sağlayabilen metadata servisleriyle iletişim kurabilir. Bir saldırgan, zafiyet üzerinden bu servislere erişim sağlamaya çalışarak hassas bilgiler veya erişim belirteçleri elde etmeyi deneyebilir. Sonuç, bulut sağlayıcısına ve yapılandırmaya bağlıdır.

SSRF'deki asıl tehlike, saldırganın yalnızca farklı bir URL yazabilmesi değil, uygulama sunucusunun sahip olduğu ağ erişimini kötüye kullanabilmesidir. Bu nedenle kullanıcı kontrollü adresler dikkatle doğrulanmalı, sunucunun erişebileceği hedefler sınırlandırılmalı ve gereksiz iç ağ erişimleri ağ seviyesinde engellenmelidir.

KAYNAKÇA:

https://portswigger.net/web-security/ssrf

https://tryhackme.com/room/ssrfqi

https://owasp.org/www-community/attacks/Server_Side_Request_Forgery

https://www.youtube.com/watch?v=2ONduwyqYUA&t=5537s