Content-Security-Policy CSP

Ziyahan Albeniz Özgür Web Teknolojileri Günleri 2016

Kimdir?

Ziyahan Albeniz

● Security Researcher & QA Engineer @ Netsparker● Klavye Delikanlıları (www.klavyedelikanlilari.com) Web Güvenlik Podcast'i● Esperantist● Twitter: ziyaxanalbeniz● ziyahan@netsparker.com

Web Güvenliği Neden Önemli

- Firmaların / Kurumların Dışa Açılan Kapısı- İç ağa yönelik saldırılar için bir sıçrama tahtası.- Ticaret / iş hacmi

Web Cangılında Hayat

- 2016 yılında, - ImageTragick (https://imagetragick.com)- Hacking Team Vakası (http://pastebin.com/raw/0SNSvyjJ)

- Panama Papers

(https://www.netsparker.com/blog/web-security/web-application-security-basics-keeping-sofware-up-to-date/)

- SSL DROWN (https://drownattack.com/)

HTTP Güvenlik Headerları

Response ve Request Headerları, İstek ve yanıtlarda yer alan ve mesaja ilişkin meta bilgiler içeren kısımdır. Tarih, dil tercihleri, credentialslar, içerik boyutu, vb.

Content-Security-Policy (CSP) Nedir?

Sayfamıza hangi kaynakları yükleyebileceğimizi, hangi kaynakların bizi yükleyebileceğini white-list yaklaşımı ile HTTP yanıtlarında belirten bir güvenlik mekanizmasıdır.

- CSP 1 (2012, Kasım)- CSP 2- CSP 3 (Taslak Aşamasında)

İki Anahtar Kelime

Whitelist

Defence In Depth

Defence In Depth

CSP, başta XSS olmak üzere, bir dizi zafiyete karşı korumak için geliştirilmiştir. Fakat uygulamalarımızı bu zafiyetlere (örneğin, XSS) karşı korumak için tek başına yeterli değildir.

Uygulamamızdaki girdileri ve çıktıları kontrol etmeliyiz!

Eğer uygulamamızda bir XSS zafiyeti varsa, CSP nin desteklenmediği bir browserda, CSP headerlarına rağmen, istismar edilebilir.

Whitelist

Neyi kabul etmediğimizi belirten sonsuz listeler yerine, neyi kabul ettiğimizi tek kalemde belirterek, tartışmayı sonlandırabiliriz :)

CSP Implementasyonu

Content-Security-Policy: Chrome v25+, Firefox 23+, Opera 19+, Safari 7+, Microsoft Edge 12 build 10240+.

X-Content-Security-Policy: Internet Explorer 10+,Firefox 4+

X-Webkit-CSP: Chrome v14-v25, Safari 6+

Örnek :

Content-Security-Policy: script-src 'self'

https://apis.google.com

Kontrol Noktalarıbase-uri : <base> element'inde kullanılacak değer ile ilgili kısıt tanımlamamıza yardımcı olur.Böylece Base Tag Hijacking saldırıları engellenebilir.child-src : Deprecated olan frame-src yerine kullanılır. Sayfaya embed edilecek olan framelerin alabileceği kaynak değerleri tanımlar.connect-src: XHR, WebSockets, EventSource ile bağlanılabilecek kaynakları kısıtlar.font-src: Fontların yüklenebileceği kaynakları belirtir.form-action : Form tagları için geçerli action'ları belirtir.frame-ancestors : Mevcut sayfayı frame, iframe, embed ve applet olarak yükleyebilecek kaynakları belirtir. X-Frame-Options'ın muadilidir. Clickjacking vb UI Redressing saldırılarını engellememize yardımcı olur.frame-src : Deprecate edilmiş bir özelliktir. Bunun yerine child-src kullanılabilir.img-src: Resimlerin yüklenebileceği kaynakları tanımlar.media-src: Video ve ses yüklenebilecek kaynakları tanımlar/kısıtlar.object-src: Flash ve diğer plugin'lerin yükleneceği kaynakları tanımlar/kısıtlar.plugin-types: Yüklenebilecek plugin tiplerinini belirler/limitler.report-uri: CSP'nin ihlal edildiği durumda, raporun gönderileceği adresi belirtir.style-src: Stil dosyaları için kaynak tanımlaması/kısıtlaması yapar.upgrade-insecure-requests : HTTP isteklerini HTTPs olarak değiştirir.

Aksi belirtilmedikçe, …

Wide Open Approach: Aksi belirtilmedikçe, bir direktif tanımlanmadıkça kontrol noktaları için denetim ve kısıtlama yapılmaz.

Örneğin, 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 belirtilmedi ise, tüm kaynaklardan stil yüklemesi yapılabilir. (Varsayılan durum)

default-src

Burada tanımlanan değer, -src ile biten pek çok direktif için fallback görevi yapar ve bu direktifler için default 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'dan yüklenebilir.

İstisnalar kaideyi bozmaz

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

base-uri report-uri

form-action sandbox

frame-ancestors

plugin-types

Bir taşla birçok kuş...

Bir veya birden çok direktifi bir HTTP header içerisinde, her talimatı birbirinden noktalı virgül (;) ile ayırarak kullanabiliriz.

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

Bir taşla birçok kuş...

Bir direktifin alacağı muhtelif değerler, boşluk ile birbirinden ayrılmalıdır:

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

Şeytan ayrıntıda gizlidir...

CSP her sayfa için özel tanımlanmalı ve bu sayfanın HTTP yanıtında gönderilmelidir.

Bu, her sayfaya yönelik, onun spesifik ihtiyaçları için en optimum policy'i tanımlamamıza yardımcı olacaktır.

Şeytan ayrıntıda gizlidir...

Kaynağı FQDN olarak belirtebiliriz:

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

Şeytan ayrıntıda gizlidir...

Sadece hostname belirtebiliriz:

script-src example.com

Şeytan ayrıntıda gizlidir...

Ya da sadece şema olarak belirtebiliriz:

script-src https://

script-src data://

Şeytan ayrıntıda gizlidir...

Wildcardlar, port ve URL'in sadece subdomain kısmı için kullanılabilir.

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

script-src https://*.example.com:*

Anahtar Kelimeler

Yine source tanımlarken, bazı özel anahtar kelimeler kullanabiliriz.

'none' : Hiçbiri, Örneğin, object-src: 'none' Sayfada hiçbir obje embed edilmeyecektir.

'self': Mevcut sayfanın origin'i ile eşleşir. Subdomainler de dahil, hiçbir başka kaynaktan yükleme yapılamaz.

'unsafe-inline': inline Javascript ve CSS kullanımına izin verir.

'unsafe-eval': eval gibi text-toJavascript fonksiyonların kullanımına izin verir.

Şeytanın gör dediği...

Bu anahtar kelimeler tek tırnaklar içerisinde kullanılmalıdır. Aksi takdirde, örneğin sadece self değeri girilirse, bu normal bir hostname gibi algılanır ve self kelimesi içeren hostname'lere yetki verilmiş olur.

script-src none

script-src self

sandbox

Bu direktif kullanıldığında, sayfa "sandbox" attribute'ına sahip bir iframe içerisinde yüklenmiş gibi davranmaktadır. Böylece sayfada, script'lerin çalışıp çalışmayacağını, formların gönderilip gönderilmeyeceğini, sayfanın benzersiz (unique) bir origin'de değerlendirilip değerlendirilmeyi talimatı, bu özellik ile birlikte verilmektedir.

Content-Security-Policy: sandbox allow-forms allow-scripts;

Meta Tagları

CSP için tercih edilen yöntem HTTP response'larında direktifleri belirtmek olsa da, CSP'leri meta tagları olarak da belirtebiliriz. Özellikle de paylaşımlı hosting gibi headerlara müdahale edemediğimiz ortamlar için idealdir.

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

child-src 'none'; object-src 'none'">

Ufak bir ayrıntı daha...

Meta tagları ile CSP tanımlarken, aşağıdaki direktifler için kullanılamaz:

frame-ancestors, sandbox, report-uri

Inline Injection

CSP'nin varlık nedenlerinden biri olan XSS için hala büyük bir boşluk var: Inline Injection:

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

javascript:alert(123)

onclick="alert(123)"

Persona non grata!

CSP bu problemi, inline scriptleri engelleyerek çözmektedir. Sadece script tagları arasına gömülmüş kodları değil, inline olay tetikleyecilerini ve javascript: URL'lerini de engellemektedir.

Her işte bir hayr vardır!

Internal scriptler engelleneceği için, kodlarımızı harici dosyalara taşımamız gerekecektir (Externalisation)

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

Nush ile uslanmayan!

CSP'nin çok güçlü bir yanı olan inline blokajını kaldırmayı ve her şeye rağmen inline javascript ve CSS'i hala kullanmak istiyorsanız, ilgili kaynaklara izin verilen direktiflerde bunu ÖZELLİKLE belirtmelisiniz:

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

Nush ile uslanmayan!

Ya da CSP 2 ile birlikte gelen nonce'ları kullanabilirsiniz:

Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'

<script nonce=EDNnf03nceIOfn39fn3e9h3sdfa>

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

</script>

Nush ile uslanmayan!

Script bloklarına, ayrıca bu blokların hash değerleriyle birlikte, CSP talimatları ile beyaz listeye alabilirsiniz:

Content-Security-Policy: script-src

'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='

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

*sha256, sha384,sha512 desteklenmektedir.

Eval=Evil

text-to-JS operasyonu CSP tarafından engellenmiştir:

Eval, new Function(), setTimeOut, setInterval

Eval tamamen engellenmiştir.

setTimeOut ve setInterval fonksiyonlarının da text-to-js fonksiyonları bloke edilmiştir.

Çare Sarıgül!

setTimeout("document.querySelector('a').style.display = 'none';",

10);

yerine

setTimeout(function () {

document.querySelector('a').style.display = 'none';

}, 10);

Derdim bana derman imiş...

Eğer, eval gibi text-to-javascript fonksiyonlarının kullanımı kaçınılmaz ise, "unsafe-eval" talimatını kullanarak, CSP güvenlik mekanizmasında koca bir delik açabilirsiniz.

script-src: 'unsafe-eval'

Reporting

Böylesine katı bir biçimde uygulanan güvenlik politikasını, web uygulamanızın bir parçası haline getirmekte tereddütleriniz olabilir. Report özelliği sayesinde, CSP'yi kısıtlayıcı modda değil, yalnızca ihlallerin bildirilmesi amacıyla kullanabilirsiniz. Böylece CSP'yi uygulamanıza bir güvenlik mekanizması olarak dahil etmeden önce, uygulamanızdaki hal ve gidişatı da izlemiş olursunuz:

Content-Security-Policy-Report-Only: default-src 'self'; ...;

report-uri /my_amazing_csp_report_parser;

[*]https://blogs.dropbox.com/tech/2015/09/on-csp-reporting-and-filtering/

Reporting

Best Practice olarak, henüz web sitenizde kullanılmayan bir CSP'yi önce Report modunda devreye alarak, uygulamanızın CSP entegrasyonuna ne kadar hazır olduğunu ve bu muazzam değişikliğin sayfalarınızı nasıl etkileyeceği görebilirsiniz. Github, Dropbox gibi örnek hikayeler bu hususta faydalı olacaktır.

Content-Security-Policy-Report-Only: default-src 'self'; ...;

report-uri /my_amazing_csp_report_parser;

[*]https://blogs.dropbox.com/tech/2015/09/on-csp-reporting-and-filtering/

[**]http://githubengineering.com/githubs-csp-journey/

Reporting

{ "csp-report":

{

"document-uri": "http://example.org/page.html",

"referrer": "http://evil.example.com/",

"blocked-uri": "http://evil.example.com/evil.js",

"violated-directive": "script-src 'self' https://apis.google.com",

"original-policy": "script-src 'self' https://apis.google.com; report-uri

http://example.org/my_amazing_csp_report_parser"

}

}

Reporting

document-uri: İhlalin olduğu sayfayı

referer: Sayfamızın referer'ini

blocked-uri: Bloke edilen kaynağı

violated-directive: İhlal edilen güvenlik direktifini.

origin-policy: CSP direktiflerini belirtir.

CSP 3 - Nonce Based CSP

Google tarafından yayınlanan son makalede[1], CSP tanımlarındaki whitelist yaklaşımının yumuşak karnı detaylı incelenirken; buna karşılık, nonce-based olarak adlandırılan yeni bir yaklaşım önerilmektedir.

Araştırma 1 milyon 687 bin hostname'i ve 26 bin tekil CSP headerı kapsıyor. Bugüne kadarki en büyük güvenlik analizlerinden biri olan rapora göre, CSP'yi bypass etmek için tespit edilen 3 yaygın yöntem analiz ediliyor. Bunlar Open Redirection, Insecure JSONP Endpoint ve AngularJS CSP Compability Mode.

[1] CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future of Content Security Policy, http://research.google.com/pubs/pub45542.html

CSP 3 - Nonce Based CSP

Script yüklemelerinde, whitelist'e alınan 15 domain'in 14'ünde insecure endpoint zafiyeti belirlendiği belirtilen raporda, bu noktalardan yapılacak atakların CSP policy'lerini etkisiz hale getirmesinin kaçınılmaz olduğu ifade ediliyor.[1]

[1] "We observe that 14 out of the 15 domains most commonly whitelisted for loading scripts contain unsafe endpoints; as a consequence, 75.81% of distinct policies use script whitelists that allow attackers to bypass CSP."

CSP Bypass - Open Redirection:

Content-Security-Policy: script-src example.org;

// Allows loading of untrusted resources via:

<script

src="//example.org?redirect=partially-trusted.org/evil/script.js"

>

CSP Bypass - Insecure JSONP Endpoint

<script src="/api/jsonp?callback=evil"></script>

CSP Bypass - AngularJS CSP Compability Mode

<script src="angular.js"></script>

<div ng-app>{{ executeEvilCodeInUnsafeSandbox() }} </div>

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.

Bunun için CSP spesifikasyonuna strict-dynamic kullanımını öneren Google, kendi browserlarında bu yöntemi desteklemeye başladı bile. Google dışında Opera tarafından da strict-dynamic kullanımı desteklenmektedir.

strict-dynamic

example.com/map.js üzerinden bir script yükleyeceğiniz. Bunun için bir CSP tanımladığımız varsayalım:

Content-Security-Policy: script-src example.com;

strict-dynamic

example.com'a güveniyoruz ve çalışma zamanında DOM'a yükleyeceği nesneler CSP engeline takıldığı için, 'unsafe-inline' direktifleriyle, CSP'imizde bize göre küçük bir esneklik, saldırganlara göre ise koca bir gedik açtık:

Content-Security-Policy: script-src example.com 'unsafe-inline';

strict-dynamic

Üstelik bunu yaparken daha en başından, example.com domainini beyaz listeye alarak, example.com 'da olaşabilecek başka saldırı parametrelerinden de sitemizdeki CSP korumasının bypass edilmesine kapı araladık.

example.com 'da bir Open Redirection olduğunu varsayalım:

example.com/redirectme.php?go=http://attacker.com/bad.js

strict-dynamic

Bunun yerine, nonce-based CSP 'i kullansa idik, pek çok saldırı parametresini ortadan kaldıracaktık:

Content-Security-Policy: script-src 'nonce-random-123' 'strict-dynamic';

<script src="http://exampe.com/map.js" nonce=random-123></script>

strict-dynamic

Content-Security-Policy: script-src 'nonce-random-123' 'strict-dynamic';

<script src="http://exampe.com/map.js" nonce=random-123></script>

Sadece example.com/map.js üzerinden yüklenen script'e güvendiğimizi, script'in yüklendiği bloka bir nonce değeri atayarak, güvenli olarak belirttik. Yine strict-dynamic talimatları ile de, bu blok içerisinden yapılacak yüklemelere izin verdiğimizi belirtmiş olduk.

Böylece hem koca bir example.com etki alanını whitelist'e almak zorunda kalmadık; hem de dinamik yüklemeler için başka saldırılara da kapı aralayarak 'unsafe-inline', 'unsafe-eval' gibi talimatları kullanmamış olduk.

Geçmişin Ağır Yükü: Geriye Uyum!

Nonce sadece CSP 2 ile birlikte destekleniyor. strict-dynamic yapısı ise, CSP 3 ile birlikte gelen özelliklerden.

Nonce'ı kullandığınız takdirde, eğer ziyaretçi browserı CSP 2'yi desteklemiyorsa ne olacak?

Buna çare olarak, yani bir geriye uyum olarak nonce ile birlikte 'unsafe-inline' talimatı da kullanılması öneriliyor.

Endişeniz yersiz değil! Buradaki amaç kısaca şu:

Geçmişin Ağır Yükü: Geriye Uyum!

Content-Secutity-Policy: script-src 'nonce-random123' 'unsafe-inline'

<script nonce=random123>

console.log("code works");

</script>

Nonce kullanıldığında, unsafe-inline kullanımı browser tarafından ignore ediliyor. Yani CSP 2 ve üzeri sürümleri destekleyen browser'larda bu satırdaki 'unsafe-inline' talimatı yok sayılacak. nonce talimatının tanınmadığı, yani CSP 1'in desteklendiği browser'larda ise 'unsafe-inline' çalışacak ve sayfanınızın bütünlüğü bozulmayacak, yani kodlarınız çalışacak.

Geçmişin Ağır Yükü: Geriye Uyum!

strict-dynamic'de ise geriye uyum için önerilen implementasyon şöyle:

Content-Security-Policy: script-src 'nonce-random123' 'strict-dynamic' https: http:

strict-dynamic kullanımı ile birlikte, CSP 3 ve üzeri sürümlerin desteklendiği browser'larda, CSP talimatındaki https: ve http: talimatları ignore edilecek.

Kuşbakışı CSP

Web uygulamanıza implemente ettiğiniz CSP 'nin özet bir değerlendirmesini ise Mozilla Firefox 43 sürümü ile birlikte gelen Developer Toolbar üzerinden security csp komutunu kullanarak yapabilirsiniz.

Ya da

Google CSP Evaluator:

https://csp-evaluator.withgoogle.com/

Manzara-i Umumiyye

Dr. Emin İslam Tatlı ve Koray Emre Kısa tarafından yapılan Türkiye Güvenlik Headerları Analizi (Analysis of HTTP Security Headers in Turkey ) araştırmasına göre[1], Alexa Top 500 Turkey'de siteler incelendi.

- Google gibi uluslararası portallar bu siteden çıkarıldığında, değerlendirme 370 site üzerinden yapıldı. Bu siteler, Medya, Finans, Telekominikasyon ve Hükümet siteleri gibi 18 ayrı kategoriye ait siteler.

- Bu sitelerin sadece 6 tanesinin CSP headerları implemente implemente ettiği görülüyor.

- Bu sitelerin %60'ında hiçbir güvenlik headerı yok.

[1] https://www.researchgate.net/publication/307931790_Analysis_of_HTTP_Security_Headers_in_Turkey

Kaynaklar

https://www.netsparker.com.tr/blog/web-guvenligi/CSP-Content-Security-Policy/

Ya da

https://tinyurl.com/cspnedir?

Sorular

Twitter: ziyaxanalbeniz

E-mail: ziyahan@netsparker.com