Merhaba,


Server Site Request Forgery yani kısa adı ile SSRF, Sunucu Taraflı İstek Sahteciliği olarak dilimize çevrilebilir. Sunucu Taraflı İstek Sahteciliği veya SSRF, saldırganın sunucuyu kendisi adına istekte bulunmaya zorlayan bir güvenlik açığıdır. Daha açık ifade edecek olursak web uygulamaları, genellikle yazılım güncellemeleri gibi uzak kaynakları almak veya bir URL’den ya da diğer web uygulamalarından içeri veri aktarmak için denenen sunucular arası istekleri tetikleyebilir. Bu tür sunucular arası istekler, genelde güvenli olsa da implementasyon doğru yapılmadığı takdirde SSRF zafiyetine yol açabilirler. SSRF, saldırgana bu güvenlik açığı bulunan sunucudan istek oluşturması veya buradan gelen istekleri kontrol edebilmesi için web uygulamasındaki bir parametreyi değiştirmesine izin vermektedir.
  • IP kontrolünü atlatabilir.
  • Zafiyeti barındıran sunucu ile diğerleri arasındaki güven ilişkisini kötüye kullanabilir.
  • Host tabanlı kimlik doğrulama servislerini atlatabilir.
  • ASP.NET’te trace.axd veya AWS ortamında metadata API’leri gibi herkese açık olmayan kaynakları okuyabilir.
  • Sunucuya bağlı olan yerel ağı tarayabilir.
  • Hostname’in sonuna nokta koyarak blacklist bypass edebilir.
  • Sunucuda bulunan dosyaları okuyabilir.
  • Status Pages (Durum Sayfaları)'i görüntüleyebilir ve API'larla kurulan etkileşimde, zafiyetin bulunduğu web sunucusunun yerine geçebilir.
  • Bir reverse proxy'nin ardındaki web sunucusunun IP adresi gibi hassas bilgileri alabilir. Örneğin Cloudflare benzeri dns kullanan bir sitenin gerçek ip adresini öğrenebilir.
Eğer http:// veya https:// yerine file:// kullanırsak yerel dosya sisteminden dosyaları okuyabiliriz. Örneğin file:///et.c/pass.wd kullanırsak (noktaları kaldırın) unix sistemlerindeki passwd dosyasının içeriğini sayfaya yazdırabiliriz. Aynı teknik zafiyet bulunan web uygulamasının kaynak kodunu görmek için de kullanılabilir.



SSRF saldırıları kullanarak şunları yapmak mümkündür ;






Server Side Request Forgery (SSRF) Açığnı Önleme

SSRF açıklarını önlemek için, web sunucusunun uzak kaynakları çağırmasına olanak verilen domainler ve protokoller için whitelist yöntemi uygulamanız tavsiye edilmektedir. Ayrıca, bir kural olarak kullanıcı girdisini sunucu adına istekte bulunabilecek işlevlerde doğrudan kullanmamalısınız. Ayrıca kullanıcı girdilerini sanitize etmelisiniz ve filtrelemelisiniz. Ancak genellikle farklı senaryoları kapsamak imkânsız olduğu için pratikte bunu uygulamak zordur.

DNS Çözümleme ve Whitelist Oluşturma

SSRF tehtidini önlemenin en sağlam yolu, uygulamanızın erişmesi gereken DNS adını veya IP adresini whitelist yöntemiyle erişime açmaktır. Whitelist yaklaşımı size uymuyorsa mecburen bir blacklist oluşturup güvenmediğiniz IP adreslerini tutabilirsiniz. Burada önemli olan kullanıcı erişimini doğrulamaktır.
Blacklist yöntemi için sayısız ihtimali azaltma yolu olarak da düşünebiliriz. SSRF için evrensel bir önleme metodu olmadığı için mecburiyet halinde kullanılmalıdır.

Kullanılmayan URL Şemalarını Devre Dışı Bırakma

Uygulamanız istekte bulunmak için yalnızca HTTP veya HTTPS kullanıyorsa, yalnızca bu URL şemalarına izin verin. Kullanılmayan URL şemalarını devre dışı bırakırsanız, saldırgan, file://, dict://, ftp:// ve gopher:// gibi tehlikeli şemalar kullanarak istekte bulunmak için web uygulamasını kullanamaz.

İç Ağda Bulunan Servislere Erişim İçin Kimlik Doğrulama

Varsayılan olarak, Memcached, Redis, Elasticsearch ve MongoDB gibi servislerin onaylanması gerekmez. Saldırgan, bu hizmetlere kimlik doğrulaması yapmadan erişebilir. Bu nedenle yerel ağdaki hizmetler için mümkün olduğunca kimlik doğrulamasını etkinleştirmek gerekmektedir.

Sunucu Taraflı Yanıt Kontrolü (Response Handling)

Saldırganların SSRF ile sunucudan sömürü amaçlı aldığı yanıtlar normalden farklı olacaktır. Sunucudan gönderilen yanıtların veya isteklerin kontrol edilip çıktığı gibi iletilmemesi gerekmektedir. Aksi takdirde SSRF ile verilen yanıtlar saldırganın isteğine göre kontrolsüz şekilde gidecektir.