Bu yazı 03.02.2020 tarihinde kaleme alınmıştır.
Yepyeni Hap Bilgi serisine hoşgeldiniz. Bu seride mümkün olduğunca konulara en özet, en hızlı ve best practice yansıtacak şekilde bakmaya çalışacağım.
Bu yazıda Content Security Policy(CSP), Same Origin Policy(SOP) ve Cross Origin Request Sharing(COSR) konularını inceleyeceğiz.
CSP — Content Security Policy
CSP — Content Security Policy Nedir?
Content Security Policy, web uygulamamız veya bir web sitemizi ziyaret eden kullanıcıların web browser’larına güvenlik amacıyla belirli komutlar yollayabildiğimiz bir politikalar bütünüdür.
XSS (Cross-Site Scripting) saldırıları başta olmak üzere frame injection, clickjacking, Protocol Downgrading vb saldırıların engellenmesi CSP sayesinde mümkün olmaktadır. Ancak burada çok önemli bir nokta vardır. CSP, sadece kendisini destekleyen browserlarda çalışmaktadır. Destek bulunmayan bir browser üzerinden yine saldırılar yapılabilecektir.
CSP bize ek bir güvenlik katmanı sunmaktadır. Tek başına sistemimizin güvenliği için yeterli olmamakla birlikte doğru konfigürasyonla birlikte çok kullanışlı bir güvenlik katmanı olabilmektedir.
Temel olarak CSP’de whitelist olarak bilinen, kural tanımlarken sadece izin verilenlerin geçebileceği bir yaklaşım kullanılmaktadır.
CSP’nin bugüne kadar duyurulmuş 3 ve yayınlanmış 2 sürümü vardır.
- CSP 1
- CSP 2
- CSP 3 (Yapım Aşamasında)
CSP — Content Security Policy Neden Var?
CSP’nin var olmasının nedeni, kötü niyetli saldırganların web application’ımız üzerinde zafiyet bulmasını veya onu sömürmesini engellemek amacıyla belirli bir kurallar dizisi oluşturmak ve bu kuralları kullanıcının web browser’ına iletmektir.
CSP — Content Security Policy Nasıl Çalışır?
Yazımızın başında whitelist mantığı ile çalıştığından bahsetmiştik. Şimdi ise bunu biraz daha açalım.
Oluşturacağımız whitelist sayesinde sadece bizim izin verdiğimiz veya kabul ettiğimiz çalışma şeklinin çalışmasını, izin vermediklerimizin kullanımını önlemiş oluruz. Bu kaynakların neler olduğunu HTTP response’ları ile beraber gönderdğimiz CSP talimatlarında belirtmemiz yeterli olacaktır.
Content Security Policy’nin nasıl çalıştığının daha detaylı anlaşılabilmesi için bir web sitesine giderken arka planda tarayıcının ne gibi davranışlar sergilediğini bilmemiz faydalı olacaktır. Bu nedenle burayı tıklayarak ilgili yazıyı okuyabilirsiniz.
Bir saldırgan gözü ile baktığımızda;
Not: aşağıda özet olarak bahsedilen konuyu daha detaylı incelemek için lütfen tıklayın.
Bir web sitesine giderken tarayıcımız girdiğimiz URL üzerinden IP adresini bularak gitmek istediğimiz sunucuya GET metoduyla (direkt olarak url’ye gitmek istediğimiz adresi girdiysek) istekte bulunur. Eğer gitmek istediğimiz yer ilgili sunucu da mevcut ise http 200 durum kodu döner ve sayfanın text hali yine GET metodu ile gönderilir. Eğer ilgili sunucuda sayfa mevcut değilse 404 durum kodlu bir HTTP paketi gönderilir.
Tarayıcımız bu aşamada gelen sayfa kaynak kodunu inceleyerek diğer istekleri (CSS, Js, images vs) parse etmeye başlar. Bu aşamada output validition ve input filtering yapılmayan sistemlerde zafiyet açığa çıkmaktadır. Tarayıcı olduğu gibi tüm istekleri alıp cihazın temp klasörüne indirecektir. Bu nedenle zararlı dosyaların sitenin ziyaretçilerine bulaştırılması söz konusu olacaktır. Tam bu aşamada CSP çalıştırmak bunun önüne geçecektir. Ancak yine tekrarlamak istiyorum. CSP desteği olmayan browserlarda CSP bir işe yaramayacaktır.
CSP’yi headerlar aracılığıyla gönderdiğimizden bahsetmiştik. CSP headerı nasıl oluyor derseniz bir örnek paylaşalım:
Content-Security-Policy: KONTROL_ALANI değerler
script-src ‘strict-dynamic’ ‘nonce-rAnd0m123’ ‘unsafe-inline’ http: https:;object-src ‘none’;base-uri ‘none’;report-uri https://csp.example.com;
CSP headerları sayesinde neler yapabileceğimize biraz daha yakından bakalım. Aşağıda kısaca bilgilerini vermiş olduğumuz değerler varsayılan olarak tüm kaynaklardan yüklemelere izin vermektedir. Örneğin style.src için bir değer belirtilmediği takdirde herhangi bir kaynaktan stil yüklenmesine izin verilecektir. Ne kadar tehlikeli olduğunu fark edebiliriz.
base-uri
child-src
connect-src
font-src
form-action
frame-ancestors
frame-src
img-src
media-src
object-src
plugin-types
report-uri
style-src
upgrade-insecure-request
What if?
Şimdi de işin püf noktalarına bakalım.
- CSP her sayfa için özel olarak tanımlanmalıdır. Tanımlandığı sayfanın http yanıtında bu policy gönderilmelidir.
- Bu sayede her sayfaya aynı policy belirlemek yerine her sayfanın kendine özgü ihtiyacını karşılayacak ayarlamaları yapmamız mümkün olacaktır.
- Direktifler tanımlanırken dilersek sadece hostname veya şema, ya da FQDN olarak belirtilebilmektedir.
- CSP source tanımlanırken bazı özel anahtar kelimeler kullanmamıza müsaade etmektedir. Örneğin none, self gibi. Ancak bunları kullanırken mutlaka tek tırnak içerisinde yazmalıyız.
- Headerlara müdahale edilemeyen durumlarda dilersek CSP’yi meta tag olarak da düzenleyebiliriz. Ancak meta tag olarak tanımlama yapıldığında bazı özel direktifler kullanılamamaktadır. Bunları dikkat edilmesi önerilir.
- Nonce’lar her istek için yeniden oluşturulmalı, kendi içinde tekrarlamamalı ve tahmin edilemeyecek kadar güçlü olmalıdırlar. Aksi takdirde bir güvenlik açığı oluşacaktır.
Peki CSP ByPass edilemez mi? Bu sorunun cevabı hiçbir teknoloji için maalesef net bir şekilde hayır olmaktan çok uzak. Elbette hacker’ların elinden hiçbir şeyin kurtulmadığı gibi bu da kurtulamıyor.
Google tarafından yayınlanan bir makalede (buraya tıklayarak makaleye erişebilirsiniz) CSP’nin ByPass edilmesi için tespit edilen 3 yaygın yöntem analiz edilmiş. Bu yöntemlerde, CSP ByPass — Open Redirection, CSP ByPass — Insecure JSONP Endpoint ve CSP ByPass — AngularJS CSP Compability Mode’dur.
SOP — Same Origin Policy
SOP — Same Origin Policy Nedir?
Same Origin Policy (SOP) Protokol, domain ve port bilgilerinin kontrol edildiği bir güvenlik protokolüdür.
SOP, aynı originde bulunan kaynakların birbirlerine erişimine izin veren bir güvenlik katmanıdır. SOP’a göre protokol, domain ve portu farklı olan kaynakların birbirleri ile iletişiminin kısıtlanarak güvenlik sağlanmasıdır. Örneğin serhanbahar.com’a gitmeye çalıştığımızı varsayalım. HTTPS bağlantısı kullanılacağı için aşağıdaki bilgiler ile erişim yapılıp yapılmadığı kontrol edilecektir.
Protokol: HTTPS
Domain: serhanw.me
Port: 443
Tarayıcı tarafından yapılan istekte üzerine dönen verilerde yukarıdaki verilerden biri bile farklı olursa SOP sayesinde cevap işlenmez.
SOP — Same Origin Policy Neden Var?
Bir web sitesine girdiğimiz zaman o siteler bize tarayıcı aracılığıyla cookie’ler bırakır. Cookie’lerin storage edildiği yer değiştirilmediği sürece aynıdır. Cookie’nin güvenlik açısından önemine dair yazıyı buraya tıklayarak okuyabilirsiniz.
Cookie’ye sahip olan kişi ilgili siteye herhangi bir doğrulama olmadan girebilir. Bir de JavaScript’in cookie’ye erişebildiği bilgisini ekleyelim. Bir de tarayıcının cihazımız üzerinde kod çalıştırabildiğini ekledik mi tehlike çanları çalıyor. İşte bunların birleşimi sonucunda SOP neden var sorusunun cevabı ortaya çıkıyor.
Günümüzde neredeyse tüm modern tarayıcılar bu policy’yi kabul etmekte ve permissionları buna göre vermektedir.
SOP — Same Origin Policy Nasıl Çalışır?
SOP’un nasıl çalıştığını aşamalarla anlatan bir kaynağımız var. Öncelikle bunu alıntılayalım ve inceleyelim.
- B kaynağındaki bir script ‘i yükleyerek, kendi kontekstinde çalıştırılabilir.
- B kaynağındaki bir script’in raw koduna, source koduna erişemez.
- B kaynağındaki CSS’leri yükleyebilir.
- B kaynağındaki CSS’lerin raw-text haline erişemez.
- B kaynağındaki bir sayfayı iframe ile kendisine dahil edebilir.
- B kaynağından yüklediği bu iframe’in DOM’una erişemez.
- B kaynağındaki bir resim yükleyebilir.
- B kaynağından yüklediği bu imajin bit’lerine erişemez.
- B kaynağındaki bir videoyu çalıştırabilir.
- B kaynağından yüklediği bu video’nun imajlarını capture edip, tekrar oluşturamaz.
Yukarıdaki akışa baktığımızda bir web sitenin domainini değiştirerek site üzerinden elementlere ulamamız mümkün olmayacaktır.
What if?
Şimdi de işin püf noktalarına bakalım.
- XMLHTTPRequest çağrısını farklı origin’e yapabiliriz ancak cevap alamayız.
- Aynı origin’e çağrı yapılırsa cevabı okuyabiliriz.
- Çağrı yaptığımız kaynak aynı originde ise custom header eklenebilmektedir.
- JSONP çağrısı yapılan sitenin kaynağının güvenilir olup olmadığı doğrulanmalıdır. Aynı zamanda bu isteğin SSL gibi güvenli bir kanal üzerinden yapılması da ekstra güvenlik önlemi olacaktır.
COSR — Cross Origin Request Sharing
Cross Origin Request Sharing yani CORS bir önceki konumuz ile de biraz ilişkili. Adından da anlaşılacağı üzere farklı merkezler arası kaynak paylaşımıdır. Birbirinden farklı domain isimleri üzerinde kaynak paylaşımının sınırlanmasının esnetilmesi olarak belirtebiliriz.
SOP sayesinde tarayıcıların zararlı bir domainin aynı tarayıcıda açılan diğer sitelerin cookie bilgilerinin çalınmasını engellediğinden bahsetmiştik. Bazen geliştirdiğimiz web uygulamalarına farklı domainlerden erişim için izin verme ihtiyacı ortaya çıkabilir. Bu gibi durumlarda CORS policy devreye girer.
Bir örnekle bunu somutlaştıralım. Serhanbahar.com üzerinde yer alan bazı modüllerin çalışması için serhan-bahar.com/data.json sitesinin API servisinden XMLHTTPRequest oluşturarak veri çektiğimizi düşünelim. Burada farklı domainler olduğunu fark edebilirsiniz. Normal şartlar altında gelen talepte ve dönen cevaptaki domainler birbirinden farklı olacağı için SOP bunu kabul etmeyecektir. Eğer CORS ile bir policy belirlenirse SOP’un bunu kabul etmesini sağlayabiliriz.
-Ek Bilgi-
Web sitelerinin CSP’ni kontrol etmek isterseniz: https://observatory.mozilla.org/
CSP düzenlemesinde yardıma ihtiyaç duyarsanız: https://csp-evaluator.withgoogle.com/
Kaynaklar:
https://www.netsparker.com.tr/blog/web-guvenligi/csp-content-security-policy/#ftnt1
https://onaymetinkivilcim.com/content-security-policy/
https://www.netsparker.com.tr/blog/web-guvenligi/same-origin-policy/
