Bir Hacker Gibi Düşünmek — #12

SSRF Nedir? Bir Web Sunucusu Nasıl Başka Sistemlere İstek Göndermeye Zorlanabilir?

Bir web sitesine girdiğinde tarayıcının sunucuyla iletişim kurduğunu, sunucunun da gerektiğinde başka sunuculardan veri aldığını biliyoruz. Örneğin bir hava durumu uygulaması güncel verileri başka bir servisten alabilir, bir profil sayfası kullanıcının eklediği profil fotoğrafını farklı bir adresten indirebilir veya bir web uygulaması girilen bağlantının önizlemesini oluşturabilir. Bu işlemler oldukça sıradan görünür. Ancak uygulama, kullanıcıdan aldığı bir adresi yeterince kontrol etmeden ziyaret ederse önemli bir güvenlik problemi ortaya çıkabilir.

Bir saldırganın, web uygulamasına kendi seçtiği bir adrese istek göndertmesini düşün. Üstelik bu adres, internetten doğrudan erişilemeyen bir iç ağ servisine ait olabilir. İşte bu senaryo, web güvenliğinin önemli konularından biri olan SSRF (Server-Side Request Forgery) zafiyetinin temelini oluşturur.

Bu yazıda SSRF'nin ne olduğunu, nasıl ortaya çıktığını, saldırgan açısından neden değerli olduğunu ve bir geliştiricinin bu zafiyeti nasıl önleyebileceğini inceleyeceğiz.

SSRF tam olarak nedir?

SSRF, Türkçeye kabaca Sunucu Taraflı İstek Sahteciliği olarak çevrilebilir. Bu zafiyette saldırgan, bir web uygulamasının kendi sunucusu üzerinden istek göndermesini sağlayarak normalde erişememesi gereken kaynaklara ulaşmaya çalışır.

Buradaki en önemli ayrıntı, isteği gönderen tarafın saldırganın tarayıcısı değil, web uygulamasının sunucusudur.

Örneğin bir web uygulamasında şu özellik bulunduğunu varsayalım: Kullanıcı bir URL giriyor ve uygulama o adresteki içeriği indirerek kullanıcıya gösteriyor. Bu özellik, bağlantı önizlemesi oluşturmak veya uzaktaki bir görseli içe aktarmak için tasarlanmış olabilir.

Uygulamanın işleyişi basitçe şöyledir:

1. Kullanıcı uygulamaya bir URL gönderir.
2. Sunucu bu URL'ye HTTP isteği yapar.
3. Uzak sunucudan gelen yanıtı alır.
4. Yanıtı işler ve sonucu kullanıcıya gösterir.

Bu süreçte uygulama, girilen adresin güvenli olup olmadığını kontrol etmiyorsa kullanıcı yalnızca herkese açık bir web sitesini değil, sunucunun erişebildiği başka adresleri de hedef gösterebilir.

Önemli olan, uygulamanın gerçekten hangi adreslere erişebildiğidir. Her SSRF zafiyeti otomatik olarak iç ağa erişim, veri sızdırma veya sunucunun ele geçirilmesi anlamına gelmez. Etki, uygulamanın yetkilerine ve bulunduğu ağ ortamına bağlıdır.

Basit bir SSRF senaryosu

Bir şirketin internet sitesinde, girilen bir bağlantının başlığını ve açıklamasını otomatik olarak getiren bir özellik olduğunu düşünelim. Kullanıcı, bir blog yazısının bağlantısını girdiğinde uygulama o sayfaya istek gönderiyor ve içeriği analiz ediyor.

Normal kullanımda bu özellik oldukça kullanışlıdır. Fakat sunucu, kullanıcı tarafından gönderilen her adresi sorgulamayı kabul ediyorsa uygulamanın güvenlik sınırı yanlış çizilmiş olabilir.

Kullanıcı
   |
   | https://example.com/article
   v
Web uygulaması
   |
   | HTTP isteği
   v
Herkese açık web sitesi
Kullanıcı
   |
   | Kontrol edilmemiş URL
   v
Web uygulaması
   |
   | Sunucunun erişebildiği adrese istek
   v
İç servis / yerel servis / uzak sunucu

Kullanıcı
   |
   | https://example.com/article
   v
Web uygulaması
   |
   | HTTP isteği
   v
Herkese açık web sitesi
Kullanıcı
   |
   | Kontrol edilmemiş URL
   v
Web uygulaması
   |
   | Sunucunun erişebildiği adrese istek
   v
İç servis / yerel servis / uzak sunucu

İkinci senaryoda saldırgan, uygulamayı normalde kendisinin erişemediği bir hedefe istek göndermek için aracı olarak kullanmaya çalışır. Sunucunun iç ağdaki bir yönetim servisine erişimi varsa, bu servis internetten erişilemese bile SSRF üzerinden risk altına girebilir.

Burada şu ayrımı yapmak gerekir: SSRF, bir sunucunun mutlaka bütün iç ağlara erişebileceği anlamına gelmez. Ağ kuralları, servislerin kimlik doğrulama gereksinimleri ve uygulamanın çalışma ortamı saldırının etkisini belirler.

Saldırganlar neden SSRF ile ilgilenir?

Bir sunucu, kullanıcının bilgisayarından farklı bir ağ konumunda bulunur ve çoğu zaman farklı erişim izinlerine sahiptir. Bir saldırganın kendi bilgisayarından erişemediği bir servis, web sunucusunun bulunduğu ağdan erişilebilir olabilir.

Örneğin şirketlerin uygulama sunucuları; veritabanları, yönetim panelleri, önbellek servisleri veya yalnızca iç ağda çalışması gereken API'lerle iletişim kurabilir. Bu servisler dış dünyaya açık olmayabilir çünkü şirket bunların yalnızca kendi sistemlerinden erişilebileceğini varsaymıştır.

SSRF, bu varsayımın yanlış olduğu durumlarda devreye girer. Saldırgan uygulamaya istek göndertmeyi başarırsa bazı servislerin varlığını öğrenebilir, yanlış yapılandırılmış servislerden bilgi almaya çalışabilir veya sunucunun erişim yetkilerinden yararlanabilir.

Özellikle bulut ortamlarında ek bir risk vardır. Bazı bulut altyapılarında sanal makineye veya çalışma ortamına ait kimlik bilgileri, özel bir metadata servisi üzerinden sağlanabilir. Uygulama bu servise erişebiliyorsa ve gerekli korumalar yoksa SSRF, hassas kimlik bilgilerinin açığa çıkmasına neden olabilir. Bu durum her bulut sağlayıcısında ve her yapılandırmada aynı şekilde gerçekleşmez; kullanılan metadata mekanizmasına ve güvenlik kontrollerine bağlıdır.

Bu nedenle SSRF yalnızca "başka bir siteye istek göndermek" meselesi değildir. Asıl sorun, uygulamanın kendi ağ konumunu ve erişim yetkilerini kullanıcı girdisi üzerinden kötüye kullandırmasıdır.

SSRF nerelerde ortaya çıkar?

SSRF çoğunlukla uygulamanın bir URL'yi sunucu tarafında ziyaret ettiği özelliklerde görülür. Bağlantı önizlemesi oluşturma, uzaktaki bir görseli indirme, PDF veya belge dönüştürme, webhook tanımlama, URL üzerinden veri içe aktarma ve uzaktaki bir kaynağın durumunu kontrol etme gibi özellikler buna örnek verilebilir.

Ancak bir uygulamanın URL kabul etmesi tek başına SSRF olduğu anlamına gelmez. Önemli olan, bu URL'nin sunucu tarafından nasıl kullanıldığı ve hangi hedeflere erişmesine izin verildiğidir.

Örneğin uygulama yalnızca belirli bir görsel sağlayıcısından içerik alacak şekilde tasarlanmışsa, kullanıcının istediği herhangi bir adrese erişmek zorunda değildir. Buna rağmen geliştirici, kullanıcıdan gelen adresi doğrudan HTTP isteğine dönüştürüyorsa gereksiz bir saldırı yüzeyi oluşturmuş olabilir.

Güvenlik açısından şu soruyu sormak gerekir: Uygulamanın kullanıcı adına başka bir adrese istek göndermesi gerçekten gerekli mi? Gerekliyse bu erişim hangi hedeflerle sınırlandırılabilir?

SSRF ile CSRF arasındaki fark nedir?

Önceki yazımızda CSRF'yi, bir kullanıcının tarayıcısının kendi oturumu üzerinden istemeden işlem yapmaya yönlendirilmesi olarak incelemiştik. SSRF'de ise temel mesele, sunucunun bir isteği kullanıcının kontrol ettiği hedefe göndermesidir.

CSRF'de çoğunlukla kullanıcının tarayıcısı ve oturum yetkileri ön plandadır. SSRF'de ise uygulama sunucusunun ağ erişimi ve yetkileri önemlidir.

Benzer şekilde SSRF'yi XSS ile de karıştırmamak gerekir. XSS, bir web sayfasında saldırganın kontrol ettiği JavaScript kodunun çalıştırılmasıyla ilgilidir. SSRF ise sunucu tarafında yapılan isteklerin güvenli biçimde sınırlandırılmamasından kaynaklanır. Bazı saldırı zincirlerinde farklı zafiyetler birlikte kullanılabilir, ancak her biri ayrı bir güvenlik problemidir.

Bir geliştirici SSRF'yi nasıl önleyebilir?

SSRF'ye karşı en iyi savunma, uygulamanın ihtiyaç duymadığı hedeflere istek göndermesini engellemektir. Bir uygulama yalnızca belirli servislerden veri alacaksa kullanıcıya serbestçe herhangi bir URL belirtme imkânı vermek yerine izin verilen servisleri açıkça tanımlamak daha güvenlidir.

Örneğin bir uygulamanın yalnızca api.example.com adresinden veri alması gerekiyorsa, hedefi bu alan adıyla sınırlandırmak iyi bir başlangıçtır. Ancak yalnızca metin olarak alan adını kontrol etmek yeterli olmayabilir. URL ayrıştırma hataları, beklenmeyen bağlantı noktaları, farklı IP adreslerine çözümlenen alan adları ve yönlendirmeler kontrollerin aşılmasına neden olabilir.

Bu yüzden güvenli bir uygulama, URL'nin şemasını ve hedefini doğrulamalı; alan adını DNS üzerinden çözdüğünde elde edilen IP adreslerini de politikasına göre kontrol etmelidir. Yerel makineye, özel iç ağlara ve bağlantı-yerel adreslere giden istekler, uygulamanın iş gereksinimleri açıkça izin vermediği sürece engellenmelidir. Yönlendirme takip ediliyorsa her yeni hedef yeniden doğrulanmalıdır. İlk URL güvenli görünse bile sunucu, yönlendirme sonucunda farklı bir adrese ulaşabilir.

Bir diğer önemli önlem, sunucunun ağ erişimini sınırlamaktır. Uygulamanın internete istek göndermesi gerekiyorsa bu, tüm iç ağlara erişebilmesi gerektiği anlamına gelmez. Ağ seviyesindeki çıkış kuralları, uygulamanın yalnızca ihtiyaç duyduğu hedeflere ulaşmasına izin verebilir. Böylece uygulama kodunda bir hata olsa bile olası etkinin sınırlandırılması mümkün olur.

Bulut sistemlerinde metadata servislerine erişim ayrıca korunmalıdır. Kullanılan platformun desteklediği güvenlik mekanizmaları etkinleştirilmeli, hassas kimlik bilgileri mümkün olduğunca dar yetkilerle verilmelidir. Çünkü bir SSRF zafiyetiyle bu bilgilere ulaşılması durumunda, elde edilen yetkiler saldırının etkisini büyütebilir.

Son olarak, kullanıcıdan alınan URL'leri doğrulamak ile sunucunun güvenliğini sağlamak birbirini tamamlayan önlemlerdir. Girdi doğrulaması, ağ kısıtlamaları, güvenli yönlendirme yönetimi, kimlik bilgilerini koruma ve uygun günlükleme birlikte düşünülmelidir.

Güvenli bir test ortamında SSRF mantığını nasıl gözlemleyebilirsin?

SSRF'yi öğrenmek için gerçek sistemlere istek göndermek veya internetteki servisleri denemek gerekmez. Kendi bilgisayarında çalışan basit bir test uygulaması ya da SSRF için hazırlanmış bir eğitim laboratuvarı, konuyu anlamak için yeterlidir.

Örneğin yalnızca kendi bilgisayarında çalışan bir uygulamanın bir URL alıp sunucu tarafında o adrese istek gönderdiğini gözlemleyebilirsin. Ardından uygulamanın hangi hedeflere erişmesi gerektiğini belirleyip izin verilen ve verilmeyen adresleri ayırt eden kontroller ekleyebilirsin. Test sırasında sunucunun günlüklerini incelemek, isteğin tarayıcıdan mı yoksa uygulama sunucusundan mı çıktığını anlamana yardımcı olur.

Bu konuda PortSwigger Web Security Academy içindeki SSRF eğitimleri, konuyu kontrollü bir ortamda öğrenmek için yararlı bir kaynaktır. Laboratuvarları yalnızca belirtilen eğitim ortamında çalıştırmak ve gerçek sistemlerde izinsiz test yapmamak gerekir.

Sonuç: Bir isteğin nereden gönderildiği önemlidir

Bir web uygulamasının başka bir sunucuya istek göndermesi normaldir. Güvenlik problemi, bu davranışın kullanıcı girdisiyle kontrol edilebilir hâle gelmesi ve erişilebilecek hedeflerin yeterince sınırlandırılmamasıyla ortaya çıkar.

SSRF bize önemli bir güvenlik prensibini hatırlatır: Bir kullanıcının uygulamaya veri gönderebilmesi, uygulamanın bu veriye dayanarak sınırsız ağ erişimi sağlaması gerektiği anlamına gelmez. Sunucunun erişebildiği her kaynak, uygulamanın güvenlik tasarımında değerlendirilmelidir.

Bir hacker gibi düşünmek, yalnızca dışarıdan görünen web sayfasına bakmak değildir. Bazen asıl risk, sunucunun arka planda kiminle iletişim kurabildiğini ve bu iletişimin ne kadar kontrol edildiğini anlamakta yatar.