Server Side Request Forgery (SSRF) Nedir? Nasıl Önlem Alınır?

Web uygulamaları, genellikle yazılım güncellemeleri gibi uzak kaynakları almak veya bir URL’den ya da diğer web uygulamalarından içeriye veri aktarmak için yapılan 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’e Giriş

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 verir.

Farklı bir web sitesinden RSS akışı yüklemede olduğu gibi, web uygulamasındaki bilgilerin harici bir kaynaktan alınması zorunlu kılındığında, sunucu tarafından yapılan istekler ilgili kaynağı çekmek ve web uygulamasına dahil etmek için kullanılır. Örneğin bir geliştirici başka bir kaynaktaki akışı almak için https://example.com/feed.php?url=externalsite.com/feed/ gibi bir URL kullanabilir. Saldırgan URL parametresini localhost olarak değiştirebilirse, sunucu üzerindeki yerel kaynakları görüntüleyebilir ve sunucuda bir Server Side Request Forgery zafiyeti meydana getirebilir.

Eğer bir saldırgan sunucu isteklerinin varış yerini kontrol edebiliyorsa muhtemelen aşağıdaki eylemleri de gerçekleştirebilmektedir:

• Zafiyeti barındıran sunucu ile diğerleri arasındaki güven ilişkisini kötüye kullanabilir.
• IP kontrolünü atlatabilir.
• 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.
• 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 kullanan bir sitenin gerçek ip adresini öğrenebilir.

Bir SSRF Zafiyetinin Kullanımı

Saldırgan, güvenlik duvarı tarafından engellenmesi nedeniyle kurbanın sunucusuna direkt istekler gönderemediğinden bir iç ağı taramak için şunları yapmalıdır:

1. SSRF zafiyetini kötüye kullanan bir isteği güvenlik açığı bulunan web sunucusuna göndermelidir.
2. Web sunucusu, güvenlik duvarının arkasındaki kurbanın sunucusuna bir istek yapar.
3. Kurbanın sunucusu veriyle cevap verir.
4. Eğer SSRF açığı buna izin veriyorsa, veri saldırgana geri gönderilir.

SSRF Zafiyetinin Yansımaları

1. Etkilenen sunucuya duyulan güvenin kötüye kullanımı

En iyi yöntem olarak, saldırı yüzeyini mümkün olduğu kadar küçük tutmak her zaman daha iyidir, bu nedenle belirli portlara veya eylemlere erişim genellikle, sadece whitelist’e alınmış makinelerle sınırlandırılmaktadır. Aslında sunucular, verileri kolayca paylaşmak ve yönetimsel görevlere izin vermek için genellikle diğer makinelerle güven ilişkisine sahiptir.

Örneğin ağ seviyesinde güven şu anlama gelir: Bir güvenlik duvarı, eğer erişim talep eden makine aynı yerel ağda bulunuyorsa veya makinenin IP adresine güveniliyorsa, sadece belirli portlara erişim izni verir.

Yazılım düzeyinde güven şu şekilde olabilir: IP adresi 127.0.0.1 olduğu sürece veya yerel ağın içindeyse, bazı yönetimsel görevler için kimlik doğrulama gerekli değildir. Bu tür bir güven, bir saldırganın parolayı bildiği halde yerel ağa erişim olmadan giriş yapamamasını sağlamak için ek bir güvenlik önlemi olarak da kullanılabilir.

Saldırgan, SSRF’ten yararlanarak yukarıdaki kısıtlamaları atlatabilir ve örneğin; etkilenen makineye güvenen diğer sunucuları sorgulayabilir veya dış ağdan erişilemeyen bazı portlarla etkileşim kurmak için kötü amaçlı isteklerde bulunabilir. Saldırgan, bu şekilde dışarıdan yapılması mümkün olmayan kötü amaçlı eylemleri sunucunun kendisini kullanarak sunucu üzerinde gerçekleştirebilir

2. Yerel veya Harici Ağların Taranması

Saldırganlar, SSRF güvenlik açığından yararlanarak, güvenlik açığı bulunan sunucunun bağlı olduğu yerel veya harici ağları tarayabilir. Saldırganlar genellikle bir sayfanın yüklenme süresini, sayfadaki hata mesajını veya hedefledikleri araştırmadan cevap alıp alamadıklarını belirlemek ve test edilen portun açık olup olmadığını doğrulamak için sorguladıkları banner bilgisini kullanırlar.

Bir Ağın SSRF Zafiyeti Kullanılarak Nasıl Taranacağına Dair Örnek

Uzak kaynaktan jpeg formatında resim çağırmanıza izin veren ve bu işlem sırasında resimlerin boyutlarını belirleyebilen bir web servisi hayal edin.

Önlem olarak, servis uzak kaynaktan gelen istekte "image/jpeg" değerine sahip bir Content-Type headerı olup olmadığını denetler. Eğer Content-Type başlık alanı değeri “image/jpeg” değilse veya içerik tipi farklıysa, dosyanın jpeg olmadığını varsayarak “Sadece jpeg imajları kabul edilmektedir” şeklinde bir hata döndürür. Bunun haricinde, uzaktaki kaynağa bağlanmada bir problem varsa, "Resim bulunamadı!" hatası döndürülür.

Saldırganların host’un ayakta olup olmadığını anlamak için web servisinin yanıtını etkileyen nasıl farklı inputlar kullanabildiğine bakalım.

https://victim.com/image.php?url=https://example.com/picture.jpg şeklinde istekte bulunursak cevap olarak resmin yüksekliğini ve genişliğini alırız. Ki bu, Content-Type header’ı doğru olan geçerli bir resim olduğu anlamına gelir.

Şimdi farklı bir istekte bulunmayı deneyelim ve sunucuya yaptığımız istekte resim yerine bir HTML dosyası gönderelim: https://victim.com/image.php?url=https://example.com/index.html Bu durumda yüklenen sayfanın Content-Type header’ı “text/html” olduğundan servisin cevabı “Sadece jpeg imajları kabul edilmektedir” olur.

Şimdi geçersiz bir URL ile istekte bulunalım; https://victim.com/image.php?url=https://example.invalid/ Servis “Resim bulunamadı” hatasının döndürür. Bunun anlamı uzak kaynak alınırken bir hata oluştuğudur.

Artık uygulamanın farklı girdiler için nasıl davrandığını bildiğimizden kötüye kullanmayı deneyebiliriz. Yanlış veya eksik Content-Type header’ı olan geçerli bir URL'in “Sadece jpeg imajları kabul edilmektedir” hatasını döndürdüğünü biliyoruz. Bunun anlamı aşağıdaki isteği gönderirsek;

https://victim.com/image.php?url=127.0.0.1:3306

Ve “Resim bulunamadı” hatası alırsak, bunun anlamı 127.0.0.1 port 3306’da yanıt yok demektir. Eğer “Sadece jpeg imajları kabul edilmektedir” hatasını alırsak sunucudan gelen bir yanıtın olduğunu dolayısıyla söz konusu port üzerinde bir servisin çalıştığını anlayabiliriz. Bundan dolayı bu metodu, tam bir tarama yapma amacıyla farklı dahili IP adreslerini ve portlarını sorgulamak için kullanabiliriz.

3. Sunucudan Dosyaların Okunması

Uzak bir kaynağın içeriği doğrudan bir sayfaya yansıtıldığında, saldırganların dosyaların içeriğini okuma olasılığı vardır. Örnek olarak, verilen bir url'den tüm resimleri kaldıran ve metni biçimlendiren bir web servisi düşünün. İlk önce belirli bir url'nin yanıt gövdesini elde ederek çalışır, daha sonra biçimlendirmeyi uygular.

Eğer http:// veya https:// yerine file:// kullanırsak yerel dosya sisteminden dosyaları okuyabiliriz. Örneğin file:///etc/passwd kullanırsak 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 Zafiyetinin Etkileri

Yukarıdaki örneklerde görüldüğü üzere bir SSRF zafiyeti ,neredeyse her zaman, aşağıda listelenen türde bilgi ifşalarına neden olur:

1. Portları ve IP adreslerini taramaya imkan verir.
2. Daha fazla keşif yapmanıza izin veren Gopher gibi bazı protokollerle etkileşime izin verir.
3. Bir reverse proxy’nin arkasındaki sunucuların IP adreslerini tespit edebilir.
4. Uzaktan kod çalıştırma yapabilir.

Saldırganların, SSRF zafiyeti kullanarak yapabilecekleri bir çok şey vardır. Bunların bazıları çok ciddi sonuçlar doğurabilmektedir. Fakat SSRF zafiyeti kullanılarak yapılabilecekler daha ziyade web uygulamasının uzak kaynaktan gelen istekleri nasıl kullandığına bağlıdır.

Server Side Request Forgery (SSRF) Zafiyetini Önleme

Web uygulamalarınızdaki SSRF açıklarını önlemek için, web sunucusunun uzak kaynakları çağırmasına izin verilen domainler ve protokoller için whitelist yöntemi uygulamanız şiddetle tavsiye edilir.

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ın tümünü kapsamak neredeyse imkânsız olduğu için pratikte bunu uygulamak çok zordur.

Bir saldırgan aşağıdakileri yapabilir:

• Dahili bir ağdaki IP adresine çevirilecek olan IP adreslerini encode edilmiş şekilde kullanabilir.
  • 1 -> localhost ile aynı
  • 123.123.123 -> localhost ile aynı
• Dahili IP adreslerine host isimleri sağlayabilir.
• Hostname’in sonuna nokta koyarak blacklist bypass edebilir.

Bu saldırganların cephaneliklerinde olan bypass yöntemlerinin yalnızca küçük bir bölümünü oluşturur. Bu nedenle sunucu adına istekte bulunan işlevlerde kullanıcı girişini önlemeniz önerilir.

Web Uygulamalarındaki SSRF Zafiyetlerini Tespit Etmek

Web uygulamalarınızdaki SSRF zafiyetlerini otomatik olarak tespit etmek için Netsparker web uygulaması güvenlik tarayıcısını kullanabilirsiniz. Netsparker SSRF ve Out-of-Band zafiyetlerini Invicti Hawk’ı kullanarak tespit etmektedir.