Content Security Policy (CSP) Nedir?

İçerik Güvenliği Politikası (CSP) olarak adlandırılan, bir tarayıcının belirli bir web sayfasında hangi konumdan hangi alanları,alt alanları hangi kaynak türlerinin yükleneceğine izin verme konusunda talimat oluşturma imkanı sunan ek bir güvenlik katmanı ya da tarayıcı güvenlik standardı diyebiliriz. CSP tarayıcıya belirli alandan javascript kaynakları yüklenmesini ve de sitemizde çalışan inline javascript’i engellememize yardımcı olur. Bu sayede XSS, Formjacking, SQL Enjeksiyonu tarzı saldırılar algılanıp, azaltılabilir.

Resim-1

CSP oldukça faydalıdır bunun sebebi tarayıcıları hedef alan birçok saldırıyı önlemesidir. Neden kullanılmalı sorusuna;

• Siteler Arası Komut Dosyası Yazma (XSS) ve Formjacking : Saldırgan ödeme sayfanıza kod ekleyebilir bu aşamada CSP otomatik olarak ödeme bilgilerimizi saldırganın etki alanına göndermez.
• Reklam Enjeksiyonu : Kötü amaçlı yazılı ile kullanıcı tarayıcısında çeşitli reklamlar görüntülenebilir. CSP ile bu tarz reklamların yüklenmesini engellemiş oluruz.

Bunların yanı sıra CSP’yi yapılandırırken oldukça dikkatli olmalıyız çünkü aldığımız rapor sayısı bir anda artabilir ve bunu kontrol edemeyebiliriz site girişlerini felç edebiliriz ya da CSP’nin uyumlu olmadığı tarayıcılarda kullanılan headerlara rağmen zafiyet olabilir. Ama CSP; Chrome, Internet Explorer, Edge, Safari, Firefox, Opera olmak üzere birçok tarayıcı ile uyumludur.

İçerik Güvenliği Politikası Nasıl Çalışır?

İlk olarak CSP’de neyi,neleri engelleyeceğimizi düşünmek yerine nelere izin vermemiz gerektiğini düşünmeyle başlayabiliriz yani whitelist olarak bilinen yaklaşım ilk adımımız olacaktır. Whitelist yaklaşımı sayesinde, yalnızca kabul ettiğimiz kaynakları belirtip oluşturduğumuz list ile eşleşmeyen kaynakları engelleyebiliriz. Bu kaynakların hangileri olacağını HTTP response’ları ile beraber döndürdüğümüz CSP talimatlarında belirtmemiz yeterli olacaktır.

Content-Security-Policy: script-src 'self' https://www.mshowto.org

Resim-2

Resim-2’deki CSP talimatı ile sayfamızda “self” ve ” https:// ” ile belirtiğimiz adres üzerinden yüklenecek scriptlere izin verip, inline script çağrımları ve olay tetikleyicileriyle script çalıştırmak olumsuz sonuçlanacaktır.

Whitelist bazı durumlarda iyi gibi görünmesine karşın saldırgan tarafından başarılı olan yetkisiz erişim ile eski kütüphaneleri kullanabilir. Bu talimat alan sahibi tarafından güvenilir alanlara uygulanmalıdır.

CSP sayesinde, yalnızca belirttiğimiz kaynaklardan yapılacak script ve style yüklemelerini değil; hangi kaynaklardan yapılan embeding’lere izin verileceğini; hangi kaynakların iframe olarak yükleneceğini ya da hangi kaynakların sayfaya iframe olarak yükleyebileceği gibi pek çok HTML unsurunu kontrol edebiliriz.

Content-Security-Policy: KONTROL_ALANI degerler

RESİM-3

Resim-3 de örnek CSP headerı görüyoruz.

Direktifler

Resim-4

CSP headerı ile birlikte, aşağıda sıralayacağımız kontrol alanlarındaki kaynak kullanımlarını sınırlandırabilir, tanımlayabiliriz.

• base-uri : Base elementi, sayfadaki tüm relative URL’lerin kendisine çözümleneceği absolute URL’i belirtilen bir değerdir. <base> elementinde kullanılacak değer ile ilgili kısıt tanımlamamıza yardımcı olur. Böylece Base Tag Hijacking saldırıları engellenebilir.
• block-all-mixed-content
• child-src: Deprecated olan frame-src yerine kullanılır. Sayfaya embed edilecek olan framelerin alabileceği kaynak değerleri tanımlar. Sayfamızı Frame Injection saldırılarına karşı koruyabilmek için, ek bir tedbir olarak kullanabiliriz.
• connect-src : XHR, Web Sockets, EventSource ile bağlanılabilecek kaynakları kısıtlamamıza yardımcı olur.  Eğer izin verilmeyen kaynaktan bir sorgulama yapılırsa tarayıcından 400 HTTP kodu döner.
• default-src : Burada tanımlanan değer, -src ile biten pek çok direktifin varsayılan değer tanımlamak için kullanılır. Eğer default-src ‘i http://www.example.com olarak tanımlandı ise ve font-src ‘ye bir değer vermediysek bu durumda fontlar yalnızca https://www.example.comadresinden yüklenir.
• font-src : fontların yüklenebileceği kaynakları belirtir.
• form-action : form tagları için geçerli olan action’ları belirtir.
• frame-ancestors : mevcut sayfayı, frame, iframe, embeded ve applet olarak yükleyebilecekleri kaynakları belirtir. X-Frame-Options’in bir benzeridir. Clickjacking, UI Redressing vb.. saldırıları engellememize yardımcı olur. Bu direktifi ‘none’ olarak ayarlamak X-Frame-Options: DENYile aynıdır.
• frame-src : Sayfayı embed edilecek olan framelerin alabileceği kaynak değerleri tanımlar. Sayfamızı Frame Injection saldırılarına karşı koruyabilmek için ek bir tedbir olarak kullanılır.
• img-src : Resimlerin yüklenebileceği kaynakları tanımlar.
• media-src : Geçerli ses veya görüntü kaynaklarını tanımlar.
• manifest-src : Manifest dosyasının kaynağını tanımlar.
• object-src : Flash ve diğer pluginlerin yüklenebileceği kaynakları tanımlar.
• plugin-types : Yüklenebilecek plugin MIME tiplerini belirler veya kısıtlar.
• report-uri : Belirttiğiniz direktiflerin ihlali durumunda bir JSON nesnesinin POST edileceğini URI.
• sandbox : Sandbox modu sayesinde birçok etkinliği kısıtlayabilirsiniz. Popupları engeller, formları durdurur, javascriptleri çalıştıramaz hale getirebilirsiniz. Sandbox direktifi için boş değer tanımlarsanız aşağıdaki listenin tümünü tanımlamış sayılırsınız yada sadece seçtiklerinizi çalışmasını sağlayabilirsiniz.
  • allow-form
  • allow-same-origin
  • allow-scripts
  • allow-popups
  • allow-modals
  • allow-orientation-lock
  • allow-pointer-lock
  • allow-presentation
  • allow-popups-to-escape-sandbox
  • allow-top-navigation
• script-src : Geçerli javascript kaynaklarını tanımlar.
• style-src : Stil dosyaları için kaynak tanımlanması yapar.
• upgrade-insecure-requests : HTTP isteklerini HTTPs olarak değiştirir.
• worker-src : Worker dosyalarının kaynaklarını tanımlar.

Bu değerlerde varsayılan olarak benimsenen yaklaşım “Wide Open” olarak bilinen yaklaşımdır. Yani CSP headerlarında, yukarıdaki alanlar için bir değer belirtilmez ise, bu alanlar için herhangi bir kaynaktan yapılan yüklemelere izin verilecektir. Örneğin style-src için bir değer belirtilmezse, bu style-src: * olarak kabul edilecek ve tüm kaynaklardan stil yüklemeye izin verilecektir.

Bu davranışı değiştirmek için default-src direktifini kullanabiliriz. Burada tanımlanan değer, -src ile biten pek çok direktifi override ederek, bu direktifler için default bir değer tanımlar. Eğer default-src’i http://www.example.com olarak tanımladı isek ve font-src’ye bir değer vermediysek bu durumda fontlar da yalnızca https://www.example.com adresinden yüklenebilir.

Aşağıdakiler, default-src tanımınının override edemeyeceği direktiflerdir:

• base-uri
• form-action
• frame-ancestors
• plugin-types
• report-uri
• sandbox

script-src https://host1.com https://host2.com; style-src https://www.example.com

Resim-5

Resim-5’te Bir veya birden çok direktifi bir HTTP header’ı içerisinde, her talimatı birbirinden noktalı virgül (;) ile ayırarak kullanılabiliriz.

script-src https://host1.com https://host2.com;

Resim-6

Resim-6’da Bir direktifin alacağı muhtelif değerler, boşluk ile birbirinden ayrılmalıdır.

CSP’de Görmezden Geldiğimiz Ayrıntı

Nasıl elimizdeki bir anahtarla her kapıyı açamıyorsak oluşturduğumuz CSP ‘nin her sayfa/tarayıcıda optimize çalışmasını bekleyemeyiz. CSP’yi her sayfa için özel tanımlamalı ve de sayfanın HTTP yanıtında gönderilmesine dikkat etmeliyiz. Bu, her sayfaya yönelik ihtiyaçlarımız dahilinde en uygun policy’yi tanımlamamıza yardımcı olacaktır. Bu durumu direktif tanımlamalarında bazı esnekliklere giderek kolaylaştırabiliriz;

1. Kaynağımızı FQDN olarak belirtebiliriz;

script-src https://www.example.com:443

1. Sadece Hostname belirtebiliriz;

script-src example.com

1. Sadece şema olarak belirtebiliriz;

script-src https:script-src data:

1. Source tanımlarken anahtar kelimeler kullanabiliriz. Bunları tek tırnak içinde kullanmalıyız yoksa header bunu normal bir hostname gibi algılar ve anahtar kelimemizi içere hostname’lere yetki vermiş oluruz. Kullanabileceğimiz anahtar kelimelerimiz;

• ‘none’ : Hiçbiri. Örneğin, object-src: ‘none’ talimatı nedeniyle sayfada hiçbir obje embed edilemeyecektir.
• ‘self’: Mevcut sayfanın origin’i ile eşleşir. Subdomainler de dahil, başka hiçbir kaynaktan yükleme yapılamaz.
• ‘unsafe-inline’: inline Javascript ve CSS kullanımına izin verir.
• ‘unsafe-eval’: eval gibi Text-to-Javascript fonksiyonların kullanımına izin verir.

1. Sandbox direktifinde diğer direktifler gibi sayfanın yüklendiği kaynağı değilde,sayfanın kendisini kısıtlar. Direktifi kullandığımızda, sayfamız “sandbox” attiribute’ına sahip iframe içerisine yüklenmiş gibi davranır.

Content-Security-Policy: sandbox allow-scripts;

MEGA TAGLAR

Yazımızın şimdiye kadarki olan kısımlarında CSP için http response’larında direktif belirtmek üzerine oldu. Peki CSP’yi mega taglar içinde nasıl tanımlayabiliriz nerelerde kullanabiliriz?

Mega tagları paylaşımlı hosting gibi headerlara müdahale edemediğimiz durumlarda oldukça işimize yarayacaktır.

<meta http-equiv=”Content-Security-Policy” content=”default-src https://cdn.example.net;

child-src ‘none’; object-src ‘none'”>

Resim-7

Mega tagları ile aşağıdaki direktifleri kullanamayız;

• frame-ancestors
• sandbox
• report-uri

Inline Injection

Belki de bu makaleyi yazmama sebep olan XSS için hala yeterli çözümü bulabilmiş değiliz ve bizim bu konudaki kriptomuz “inline injection”

<script>alert(123);</script>

<a href= onclick=”javascript:alert(123)”>Click me!</a>

<img src=1 onerror=”alert(1);”/>

Resim-8

CSP inline scriptleri engelleyerek sorunu çözmektedir. Sadece script tagları arasına gömülmüş kodları değil, inline olay tetikleyecilerini ve javascript: URL’lerini de engellemektedir. Bu sebeple script tagları arasındaki kodlarımızı harici dosyalar olarak yeniden sayfalarımızda yüklememiz gerekecektir. Bu sayade;

• External dosyalar cachelenir, performans artışı.
• Minimizing, obfuscation, saldırganların adımlarını geriletir.
• Daha düzenli kodlar!
  

Bütün bu faydalara rağmen inline Javascript ve CSS’i hala kullanmak istiyorsak, ilgili kaynaklara izin verilen direktiflerde bunu ayrıca belirtmeliyiz:

 script-src: 'unsafe-inline'; style-src: 'unsafe-inline'
					

Resim-9

Content-Security-Policy: script-src ‘nonce-EDNnf03nceIOfn39fn3e9h3sdfa’

<script nonce=EDNnf03nceIOfn39fn3e9h3sdfa>

//Some inline code I cant remove yet, but need to asap.

</script>

Resim-10

Resim-10’da Inline/embeded scriptleriniz için kriptografik nonce’lar kullanabiliriz. Güvenlik tedbiri olarak nonce’lar her istek için yeniden oluşturulmalı, tekrarlanamaz ve tahmin edilemez olmalıdır.

Content-Security-Policy: script-src 

'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='

<script>alert('Hello, world.');</script>

Resim-11

Eval=Evil

Text-To-JS operasyonu CSP tarafından engellenmiştir.

• Eval
• New Function()
• setTimeOut
• setInterval

  setTimeout(function () {
  

  document.querySelector(‘a’).style.display = ‘none’;
  

  }, 10);
  

Resim-12

script-src: ‘unsafe-eval’

Resim-13 Eğer, eval gibi Text-to-Javascript fonksiyonlarının kullanımı kaçınılmaz ise, “unsafe-eval” talimatını kullanabiliriz.

Resim-14

Strict-Dynamic: Whitelist temelli CSP politikaları kullanmak yerine, nonce-based olarak isimlendirilen bir yaklaşım öneren Google, dinamik yüklemeler ile birlikte, CSP policylerimizi kevgire çevirmeden, duruma hakim olmamızı sağlıyor.

CSP Hata Mesajları

• Chrome’da geliştirici araçlarında Content-Security-Policy kurallarını ihlal ettiğinizde aşağıdaki hatayı alırsınız:

“Refused to load the script ‘script-uri’ becaouse it violates the following Content Security Policy directive: “your CSP directive”.

• Firefox’da ise web geliştirici araçlarında herhangi bir kural ihlal edildiğinde aşağıdaki hatayı alırsınız:

“Content-Security Policy: A violation occurred for report only CSP policy (“An attempt to execute inline scripts has been blocked”). The behavior was allowed and a CSP report was sent.”

Bu konuyla ilgili sorularınızı  alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.

Referanslar

www.mshowto.org

https://www.owasp.org/index.php/Content_Security_Policy

https://content-security-policy.com/

https://www.rahulpnath.com/blog/http-content-security-policy-csp/

TAGs: Content Security Policy nedir?,CSP Nedir?,Http content security policy