Server Side Request Forgery ya da bilinen adıyla SSRF daha sık web tarafında rastlanan ciddi bir güvenlik açığıdır.
Nasıl çalışır?
Sunucu tarafı istek sahteciliği olarak çevriliyor ama benim tavsiyem ingilizce karşılığını bilmeniz. En temelde sunucunun kendi yaptığı http isteklerini kendi isteğimiz doğrultusunda değiştirmemizi sağlıyor. Ve sunucu adına istek yapabiliyoruz. Hadi örneklerle inceleyelim.
Diyelim ki https://developerrabbit.xyz adlı bir web sitemiz var. Bu site kedi resimlerinin yayınladığı bir blog olsun. Oldukça basit bir site. Bu resimleri kendi statik olarak da sunabilir veya Third-Party bir sunucudan da isteyebilir. Bu sunucu herhangi bir site olabilir. Diyelim ki bu senaryoda kedi resimlerimiz uzak bir sunucundan geliyor ve istek aynen şöyle gerçekleşiyor.
Siz bir resime tıkladığınızda
developerrabbit.xyz?getImage=https://cute.cat.photos?id=5
cute.cat.photos adlı siteden istediğimiz resim bize geliyor ve bu isteği server yani developerrabbit adlı sitemiz getImage adlı parametremizle gerçekleştiriyor. Eğer burada getImage parametresi server tarafında gerekli kontroller yapılmadan direk kullanılıyor ise burada SSRF zaafiyetinden bahsetmemiz oldukça mümkün. Peki burada SSRF olduğunu nasıl anlayacağız? Çok basit getImage parametresini kendi isteğimiz doğrultusunda değiştirecez. Bunu bir örnekle anlatalım.
Diyelim ki böyle basit bir web sitemiz var. Ürünler listelenmiş ve her birine tıklayıp detayları görebiliyoruz. Birine tıklayalım ve ürün sayfasını görelim.
Gayet hoş. Ürünün açıklaması ve bir de ne görelim Check stock adlı bir özelliğimiz var.
Buradan bu ürünün hangi ülkede ne kadar bulunduğunu görebiliyoruz.
Hadi burp suite adlı programımızı başlatalım ve arkada nasıl bir istek gerçekleştiğini görelim. Burp nedir diyenler için temelde web taracıyımızdan örneğin Chrome’den çıkan bütün http requestleri görmemizi ve bu istekleri manipule etmemizi sağlayan bir program. Devam edelim. Burp Suite’miz açık ve bakalım Milan da bu üründen kaç tane varmış.
Milan seçip check stock dediğimizde web sitesi /product/stock yoluna bir POST isteği atıyor. Ve bu isteğin gövdesinde stockApi adlı bir değişkenimiz var. Değişkenimizi inceliyelim.
stockApi=http%3A%2F%2Fstock.weliketoshop.net%3A8080%2Fproduct%2Fstock%2Fcheck%3FproductId%3D2%26storeId%3D3
Url-encode edilmiş daha net görelim ve url-decode edelim.
stockApi=http://stock.weliketoshop.net:8080/product/stock/check?productId=2&storeId=3
Gördüğünüz üzere web sitemiz başka bir site üzerinden stok kontrolü yapıyor. Hadi işleri tehlikeli bir hale getirelim. Tabii ki karşı taraf için :) stockApi adlı parametrenin SSRF zaafiyetine karşı korunmasız olduğunu düşünelim ve değişkenimizi http://localhost:80 olarak değiştirelim bakalım ne olacak.
Server tarafında localhost:80 portunda aynı son kullanıcınında görebildiği gibi alışveriş sitemiz çalışıyor. Ama bir farkla Admin panelimiz var :) İşte bu riskli ve SSRF olduğunun kanıtı. Server tarafında çalışan bir servise erişim sağladık.
Daha neler yapabiliriz. Server tarafında port taraması yapabilir ve çalışan tüm servislere erişebiliriz. Server’daki normalde görmememiz gereken bilgilere erişebiliriz. Örneğin burda localhost:80/admin diyerek admin sayfasına erişebilmemiz gibi. Normalde bizim tarayıcımız tarafından erişemediğimiz sadece sunucunun erişebildiği web sitelerine erişebiliriz ve daha nicesi.
Gördüğünüz üzere SSRF ciddi bir gücenlik açığı.
Peki nasıl korunacaz?
Parametleri kontrol ettirerek tabi. En basitinden burada stockApi adlı değişkenimizi localhost yazıldığında isteğin gitmesini engellemek gibi. Kendimize bir karaliste (blacklist) oluşturarak nelerin engelleceğini kontrol edebiliriz. Ya da bir beyazliste (whitelist) oluşturarak nelerin kabul edileceğini söyleriz. Örneğin sadece abc.com adlı siteye git gibi.
Sonuç
SSRF’in ne olduğunu, nelerden kaynaklandığını ve nasıl korunacağımıza temel düzeyde değindik.
Bir sonraki yazımızda görüşmek üzere hoşçakalın :)
