İçerik Güvenliği Politikası (İGP), sayfaya yüklenen tüm içeriklerin site sahibi tarafından güvenilir olmasını sağlar. İGP'ler, saldırganlar tarafından yerleştirilen güvenli olmayan komut dosyalarını engelleyebildiğinden siteler arası komut dosyası çalıştırma (XSS) saldırılarını azaltır. Ancak yeterince katı değilse CSP kolayca atlanabilir. Daha fazla bilgi için Katı bir İçerik Güvenliği Politikası (İGP) ile siteler arası komut dosyası çalıştırma (XSS) saldırılarını azaltma başlıklı makaleyi inceleyin. Lighthouse, ana belgede uygulanan CSP'leri toplar ve atlanabilirlerse CSP Değerlendirici'den sorunları bildirir.
Atlanılamayacak bir CSP için gerekli uygulamalar
CSP'nizin atlanamaması için aşağıdaki uygulamaları uygulayın. CSP atlanabilirse Lighthouse yüksek önem dereceli bir uyarı verir.
CSP, XSS'yi hedefler
XSS'yi hedeflemek için bir İGP'nin script-src, object-src ve base-uri yönergelerini içermesi gerekir. CSP'de söz dizimi hatası da bulunmamalıdır.
script-src ve object-src, bir sayfayı sırasıyla güvenli olmayan komut dosyalarına ve güvenli olmayan eklentilere karşı korur. Alternatif olarak default-src, script-src ve object-src dahil birçok yönerge yerine geniş bir politika yapılandırmak için kullanılabilir.
base-uri, tüm göreli URL'leri (ör. komut dosyaları) saldırgan kontrolündeki bir alana yönlendirmek için kullanılabilecek yetkisiz <base> etiketlerinin yerleştirilmesini engeller.
CSP, izin verilenler listesi atlamalarını önlemek için tek seferlik değerler veya karma oluşturma işlemleri kullanır
script-src için izin verilenler listesi yapılandıran bir İGP, güvenilir bir alandan gelen tüm yanıtların güvenli olduğu ve komut dosyası olarak yürütülebileceği varsayımını temel alır. Ancak bu varsayım modern uygulamalar için geçerli değildir. JSONP arayüzlerini gösterme ve AngularJS kitaplığının kopyalarını barındırma gibi yaygın ve zararsız bazı kalıplar, saldırganların CSP'nin sınırlarından kaçmasına olanak tanır.
Uygulama yazarları tarafından fark edilmese de pratikte script-src izin verilenler listelerinin çoğu, XSS hatası olan bir saldırgan tarafından atlatılabilir ve komut dosyası eklemeye karşı çok az koruma sağlar. Buna karşılık, tek seferlik anahtar tabanlı ve karma oluşturma tabanlı yaklaşımlar bu sorunlardan etkilenmez ve daha güvenli bir politikayı benimsemeyi ve sürdürmeyi kolaylaştırır.
Örneğin, bu kodda saldırgan tarafından kontrol edilen bir komut dosyası yerleştirmek için güvenilir bir alanda barındırılan bir JSONP uç noktası kullanılır:
İGP:
script-src https://trusted.example.com
HTML:
<script src="https://trusted.example.com/path/jsonp?callback=alert(document.domain)//"></script>
CSP'lerin atlatılmasını önlemek için komut dosyalarına nonce veya hash değerleri kullanarak ayrı ayrı izin vermesi ve izin verilenler listesi yerine "strict-dynamic" değerini kullanması gerekir.
Güvenli bir CSP için ek öneriler
Daha fazla güvenlik ve uyumluluk için aşağıdaki uygulamaları uygulayın. CSP, önerilerden birine uymazsa Lighthouse orta önem derecesinde bir uyarı verir.
CSP raporlamasını yapılandırma
Raporlama hedefi yapılandırmak, kesintileri izlemenize yardımcı olur. report-uri veya report-to yönergelerini kullanarak raporlama hedefini ayarlayabilirsiniz. report-to şu anda tüm modern tarayıcılar tarafından desteklenmemektedir. Bu nedenle, her ikisini birden veya yalnızca report-uri'ü kullanmanız önerilir.
Herhangi bir içerik CSP'yi ihlal ederse tarayıcı, yapılandırılmış hedefe bir rapor gönderir. Bu hedefte bu raporları işleyen bir uygulama yapılandırdığınızdan emin olun.
CSP'yi bir HTTP başlığında tanımlama
CSP, aşağıdaki gibi bir meta etikette tanımlanabilir:
<meta http-equiv="Content-Security-Policy" content="script-src 'none'">
Ancak mümkünse CSP'yi bir HTTP yanıt başlığında tanımlamanız gerekir. Meta etiketinden önce yapılan bir ekleme, CSP'yi atlar. Ayrıca, meta etiket CSP'lerinde frame-ancestors, sandbox ve raporlama desteklenmez.
CSP'nin geriye dönük uyumlu olduğundan emin olun
CSP nonce/hash'lerini tüm tarayıcılar desteklemez. Bu nedenle, uyumlu olmayan tarayıcılar için yedek olarak unsafe-inline eklemeniz önerilir. Tarayıcı nonce/hash'leri destekliyorsa unsafe-inline yoksayılır.
Benzer şekilde, strict-dynamic tüm tarayıcılar tarafından desteklenmez. Uyumlu olmayan tarayıcılar için yedek olarak izin verilenler listesi ayarlanması önerilir. İzin verilenler listesi, strict-dynamic'ü destekleyen tarayıcılarda yoksayılır.
Katı bir CSP geliştirme
Aşağıda, tek seferlik sayı tabanlı bir politikayla katı CSP kullanımı örneği verilmiştir.
İGP:
script-src 'nonce-random123' 'strict-dynamic' 'unsafe-inline' https:;
object-src 'none';
base-uri 'none';
report-uri https://reporting.example.com;
HTML:
<script nonce="random123" src="https://trusted.example.com/trusted_script.js"></script>
random123, sayfa her yüklendiğinde sunucu tarafında oluşturulan herhangi bir base64 dizesi olur. unsafe-inline ve https:, tek seferlik sayı ve strict-dynamic nedeniyle modern tarayıcılarda yoksayılır. Sıkı CSP'yi benimseme hakkında daha fazla bilgi için Sıkı CSP kılavuzuna göz atın.
Lighthouse ve CSP Değerlendirici'yi kullanarak bir CSP'nin olası atlamalara karşı olup olmadığını kontrol edebilirsiniz. Mevcut sayfaları bozma riski olmadan yeni bir CSP'yi test etmek istiyorsanız CSP'yi, başlık adı olarak Content-Security-Policy-Report-Only kullanarak yalnızca rapor modunda tanımlayın. Bu işlem, CSP ihlallerini report-to ve report-uri ile yapılandırdığınız tüm raporlama hedeflerine gönderir ancak CSP'yi zorunlu kılmaz.