Eksik Content-Security-Policy (CSP) Başlığı

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

Sitenizi Tarayın

Sitenizi bu zafiyete karşı kontrol edin

Otomatik bir tarama başlatın ve sitenizin etkilenip etkilenmediğini görün — sade dille bulgular ve çözümlerle.

Taramaya Başla
Kategori Güvenlik Yanlış Yapılandırması / Derinlemesine Savunma
Tipik Önem Derecesi Orta
OWASP A05:2021 – Güvenlik Yanlış Yapılandırması; A03:2021 – Enjeksiyon (XSS etkinleştirme)
CWE CWE-693 – Koruma Mekanizması Başarısızlığı
İlgili Standart W3C Content Security Policy Seviye 3 (CSP3)
Diğer Adları Eksik CSP, CSP başlığı yok, Content-Security-Policy tanımsız
Etkilenen Sistemler HTTP/HTTPS üzerinden HTML yanıtı sunan tüm web uygulamaları ve web siteleri

Genel Bakış

Content-Security-Policy (CSP), W3C tarafından standartlaştırılmış bir HTTP yanıt başlığıdır ve tarayıcılara bir belgenin hangi kaynaklardan betik, stil, görsel, çerçeve ve diğer kaynakları yükleyip yürütebileceğini kısıtlamalarını bildirir. Başlık olmadığında tarayıcı, ek kısıtlama içermeyen izin verici same-origin politikasına geri döner ve uygulamayı XSS gibi içerik enjeksiyonu saldırılarına karşı ikinci bir savunma katmanından yoksun bırakır.

Eksik bir CSP başlığı doğrudan bir güvenlik açığı oluşturmaz; ancak kritik bir hafifletme kontrolünü ortadan kaldırır. Uygulamada bir XSS veya HTML enjeksiyon zafiyeti bulunduğunda, CSP yokluğu enjekte edilen betiklerin tarayıcı düzeyinde herhangi bir müdahale olmaksızın çalışmasına olanak tanır. Sensagraph, eksik ve yanlış yapılandırılmış CSP başlıklarını sürekli HTTP güvenlik başlığı kontrolleriyle otomatik olarak tespit eder.

Nasıl Çalışır

Content-Security-Policy başlığı (veya eşdeğer <meta http-equiv> etiketi) olmadığında tarayıcılar yalnızca varsayılan same-origin kurallarını uygular. Yansıtılmış, depolanmış veya DOM tabanlı XSS yoluyla sayfaya içerik enjekte edebilen bir saldırgan, hiçbir politika script-src kısıtlaması tanımlamadığından veya satır içi betikleri engellemediğinden keyfi JavaScript çalıştırabilir.

  • Satır içi betik yürütme: Hiçbir CSP 'unsafe-inline' kullanımını yasaklamadığında, tarayıcılar <script>...</script> bloklarını ve olay işleyici niteliklerini (onclick, onerror vb.) serbestçe çalıştırır.
  • Rastgele harici betik yükleme: Bir script-src yönergesi olmadan, sayfalar herhangi bir kaynaktan betik yükleyebilir; bu da saldırganların denetimindeki CDN'lerden veya alan adlarından zararlı yük getirmesine olanak tanır.
  • connect-src yokluğuyla veri sızdırma: connect-src yönergesi olmadan enjekte edilen kod, çalınan oturum belirteçlerini veya kimlik bilgilerini harici uç noktalara özgürce iletebilir.
  • Eklenti ve nesne yükleme: object-src 'none' olmadan, eski eklenti içerikleri (Flash, Java uygulamaları) enjekte edilebilir; ancak bu modern tarayıcılarda artık daha az geçerlidir.
  • Tıklama tuzağını kolaylaştırma: CSP'nin frame-ancestors yönergesi, çerçevelemeyi kontrole alan modern yaklaşımdır; bu yönergenin yokluğu (eksik X-Frame-Options başlığıyla birlikte) tıklama tuzağı saldırılarını mümkün kılar.

İş Etkisi

Eksik CSP'nin pratik riski, uygulamanın hassasiyetine ve başka enjeksiyon zafiyetlerinin bulunup bulunmadığına göre değişir:

  • Oturum ele geçirme: Enjekte edilen betikler, HttpOnly bayrağı olmayan oturum çerezlerini ve kimlik doğrulama belirteçlerini çalarak hesap ele geçirilmesine yol açabilir.
  • Kimlik bilgisi hırsızlığı: DOM manipülasyonu, URL'de görünür bir değişiklik olmaksızın sahte giriş formları bindirebilir veya kullanıcıları kimlik avı sayfalarına yönlendirebilir.
  • Veri sızdırma: Hassas kişisel veriler, finansal bilgiler veya dahili API yanıtları saldırgan altyapısına sessizce iletilebilir.
  • Kötü amaçlı yazılım dağıtımı: Ele geçirilmiş sayfalar, ziyaretçilere sürücü indirme saldırıları sunarak yasal ve itibarsal yükümlülük doğurabilir.
  • Mevzuat riski: Mevcut teknik kontrollerin uygulanmaması, GDPR Madde 32 (uygun teknik tedbirler), PCI DSS Gereksinim 6.4 ve benzer çerçeveler kapsamında ihlal teşkil edebilir.

Nasıl Düzeltilir

  1. Yalnızca raporlama modundaki bir politikayla başlayın: İşlevselliği bozmadan ihlalleri toplamak için izin verici bir temel ve bir report-uri veya report-to uç noktasıyla Content-Security-Policy-Report-Only dağıtın. Politikayı uygulamaya koymadan önce tüm meşru kaynak kaynaklarını belirlemek için raporları analiz edin.
  2. Katı bir temel politika tanımlayın: En azından şunları içeren bir politika kullanın: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self';. Yönergeleri yalnızca doğrulanmış üçüncü taraf kaynakları için genişletin.
  3. Satır içi betik ve stilleri kaldırın: Tüm satır içi JavaScript'i harici dosyalara taşıyın. Satır içi betikler kaçınılmazsa 'unsafe-inline' yerine 'nonce-{rastgele}' veya 'sha256-{hash}' kullanın. Her yanıt için kriptografik olarak rastgele bir nonce üretin.
  4. 'unsafe-eval' kullanmaktan kaçının: Bu yönergeye olan ihtiyacı ortadan kaldırmak için eval(), Function() veya benzer dinamik kod yürütmeye dayanan kodları yeniden düzenleyin.
  5. Fetch yönergelerini kilitleyun: Uygulamanızın meşru olarak kullandığı tüm kaynaklar için script-src, style-src, img-src, font-src, connect-src, media-src, frame-src ve worker-src yönergelerini açıkça belirtin.
  6. upgrade-insecure-requests ekleyin: Karma içerik kaynaklarının otomatik olarak HTTPS üzerinden yüklenmesini sağlamak için bu yönergeyi ekleyin.
  7. Uygulamaya geçiş yapın: Politika doğrulandıktan ve ihlaller stabilleştikten sonra Content-Security-Policy-Report-Only yerine Content-Security-Policy'e geçin.
  8. Başlığı web sunucusu veya CDN katmanında sunun: Başlığı Nginx (add_header), Apache (Header always set) veya CDN'inizin yanıt başlığı kurallarında yapılandırarak tüm yanıtlarda bulunmasını sağlayın.
  9. Düzenli olarak gözden geçirin ve güncelleyin: CSP politikaları, bağımlılıklar ve üçüncü taraf entegrasyonlar değiştikçe bakım gerektirir. CSP incelemesini dağıtım sürecinize dahil edin.

Referanslar

Sıkça sorulan sorular

Eksik CSP başlığı, tek başına istismar edilebilir bir güvenlik açığından ziyade eksik bir derinlemesine savunma kontrolüdür. Ancak, XSS gibi yaygın açıkların etkisini sınırlayan tarayıcı düzeyindeki hafifletme mekanizmasını ortadan kaldırır. Bu nedenle önem derecesi bağlama göre değişir: kullanıcı girişi olmayan statik bilgilendirme sayfalarında düşük risk, hassas veri işleyen kimliği doğrulanmış uygulamalarda ise yüksek risk oluşturabilir.

Evet, CSP <head> öğesi içindeki <meta http-equiv="Content-Security-Policy"> etiketiyle sunulabilir. Ancak bu yaklaşımın önemli sınırlamaları vardır: frame-ancestors yönergesini kullanamazsınız, tüm tarayıcılarda report-uri yönergesini kullanamazsınız ve politika yalnızca meta etiketi ayrıştırıldıktan sonra geçerli olur; yani ondan önce başvurulan kaynaklar zaten yüklenmiş olabilir. CSP'yi HTTP yanıt başlığı olarak sunmak kesinlikle tercih edilen yöntemdir.

Content-Security-Policy tanımlanan politikayı uygular: tarayıcı bir yönergeyi ihlal eden herhangi bir kaynağı engeller ve isteğe bağlı olarak ihlali bildirir. Content-Security-Policy-Report-Only hiçbir şeyi engellemez; yalnızca yapılandırılmış uç noktaya ihlalleri raporlar. Report-Only modu, politikayı uygulamaya koymadan önce olası kırılmaları belirlemek için kullanılır ve uygulama modu politikasıyla paralel çalıştırılabilir.

Önceden analiz yapılmadan dağıtılan aşırı katı bir CSP, işlevselliği bozabilir. Satır içi betikler, dinamik olarak üretilen içerik, üçüncü taraf widget'lar, analitik etiketler ve CDN'den sunulan varlıkların tamamı politikada açıkça izin verilenler listesine alınmalıdır. Önerilen yaklaşım, önce yalnızca raporlama modunda dağıtmak, ihlal verilerini toplamak ve politikayı uygulama moduna geçirmeden önce iteratif olarak iyileştirmektir.

En azından şunlar olmalıdır: default-src (geri dönüş olarak), script-src (JavaScript yürütmeyi kontrol eder), object-src 'none' (eklenti içeriğini engeller), base-uri 'self' (base etiketi enjeksiyonunu önler) ve frame-ancestors (çerçevelemeyi kontrol eder). connect-src, style-src, img-src ve font-src, bu kanallar aracılığıyla veri sızdırma ve kaynak enjeksiyonunu önlemek için açıkça kapsamlandırılmalıdır.