Önceki dersimizde, verinin önce depolanıp daha sonra farklı bir bağlamda güvensizce kullanıldığı ikinci derece enjeksiyonları incelemiştik. Bu derste, yine kullanıcı girdisinin beklenmedik sonuçlara yol açtığı, ancak bu kez uygulamanın kendisini bir vekil (proxy) olarak kullandıran kritik bir zafiyet sınıfına odaklanacağız: Sunucu Tarafı İstek Sahteciliği (Server-Side Request Forgery - SSRF).
Bu dersin amacı, bir uygulamanın URL oluşturma ve HTTP istemcisi kullanma mantığındaki zafiyetleri manuel olarak nasıl tespit edeceğinizi anlamaktır. Kullanıcıdan gelen bir girdinin, sunucunun kendi ağından veya dış dünyaya kontrolsüz bir istek yapmasına nasıl neden olabileceğini kod seviyesinde izleyeceğiz. Özellikle modern bulut mimarilerinde yıkıcı etkilere sahip olabilen bu zafiyetin desenlerini tanıma ve potansiyel etkisini değerlendirme yeteneğinizi geliştireceğiz.
SSRF Zafiyetinin Temeli: Güvenilir Sunucuyu Kandırmak
En temel düzeyde SSRF, bir saldırganın, sunucu tarafındaki bir uygulamayı kendi belirlediği bir hedefe ağ isteği yapmaya zorlamasıdır. Zafiyet, genellikle uygulamanın bir URL'yi veya URL'nin bir parçasını kullanıcıdan alıp, bu girdiyi herhangi bir doğrulama yapmadan doğrudan bir HTTP istemci fonksiyonuna geçirmesiyle ortaya çıkar.
Zafiyetin temel tanımını ve çalışma prensibini anlamak için aşağıdaki makalenin giriş bölümünü inceleyelim.
SSRF (Server Side Request Forgery)
Bu makale, SSRF'in ne olduğunu ve temel bir istismar senaryosunu net bir şekilde açıklıyor.
Lütfen makalenin başındaki "SSRF Nedir?" başlığı altındaki bölümü okuyun. Uygulamanın, "uzak kaynakları çağırmasına izin verilen domainler ve protokoller denetlenmediği için" zafiyetin nasıl meydana geldiğine dikkat edin.
Bu zafiyetin kod seviyesindeki en basit halini aşağıdaki görselde görebilirsiniz. Bir Node.js uygulamasında, req.body.imageURL ile kullanıcıdan alınan URL, hiçbir kontrolden geçmeden doğrudan axios.get() fonksiyonuna veriliyor. Bu, klasik bir SSRF desenidir.
SSRF'in Yıkıcı Etkisi: Port Taramasından Bulut Hesabının Ele Geçirilmesine
SSRF'in etkisi, basit bir bilgi sızıntısından çok daha ileri gidebilir. Sunucu, saldırgan için güvenilir bir iç ağ vekiline dönüşür. Bu durum, özellikle bulut ortamlarında felaketle sonuçlanabilir.
SSRF'in başlıca etkileri şunlardır:
- İç Ağ Keşfi: Saldırgan, sunucu üzerinden iç ağdaki diğer makinelere (veritabanları, yönetim panelleri, dahili API'ler) istekler göndererek port taraması yapabilir ve ağ topolojisini haritalandırabilir.
- Dahili Servislere Erişim: Normalde internete kapalı olan ve kimlik doğrulama gerektirmeyen servislere (örn: Elasticsearch, Redis, Memcached) erişim sağlanabilir.
- Bulut Meta-Veri Servislerinin İstismarı: Bu, en kritik modern SSRF saldırı vektörüdür. AWS, GCP ve Azure gibi bulut sağlayıcıları, sanal sunucuların kendi rolleri, izinleri ve geçici anahtarları gibi meta-verilere erişebilmesi için özel bir IP adresi (
169.254.169.254gibi) üzerinden bir servis sunar. SSRF zafiyeti olan bir sunucu, bu adrese istek göndermeye zorlanarak bulut hesabına ait çok hassas kimlik bilgileri (credentials) çalınabilir. Bu kimlik bilgileri, tüm bulut altyapısını ele geçirmek için kullanılabilir.
Aşağıdaki şema, bir SSRF zafiyetinin dört adımda tam bir bulut altyapısı ele geçirme senaryosuna nasıl dönüştüğünü özetlemektedir.
SSRF'in çeşitli istismar yöntemlerini daha detaylı görmek için daha önce incelediğiniz makaleye geri dönelim.
SSRF (Server Side Request Forgery)
Bu bölüm, SSRF'in farklı istismar senaryolarını ve potansiyel etkilerini listelemektedir.
Makaledeki "SSRF Zafiyeti Sömürü Yöntemleri" başlığı altındaki bölümleri, özellikle "İç Ağda Keşif ve Saldırı" ve "Cloud servislerin meta-data bilgilerinin çekilmesi" kısımlarını dikkatlice okuyun. Bulut meta-veri servislerinin sorgulanmasının nasıl AWS anahtarları gibi kritik bilgilere yol açtığına odaklanın.
Kodda SSRF Desenlerini ve Atlatma Tekniklerini İzlemek
Tecrübeli bir güvenlik analisti olarak sizin için en değerli yetkinlik, bu zafiyetin koddaki desenlerini ve geliştiricilerin uyguladığı zayıf korumaları atlatma yöntemlerini tanımaktır.
Temel Desen: Kullanıcıdan gelen bir verinin (source), bir HTTP isteği yapan fonksiyona (sink) ulaşmasıdır.
- Source'lar:
URL query parametreleri,POST bodyiçindeki alanlar,HTTP header'ları(örn:Referer), veritabanından okunan konfigürasyonlar. - Sink'ler:
- Python:
requests.get(),urllib.request.urlopen() - JavaScript (Node.js):
axios.get(),fetch(),http.request() - Java:
new URL().openConnection(),HttpClient.send() - C#:
HttpClient.GetAsync()
- Python:
Geliştiriciler genellikle localhost, 127.0.0.1 gibi bariz girdileri engelleyen kara liste (blacklist) tabanlı korumalar uygular. Ancak bu korumalar, çeşitli kodlama ve yönlendirme teknikleriyle kolayca atlatılabilir.
SSRF (Server Side Request Forgery)
Bu bölüm, SSRF korumalarını atlatmak için kullanılan yaygın teknikleri özetlemektedir.
Lütfen makaledeki "SSRF Koruması Bypass Metotları" bölümünü inceleyin. Özellikle IP adreslerinin hexadecimal, decimal veya oktal formatta yazılarak filtrelerin nasıl aşıldığına ve [::] gibi IPv6 gösterimlerinin localhost'a erişim için nasıl kullanılabildiğine dikkat edin.
İleri Seviye Senaryo: SSRF Zincirleri ve Protokol Değiştirme
SSRF zafiyetlerinin gerçek gücü, diğer zafiyetlerle birleştirildiğinde ortaya çıkar. Bir SSRF, iç ağa açılan bir kapı olabilir ve bu kapıdan girilerek daha güçlü zafiyetler tetiklenebilir. Sizin gibi exploit zincirlerine ilgi duyan bir uzman için bu tür senaryoları anlamak kritiktir.
Aşağıdaki video, GitHub Enterprise üzerinde bulunan ve 4 farklı zafiyetin birleştirilmesiyle RCE'ye (Uzaktan Kod Çalıştırma) yol açan bir saldırı zincirini analiz ediyor. Bu zincirin her halkasında SSRF kritik bir rol oynamaktadır.
12500 USD değerinde 4 Zafiyetin Birleşimiyle Github RCE Analizi xD
Bu video, Mehmet İnce tarafından hazırlanan ve GitHub Enterprise'da bulunan karmaşık bir RCE zincirini detaylıca analiz etmektedir. Video, SSRF'in bir saldırı zincirinin başlangıç noktası ve birleştirici unsuru olarak nasıl kullanılabileceğini mükemmel bir şekilde göstermektedir.
Bu kompleks senaryoyu anlamak için videonun şu kilit bölümlerini izlemenizi öneririm: İlk SSRF ve bypass: GitHub'ın webhook özelliğindeki ilk SSRF zafiyetinin ve IP adresi doğrulama mekanizmasının nasıl atlatıldığının anlatıldığı bölüm. İkinci Derece SSRF ve Protokol Atlama: İlk SSRF kullanılarak erişilen dahili Graphite servisindeki ikinci bir SSRF'in nasıl tetiklendiğini ve bu yeni SSRF üzerindeki CRLF Injection ile HTTP dışındaki protokollere (Redis) nasıl ulaşıldığını gösteren bölüm. Tüm Zincirin Özeti: Saldırganın dış dünyadan başlayarak, birinci SSRF -> ikinci SSRF -> CRLF Injection -> Redis üzerinden Deserialization ile RCE'ye nasıl ulaştığını özetleyen şema üzerindeki anlatım.
Bu vaka analizi, SSRF'in sadece "bir yere istek göndermek" olmadığını, aynı zamanda iç sistemler arasında köprü kurmak, protokolleri değiştirmek ve daha büyük saldırıların önünü açmak için nasıl bir "primitive" olarak kullanılabileceğini göstermektedir.
Güvenli Kodlama ve Önleme Stratejileri
SSRF'i önlemenin tek güvenilir yolu, kara liste (blacklist) yerine katı bir beyaz liste (whitelist) yaklaşımı benimsemektir.
- URL Ayrıştırma ve Doğrulama:
- Kullanıcıdan gelen URL'yi standart ve güvenilir bir kütüphane ile ayrıştırın.
- Protokolün sadece
HTTPveyaHTTPSolduğundan emin olun, diğerlerini (file://,gopher://vb.) reddedin.
- Hostname (alan adı) kısmını alın.
- Hostname Beyaz Liste Kontrolü:
- Alınan hostname'in, uygulamanın iletişim kurmasına izin verilen, önceden tanımlanmış bir alan adları listesinde olup olmadığını kontrol edin.
- DNS Çözümlemesi ve IP Doğrulama:
- Hostname'i bir IP adresine çözümleyin.
- Çözümlenen IP adresinin özel, yerel veya rezerve edilmiş bir aralıkta (
127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,169.254.0.0/16) olmadığını doğrulayın. Bu, DNS Rebinding gibi gelişmiş saldırıları önlemek için kritik bir adımdır.
- İç Servislerde Kimlik Doğrulama:
- Mümkün olan her yerde, iç servisler arasında bile kimlik doğrulama mekanizmaları uygulayarak "sıfır güven" (zero-trust) mimarisini benimseyin.
Aşağıdaki video, bu prensiplerin Python'da nasıl uygulanabileceğini pratik olarak göstermektedir.
XSS, Path Traversal ve SSRF - Canlı yayında Güvenli Kod Geliştirme Challenge'ı 0x01 !
Bu videoda Mehmet İnce, güvenli kod geliştirme yarışması kapsamında bir SSRF zafiyetini nasıl düzelteceğini canlı olarak kodluyor. Teorik bilgilerin pratiğe nasıl döküldüğünü görmek için harika bir örnek.
Lütfen videonun şu bölümlerini izleyin: Güvenlik Kontrollerinin Planlanması: Geliştiricinin, bir URL'yi güvenli bir şekilde işlemeden önce hangi adımları atması gerektiğini (URL'yi parse et, domaini al, localhost kontrolü yap, DNS çözümlemesi yap) düşündüğü bölüm. IP Adresi Kontrolünün Karmaşıklığı: Girdinin doğrudan bir IP adresi olması durumunu ele almanın ve is_private gibi kontrollerin nasıl uygulanacağının tartışıldığı bölüm. Bu, gerçek dünya kodlamasındaki incelikleri gösterir.
Özet ve Sonraki Adım
Bu dersimizde, Sunucu Tarafı İstek Sahteciliği (SSRF) zafiyetinin ne olduğunu, potansiyel etkilerini ve kodda nasıl tespit edileceğini derinlemesine inceledik.
Anahtar Çıkarımlar:
- SSRF, kullanıcı girdisinin sunucu tarafında yapılan bir ağ isteğinin hedefini kontrol etmesiyle oluşur.
- En büyük riski, iç ağdaki servislere ve özellikle bulut meta-veri servislerine erişim sağlayarak kimlik bilgisi hırsızlığına yol açmasıdır.
- Kod analizi, kullanıcı girdisinden
requests.get()gibi bir HTTP istemcisine olan veri akışını izlemeye odaklanmalıdır. - Zayıf kara liste korumaları, IP kodlama ve yönlendirme teknikleriyle kolayca atlatılabilir.
- Etkili önleme, katı bir beyaz liste yaklaşımı ve hostname'in çözümlendiği IP adresinin özel bir aralıkta olup olmadığının kontrolü dahil çok katmanlı bir doğrulama gerektirir.
Bir sonraki dersimizde, enjeksiyon zafiyetleri konusuna devam edeceğiz. Bu kez veritabanı katmanına geri dönecek ve dinamik sorgu oluşturma yoluyla parametreli sorguları atlatan ORM/LINQ enjeksiyon desenlerini nasıl tespit edeceğimizi öğreneceğiz. Tıpkı önceki derste gördüğümüz gibi, modern ORM'lerin bile her zaman mutlak güvenlik sağlamadığını ve yanlış kullanımlarının nasıl ciddi zafiyetlere yol açabileceğini göreceğiz.