İçerik Güvenliği Politikaları (CSP’ler), genellikle siteler arası komut dosyası çalıştırma (XSS) ve tıklama hırsızlığı gibi istemci tarafı saldırılara karşı son savunma hattı olarak kullanılır. 2012’deki ilk kullanıma sunulmalarından bu yana, geliştiricilerin belirli bir DOM bağlamında hangi kaynakların yüklenmesine ve değerlendirilmesine izin verildiğini kontrol etmelerine olanak sağladılar.
Bununla birlikte, geliştiricilerin, istemci tarafı saldırılarına karşı tek savunma katmanı olarak bu karşı önlemi kullandığı hala yaygın olarak görülmektedir. Sonuçta bu durumdan kaçınmamız ve kötü amaçlı JavaScript kodumuzu çalıştırmamız için bize yeni fırsatlar sunuyor.
Bu makalede, İçerik Güvenliği Politikalarının ne olduğunu ve örneğin XSS açıklarından yararlanmak için CSP’leri nasıl atlayabileceğimizi derinlemesine inceleyeceğiz.
Hadi dalalım!
İçerik Güvenliği Politikası (CSP) Nedir?
İçerik Güvenliği Politikası (CSP), siteler arası komut dosyası çalıştırma (XSS) ve tıklama hırsızlığı güvenlik açıkları da dahil olmak üzere içerik enjeksiyon saldırılarını azaltmak için tasarlanmış bir tarayıcı güvenlik mekanizmasıdır. Geliştiriciler, tarayıcının farklı içerik türleri (komut dosyaları, stil sayfaları, resimler vb.) için hangi kaynaklara güvenmesi gerektiğini belirterek, web sayfalarında hangi kaynakların yüklenmesine ve çalıştırılmasına izin verildiğini etkili bir şekilde kontrol edebilir.
Doğru şekilde uygulandığında CSP, giriş doğrulaması eksik veya yetersiz olduğunda bile XSS’nin kötüye kullanılmasını engelleyebilecek derinlemesine bir savunma katmanı görevi görür. Bununla birlikte, CSP hiçbir zaman tek savunma hattı olarak düşünülmemelidir; çünkü yanlış yapılandırmalar ve gözetimler onu etkisiz hale getirebilir veya bu makalenin ilerleyen kısımlarında ele alacağımız gibi, tamamen bypass yapılmasına izin verebilir.
CSP bypass’larının ne olduğunu daha iyi anlamamıza yardımcı olacak en önemli yönerge adlarını ve kaynaklarını gözden geçirelim. CSP’lere ve istemci tarafı saldırılara zaten aşina iseniz, atlamalar bölümüne geçebilirsiniz.
İçerik Güvenliği Politikası (CSP), hata ödülünde atlanıyor
İçerik Güvenliği Politikası (CSP) yanlış yapılandırmalarının belirlenmesi, genellikle sızma testlerinde raporlanmaya değerdir. Ancak bu mutlaka hata ödülüyle aynı şey değildir.
Çoğu program, CSP bypass raporlarını bağımsız güvenlik açıkları olarak kabul etmez. Gerçek dünyadaki etkisini göstermek için her zaman CSP bypass’ınızı gerçek bir XSS güvenlik açığıyla zincirlemeniz gerekecektir.
İçerik Güvenliği Politikası (CSP) bildirimlerini bulma
İçerik Güvenliği Politikaları (CSP’ler) iki ana yolla uygulanabilir; bunların nerede aranacağını anlamak, olası yanlış yapılandırmaları analiz etmek için çok önemlidir.
HTTP yanıt başlığı
En yaygın uygulama yöntemi, Content-Security-Policy HTTP yanıt başlığı. Herhangi bir sayfa yüklemesinin yanıt başlıklarını inceleyerek bunu tarayıcınızın geliştirici araçlarında Ağ sekmesi altında kolayca görüntüleyebilirsiniz.
İçerik Güvenliği Politikası (CSP)
HTML meta etiketi:
Alternatif olarak CSP, HTML belgesinin kendisinde bir kod kullanılarak tanımlanabilir. sayfadaki etiket section:
İçerik Güvenliği Politikası (CSP) direktiflerinin yapısını bozma
İçerik Güvenliği Politikası, her biri belirli bir kaynak türünü kontrol eden bir veya daha fazla direktiften oluşur. Aşağıda, güvenlik testi sırasında karşılaşacağınız en önemli CSP yönergelerinin kapsamlı bir tablosu bulunmaktadır.
Bu bilgiler CSP bildirimlerinde aktif olarak kötüye kullanabileceğimiz yanlış yapılandırmaları bulmamıza yardımcı olacağından hem yönerge adlarına hem de kaynaklara göz atmanız önerilir:
İçerik Güvenliği Politikası (CSP) bildirim adlarının açıklaması
İçerik Güvenliği Politikası (CSP) atlamaları
CSP atlamaları genellikle yanlış yapılandırma veya zayıf CSP bildirimi nedeniyle meydana gelir. Sonraki bölümlerde, bir XSS güvenlik açığı aracılığıyla rastgele JavaScript yürütmek için bu CSP yanlış yapılandırmalarını nasıl tanımlayıp atlayabileceğinizi gösteren birkaç pratik yararlanma tekniğini inceleyeceğiz.
1. İçerik Güvenliği Politikası (CSP) beyanı yok
Eksik bir İçerik Güvenliği Politikası (CSP) bildirimi bunun en basit örneğidir. Hiçbir politika tanımlanmadığında tarayıcı, kaynak yükleme veya komut dosyası yürütme konusunda herhangi bir kısıtlama uygulamaz. Pratik olarak bu, herhangi bir kodu kısıtlama olmadan çalıştırabileceğiniz anlamına gelir.
Hedefinizin bir CSP kullanıp kullanmadığını doğrulamak için yanıt başlığını ve HTML kaynağını bir CSP bildiriminin varlığı açısından kontrol etmeniz gerekir.
Bazı durumlarda, aynı ana bilgisayardaki bazı uygulama rotalarının veya dizinlerinin farklı CSP’lerin ayarlanmış olduğunu fark edeceksiniz. Bunu da mutlaka dikkate alın.
Etkili bir CSP, web sitelerinin XSS ve enjeksiyon saldırılarını caydırmasına yardımcı olabileceği gibi, aynı zamanda güvenli komut dosyalarının yüklenmesini engelleyerek bunları yanlışlıkla kırabilir. Üretimdeki sitelerin bozulmasını önlemek için geliştiriciler, yalnızca rapor modunda yeni bir CSP dağıtacak. Bu modda CSP ihlalleri raporlanır ancak politikanın kendisi hiçbir zaman uygulanmaz. Önceki duruma benzer şekilde, bu, XSS aracılığıyla kesintisiz olarak isteğe bağlı kod yürütmenize olanak tanır.
Bu tür hedefleri bulmak için yanıtta döndürülen HTTP başlıklarını incelemeniz ve Content-Security-Policy-Report-Only başlık. Bu başlık, Google Chrome, Mozilla Firefox ve Safari dahil olmak üzere birden fazla web tarayıcısında yaygın olarak desteklenir. Temel olarak bu web tarayıcılarına yalnızca CSP ihlallerini izlemeleri ve raporlamaları talimatını verir, ancak bunları uygulamamalarını sağlar.
Yalnızca CSP ihlallerini izleyen ancak bunları hiçbir zaman uygulamayan, CSP bypass’larının ortaya çıkmasına izin veren bir hedef
Bir CSP bildirilse bile atlayabileceğimiz kısıtlayıcı olmayan bildirimleri aramalıyız. Çoğu durumda, geliştiricilerin, uygulamayı üretim ortamlarında kullanılamaz hale getirme olasılığını önlemek için bir bildirimi atlamak veya kısıtlayıcı olmayan bir bildirime sahip bir CSP eklemek zorunda kaldıklarını fark edeceksiniz. Neyse ki, bu tür gevşek kapsamlı CSP bildirimlerini tanımlamamıza yardımcı olabilecek açık kaynaklı araçlara erişimimiz var.
Birkaç örneğe bakalım.
script-src aracılığıyla CSP’yi atlamak
Daha önce gördüğümüz gibi, script-src bildirim, tarayıcının hangi komut dosyalarının yüklenmesine ve çalıştırılmasına izin verdiğini belirtir. Bir joker karakter varsa (*) bildirim kaynağı olarak ayarlandığında, herhangi bir kısıtlama uygulanmaz ve harici bir komut dosyası yükleyen basit bir veri yükünün çalıştırılmasına izin verilir:
'">Finding CSP bypasses using Google CSP Evaluator
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdnjs.cloudflare.com https://ajax.googleapis.comdefault-src ensures all other non-explicitly declared declarations are restrictive by default, and the script-src restricts script execution to the same origin and two popular CDNs. However, both of these whitelisted CDNs host vulnerable versions of JavaScript libraries that can be exploited to execute arbitrary code. With a tool like CSPBypass, we can easily find a payload that bypasses the CSP whitelisting:
Finding CSP bypasses using CSP Bypass Search
What is a JSONP endpoint?
4. Bypassing CSP via predictable nonces
A nonce (number used once) is a cryptographic token often declared within a CSP to provide for more granular control of what sources are allowed to execute. When implemented correctly, nonces allow specific inline scripts to execute while blocking all others. However, issues are bound to arise when nonces are weak, predictable, or reused, as they can be exploited to bypass CSP protection. Have a look at the following flawed CSP nonce implementation:Bypassing CSP via predictable nonces
CSP bypass via CSP injection
csp_report_uri parameter, possibly for testing purposes. We can take advantage of this behavior to bypass the current restrictions and still manage to execute arbitrary code:
/?csp_report_uri=/report; script-src * 'unsafe-inline';&vulnerable=CR/LF enjeksiyonunun hala mümkün olduğu eski PHP sürümlerinde, XSS saldırısını kolaylaştıracak ek yanıt başlıklarını enjekte edebilirsiniz. Buradaki anahtar her zaman, halihazırda uygulanan politikayı geçersiz kılmanın olası yollarını aramaktır.
Bağımsız CSP bypass'ları nadiren raporlanmaya değer hatalar olarak görülse de, rastgele JavaScript kodunun yürütülmesine izin verebileceğinden bunların yine de dikkate alınması gerekir. Bu makalede olası İçerik Güvenliği Politikası (CSP) atlamalarını test etmenin birden fazla yolunu araştırdık.
Yani, CSP'leri atlatmakla ilgili yeni bir şey öğrendiniz... Şu anda becerilerinizi test etme zamanı! Savunmasız laboratuvarlar ve CTF'ler üzerinde pratik yaparak başlayabilir veya... Intigriti'deki 70'ten fazla genel hata ödül programımıza göz atabilirsiniz ve kim bilir, belki bir sonraki gönderiminizde bir ödül kazanabilirsiniz!