SSL Sertifika Analizi Açık Port Tespiti Web Uygulama Tarama DNS Güvenlik Denetimi HTTP Başlık Analizi Yanlış Yapılandırma Tespiti Yazılım Parmak İzi Alt Alan Adı Tarama
SSL Sertifika Analizi Açık Port Tespiti Web Uygulama Tarama DNS Güvenlik Denetimi HTTP Başlık Analizi Yanlış Yapılandırma Tespiti Yazılım Parmak İzi Alt Alan Adı Tarama

Tüm Kayıtlar

Kategori Sunucu Taraflı İstek Sahteciliği
Tipik Önem Derecesi Yüksek
OWASP A10:2021 – Server-Side Request Forgery (SSRF)
CWE CWE-918
Diğer adları XSPA (Siteler Arası Port Saldırısı), Kör SSRF
Etkilenen sistemler Kullanıcı tarafından sağlanan URL veya ana bilgisayar adlarına göre uzak kaynak getiren web uygulamaları (URL getiriciler, webhook'lar, PDF oluşturucular, dosya içe aktarıcılar, proxy hizmetleri)

Genel Bakış

Sunucu Taraflı İstek Sahteciliği (SSRF), saldırganın sunucunun saldırganın seçtiği keyfi bir hedefe HTTP (veya başka protokol) istekleri yapmasına neden olabildiği bir web güvenlik açığıdır. İstek sunucunun kendisinden kaynaklandığından, genel internete açık olmayan iç servislere, bulut sağlayıcı metadata uç noktalarına ve diğer kaynaklara ulaşabilir. SSRF, modern bulut mimarilerindeki yaygınlığı ve yüksek istismar edilebilirliği nedeniyle OWASP Top 10 2021'de kendi ayrı kategorisine (A10) kavuşturulmuştur.

Nasıl Çalışır?

SSRF, bir uygulama kullanıcı kontrolündeki bir değeri (URL, ana bilgisayar adı, IP adresi veya dosya yolu) yeterli doğrulama yapmadan arka uç HTTP isteği oluşturmak için kullandığında ortaya çıkar. Saldırgan meşru bir hedefi kötü amaçlı biriyle değiştirir.

  • Doğrudan (bant içi) SSRF: Sahte isteğe verilen sunucu yanıtı doğrudan saldırgana döner; servis başlıkları veya iç API verileri gibi dahili içerikler sızdırılır.
  • Kör (bant dışı) SSRF: Yanıt saldırgana yansıtılmaz, ancak istek yine de gönderilir. Etki; DNS geri aramaları, zamanlama farkları veya yan kanal gözlemleriyle doğrulanır.
  • Bulut metadata uç noktaları: AWS, GCP ve Azure ortamlarında bağlantı-yerel adres 169.254.169.254 (ve eşdeğer IMDSv2 uç noktaları), örnek kimlik bilgileri, IAM rolleri ve yapılandırma verileri sunar — bu durum onu birincil SSRF hedefi yapar.
  • İç ağ port taraması: Hedef IP ve portu değiştirerek saldırgan, sunucunun ağ bakış açısından ulaşılabilir iç ana bilgisayarları ve açık portları haritalayabilir.
  • Protokol kaçakçılığı: Bazı SSRF açıkları, HTTP konuşmayan servislerle etkileşim kurmak için file://, dict://, gopher:// veya ftp:// gibi HTTP dışı şemalarla istismar edilebilir.
  • DNS yeniden bağlama / yönlendirme zincirleri: Saldırganlar, doğrulamayı geçmek için önce meşru bir alan adı kullanıp ardından iç IP'ye çözümlenen bir adresle ya da açık yönlendirme zincirlerini kötüye kullanarak izin listesi kontrollerini atlatır.

Tipik bir saldırı yükü şöyle görünebilir: https://example.com/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

İş Etkisi

Başarılı bir SSRF istismarı ciddi sonuçlar doğurabilir:

  • Kimlik bilgisi hırsızlığı: Metadata servislerinden bulut IAM kimlik bilgilerinin ele geçirilmesi, tam bulut hesabı ele geçirmeye yol açarak büyük ölçekte yanal hareket ve veri sızıntısını mümkün kılar.
  • İç ağ keşfi: Saldırganlar iç ağ topolojisini, servisleri ve yazılım sürümlerini haritalayarak sonraki saldırıların maliyetini önemli ölçüde düşürür.
  • Veri sızıntısı: Yalnızca VPC içinde erişilebilen iç API'ler, veritabanları, yapılandırma depoları (ör. Consul, etcd) ve gizli yöneticiler doğrudan sorgulanabilir.
  • Uzaktan kod yürütme: Redis, Memcached veya iç yönetici arayüzlerine yönelik SSRF, protokol kötüye kullanımı (ör. Gopher tabanlı Redis komut enjeksiyonu) aracılığıyla RCE'ye yol açabilir.
  • Uyumluluk ihlalleri: İç API'ler aracılığıyla KKB veya düzenlenmiş verilerin ifşası; GDPR, HIPAA, PCI-DSS ve benzeri çerçeveler kapsamında yükümlülükler doğurur.
  • İtibar ve finansal zarar: Yüksek profilli SSRF ihlalleri (ör. 2019 Capital One olayı), 80 milyon doları aşan düzenleyici para cezaları ve kalıcı itibar zararına yol açmıştır.

Nasıl Düzeltilir?

  1. Hedefleri doğrulayın ve izin listesi oluşturun: İzin verilen alan adları, IP'ler ve portlar için katı bir izin listesi oluşturun. Çözümlenen IP'si RFC 1918 özel aralıklarına (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), geri döngüye (127.0.0.0/8), bağlantı-yereline (169.254.0.0/16) veya IPv6 eşdeğerlerine düşen istekleri reddedin.
  2. DNS'yi doğrulamadan önce çözümleyin: DNS çözümlemesini sunucu tarafında gerçekleştirin ve isteği göndermeden önce elde edilen IP adresini izin listesine göre doğrulayın; bu sayede DNS yeniden bağlama saldırıları önlenir. Aynı çözümlenmiş adresin gerçek bağlantı için kullanıldığından emin olun (TOCTOU güvenli uygulama).
  3. Gereksiz URL şemalarını devre dışı bırakın: Kabul edilen URL şemalarını yalnızca https:// ile sınırlayın. file://, dict://, gopher://, ftp:// ve benzeri şemaları ayrıştırıcı düzeyinde açıkça reddedin.
  4. Özel bir çıkış proxy'si veya güvenlik duvarı kullanın: Sunucu tarafından başlatılan tüm giden trafiği, uygulama düzeyindeki kontrollerden bağımsız derinlemesine savunma sağlayan; ağ katmanında hedef izin listelerini uygulayan bir proxy veya çıkış güvenlik duvarı üzerinden yönlendirin.
  5. Yönlendirmeleri devre dışı bırakın veya yönlendirme hedeflerini doğrulayın: HTTP istemci kütüphanesi otomatik olarak yönlendirme izliyorsa, ya yönlendirme izlemeyi devre dışı bırakın ya da her yönlendirme hedefini izin listesine göre yeniden doğrulayın.
  6. Bulut ortamlarında IMDSv2'yi zorunlu kılın: AWS için tüm EC2 örneklerinde IMDSv2'yi (token tabanlı metadata erişimi) zorunlu hale getirin; bu, SSRF yüklerinin kolayca karşılayamayacağı özel başlık içeren bir PUT isteği gerektirir.
  7. En az ayrıcalık ilkesiyle ağ segmentasyonu uygulayın: Uygulamanın çalışma zamanı ağ kimliğinin iç servislere gereksiz erişimi olmadığından emin olun. Yanal erişilebilirliği sınırlamak için güvenlik grupları, ağ politikaları veya VPC güvenlik duvarı kuralları kullanın.
  8. Ham sunucu yanıtlarını istemcilere döndürmekten kaçının: Mümkün olduğunda getirilen kaynağı sunucu tarafında işleyin ve yalnızca gerekli verileri istemciye döndürün; bu, kısmi SSRF senaryolarında bilgi sızıntısını azaltır.
  9. Anormal giden istekleri günlüğe kaydedin ve uyarı oluşturun: RFC 1918 adreslerine, bulut metadata uç noktalarına veya beklenmedik dış hedeflere yönelik istekleri izleyin ve ihlaller için uyarı oluşturun.

Sensagraph, kör varyantlar dahil olmak üzere SSRF güvenlik açıklarını; kullanıcı kontrolündeki URL parametrelerini inceleyerek ve sunucu davranışını analiz ederek otomatik olarak tespit eder.

Kaynaklar

Sıkça sorulan sorular

CSRF (Siteler Arası İstek Sahteciliği), kurban kullanıcının tarayıcısını hedef siteye kurban adına istek yapmaya kandırır. SSRF ise sunucunun kendisini saldırgan adına istek yapmaya kandırır; bu istekler genellikle iç veya bulut altyapısını hedef alır. SSRF tamamen sunucu tarafında gerçekleşir ve kurban bir kullanıcı gerektirmez.

Kör SSRF'de, sahte isteğin yanıtı saldırgana yansıtılmaz. Buna karşın saldırı; DNS geri aramaları veya zamanlama yoluyla iç servislerin varlığını doğrulamak, iç sistemlerde eylemler tetiklemek ya da bant dışı kanallar aracılığıyla veri sızdırmak için kullanılabilir. Bu nedenle doğrudan yanıt olmasa bile oldukça tehlikelidir.

Bulut sağlayıcılar, geçici IAM kimlik bilgileri dahil örnek meta verilerini bir bağlantı-yerel HTTP uç noktası (AWS/GCP/Azure'da 169.254.169.254) üzerinden sunar. Bir SSRF açığı, saldırganın bu kimlik bilgilerini almasına olanak tanır; bu kimlik bilgileri bulut kaynaklarına geniş erişim sağlayarak yanal harekete, veri sızıntısına veya tam hesap ele geçirmeye yol açabilir.

Hayır. Metadata uç noktasını engellemek savunmanın bir katmanıdır, ancak diğer iç servisleri, veritabanlarını, yönetici arayüzlerini veya intranet kaynaklarını hedef alan SSRF saldırılarını önlemez. Kapsamlı bir savunma; katı hedef izin listesi, çıkış güvenlik duvarı kontrolleri ve ağ segmentasyonu gerektirir.

Evet, belirli yapılandırmalarda. SSRF, HTTP veya diğer protokoller üzerinden komut kabul eden iç servislerin kötüye kullanılmasıyla RCE'ye yükseltilebilir. Örneğin, Redis veya Memcached ile etkileşim kurmak için Gopher şemasının kullanılması keyfi komut enjeksiyonuna, iç yönetici panellerine (ör. Jenkins, Solr) erişim ise RCE uç noktalarını açığa çıkarabilir.