İçerik ve Güvenlik Politikası (CSP), Cross Site Scripting (XSS) Siteler Arası Betik (Script) Çalıştırma (Cross Site Scripting), Genellikle web uygulamalarında bulunan bir tür bilgisayar güvenlik açıklığıdır. saldırıp tipleri olmak üzere belirli saldırıları ve saldırı türlerini tespit etmeye ve engellemeye yardımcı olan ek bir güvenlik katmanıdır. Bu saldırılar, veri hırsızlığından veya kötü amaçlı yazılımların dağıtılmasına kadar bir çok alanda farklı şekillerde kullanılır. Kısaca, sitemize hangi kaynakları yükleyebileceğimizi veya hangi kaynakların bizim sitemizi yükleyebileceğini belirtilen güvenlik mekanizmasıdır. CSP bir defence-in-depth (derinliğine savunma) olarak değerlendirilip, zafiyetin giderilmesi konusunda gerekli geliştirmelerin mutlaka yapılması gerekir.

CSP bugüne kadar üç sürümü duyrulmuş ve 2 sürümü yayınlanmıştır.

– CSP 1 (2012 Kasım),

– CSP 2

– CSP 3 (Henüz taslak aşamasında)

CSP’yi etkinleştirmek için web sunucunuzu Content-Security-PolicyHTTP Content-Security-Policy yanıt başlığı, web sitesi yöneticilerinin, belirli bir sayfa için kullanıcı taraflı aracı uygulamanın yüklenmesine izin verilen kaynakları denetlemesine izin verir. Bir kaç istisna dışında, politikalar çoğunlukla sunucu kaynaklarının ve komut dosyası son noktalarının belirtilmesini içerir. Bu, siteler arası komut dosyası saldırılan karşı korunmaya yardımcı olur

Eğer sitemizde bir XSS açığı söz konusu ise, CSP’nin desteklenmediği bir tarayıcıda CSP headerlarına rağmen istismar söz konusu olur.

CSP hearlarında herhangi bir başlık belirtilmez ise, bu alanlar için herhangi bir kaynaktan yapılan yüklemelere izin verilir (Varsayılan durum). CSP tanımlamalarında dikkat edilmesi gereken her sayfa için özel olarak tanımlanmalı ve bu sayfanın HTTP yanıtında mutlaka gönderilmelidir.

CSP’de kurallar tanımlanırken whitelist (güvenli liste) olarak bilinen bir yaklaşım kullanılmaktadır. Whitelist yaklaşımı sayesinde, yalnızca kabul ettiğimiz kaynakları belirtip, bu kural ile eşleşmeyen tüm kaynakların kullanımı engelleyebiliriz. Bu kaynakların hangileri olacağını CSP talimatlarıyla belirtmemiz gerekmektedir.

AÇIKLAR

Çapraz site komut dosyası : CSP’nin birici hedefi, XSS saldırını azaltmak ve rapor etmektir. XSS saldırıları, tarayıcının sunucudan aldığı içeriğin güveninden yararlanılarak yapılır. Kötü amaçlı komutlar kurbanın tarayıcısı tarafından yürütülür, çünkü tarayıcı içeriğin kaynağına güvenir. CSP, sunucunun XSS’nin oluşturabileceği açıkları azaltmasına veya ortadan kaldırmasına olanak tanır. CSP uyumlu bir tarayıcı, tüm diğer komut dosyalarını (satır için komut dosyaları ve olay işleme HTML öznitelikleri dahil) göz ardı ederek yalnızca whitelist listedeki etki alanlarından alınan kaynak dosyalara yüklenen komut dosyalarını yürütür. Sonuç olarak korunma şekli, hiç bir zaman komut dosyalarının yürütülmesine izin vermeyen siteler, betiğin yürütülmesine küresel olarak izin vermeyi seçemez.

Paket saldırıları azaltma : İçeriğin yüklenebileceği alanların kısıtlanmasına ek olarak, sunucu hangi protokollerin kullanılmasına izin verileceğini belirtilebilir; örneğin bir sunucu tüm içeriğinin HTTPS kullanarak yüklenmesi gerektiğini belirtir. Bu veri aktarımı ve güvenlik stratejisi, yalnızca veri aktarımı için HTTPS’yi uygulamakla kalmaz, aynı zamanda tüm çerezleri de bu protokol ile işaretler ve HTTP sayfalarından HTTPS muadillerine otomatik yönlendirme sağlar. Siteler, Strict-Transport-Security ile de tarayıcıların şifrelenmiş bir kanal üzerinden bağlandığından emin olmak için HTTP üstbilgisini de kullanabilir.

Örnek bir CSP header aşağıdaki gibidir.

Content-Security-Policy: KONTROL_ALANI degerler

Bir İçerik Güvenlik Direktifi Yazma

Her bir içerik güvenlik direktifi, bir kaynak türü veya direktifi tanımlayan bir dizi yönerge kullanılarak açıklanmalıdır. Bir içerik direktifi default-src yönergesi mutlaka içermelidir. Bu, kendi direktifleri olmadığında diğer içerik direktiflerinin kaynak türlerini belirtmek için varsayılan değer tanımlar.  default-src tanımının varsayılan değer veremeyeceği direktifler şunlardır:

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

Örnek:

Aşağıdaki header tüm içeriğin kendi kaynağından gelmesi gerektiğini söyler.

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

Aşağıdaki header içeriğin kendi kaynağından ve belirtilen tüm alt alan adlarından gelmesine izin verir.

Content-Security-Policy: default-src 'self' *.trusted.com

Direktiflerinizi Test Etme

Dağıtımı kolaylaştırmak için, CSP yalnızca rapor modunda devreye alınabilir. Böyle bir durumda direktif verme zorunlu değildir, ancak herhangi bir saldırı veya ihlal durumu söz konusu olduğunda bu belirtilen URI’ye rapor edilir. Buna ek olarak, yalnızca bir rapor üstbilgisi, gelecekteki bir revizyonu test etmek için kullanılabilir.

Content-Security-Policy-Report-Only: policy

Aynı anda hem Content-Security-Policy-Report-Only hem de Content-Security-Policy varsa her iki durumda geçerli olur.

Raporlamayı Etkinleştirmek

Varsayılan olarak belirtilen direktiflerin dışındaki ihlaller rapor edilmez. İhlal bildirimlerini etkinleştirmek için report-uri direktifini belirtmeniz gerekir. Bu raporları yayınlamak için en az bir URI belirtmeniz gerekmektedir.

Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi

Rapor Sözdimi

İhlal durumunda belirtilen URI’ye gönderilen JSON nesnesi aşağıdaki verileri içerir:

  • blocked-uri : CSP ile belirlenen direktife aykırı yüklenmeye çalışan kaynağın URI’sı. Engellenen URL, document-uri’den farklı bir kaynaktan geliyorsa, engelenen URI yalnızca şema, ana bilgisayar ve bağlantısı noktası içerek şekilde olur.
  • disposition : enforce veya reporting olmamasına bağlı olarak Content-Security-Policy-Report-Only başlığı ya da Content-Security-Policy başlık kullanılır.
  • document-uri : İhlalin gerçekleştiği belgenin URI’si.
  • effective-directive : İhlale neden olan yönerge.
  • original-policy : Content-Security-Policy başlığı tarafından belirtilen direktif.
  • referrer : İhlali gerçekleştiren belgenin yönlendireni.
  • script-sample : İhlale neden olan satır içi komut dosyasının, olay işleyicisinin veya stilin ilk 40 karakteri.
  • status-code : Genel nesnenin başlatıldığı kaynağın HTTP durum kodu.
  • violated-directive : İhlal edilen direktifin bölüm adı.

Örnek İhlal Raporu

Aşağıdaki direktifleri kullanarak stil sayfaları için CSP header yazalım.

Content-Security-Policy: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports

HTML dosyası şu şekilde olsun:

<html>
  <head>
    <title>Sign Up</title>
    <link rel="stylesheet" href="css/style.css">
  </head>
  <body>
    ... Content ...
  </body>
</html>

Bu html dosyası stil dosyaları için yalnızca cdn.example.com adresinden gelen sitil dosyalarına izin verilirken, kendi kaynağında bulunan http://example.com/css/style.css bir sitil dosyası yüklemeye çalışacaktır ve bu bir ihlal durumu oluşturacak ve bunu http://example.com/_csp-reports adresine aşağıdaki JSON nesnesini POST isteği olarak gönderecektir.

{
  "csp-report": {
    "document-uri": "http://example.com/signup.html",
    "referrer": "",
    "blocked-uri": "http://example.com/css/style.css",
    "violated-directive": "style-src cdn.example.com",
    "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports"
  }

Görüldüğü üzere, raporda ihlal eden kaynağın tam yolunu blocked-uri vermektedir. Fakat her zaman kaynağın tam yolunu vermeyebilir.

Görüldüğü üzere, raporda ihlal eden kaynağın tam yolunu blocked-uri vermektedir. Fakat her zaman kaynağın tam yolunu vermeyebilir.

Direktifler:

  • base-uri : Base elementi, sayfadaki tüm relative URL’lerin kendisine çözümleneceği absolute URL’i belirtilen bir değerdir. 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 :
  • 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.com adresinden 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: DENY ile 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.

strict-dynamic

Whitelist temelli CSP direktifleri kullanmak yerine nonce-based olarak isimlendirilen bir yaklaşım öneren Google, dinamik yüklemeler ile birlikte, CSP direktiflerimizi karmaşık hale çevirmeden, duruma hakim olmamızı sağlıyor. Google kendi browserlarında bu yöntemi desteklemeye başladı. Google dışında Opera tarafından da bu yönlen desteklenmektedir.

Hep birlikte bu yöntemin nasıl çalıştığını inceleyelim. example.com/map.js üzerinden bir script yükleyeceğiz. Bunun için bir CSP tanımladığımızı varsayalım.

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

example.com adresine 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 gecik açtık.

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

Üstelik bunu yaparken daha en başından, example.com domainini beyaz listeye alarak, example.com‘da oluş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

Bunun yerine, nonce-based CSP’i kullansaydık, 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>

Sadece example.com/map.js üzerinden yüklenen script’e güvendiğimizi, scriptin yüklendiği bloka bir nonce değeri atayarak, güvenli olarak belirttik. Yine strict-dynamic talimatları ile de, bu block 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.

nonce sadece CSP 2.0 sürümünde destekleniyor. strict-dynamic yapı ise CSP 3.0 sürümüyle birlikte gelen özelliklerdendir.

nonce kullandığımızda taktirde, eğer ziyaretçi tarayıcısı CSP 2.0 ‘ı destekliyorsa ne olacak?

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

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

nonce kullanıldığında, unsafe-inline kullanımı tarayıcı tarafından dikkate alınmıyor. Yani CSP 2.0 ve üzeri sürümleri destekleyen tarayıcılar bu satırdaki unsafe-inline talimatı yok sayacak. nonce talimatının tanınmadığı durumlarda ise tarayıcı unsafe-inline çalışacak ve sayfanızın bütünlüğünü bozmayacak şekilde kodlarınız çalışacaktır.

strict-dynamic de geriye dönük uyum için önerilen implementasyonu şöyle;

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

strict-dynamic kullanımı ile birlikte CSP 3.0 ve üzeri sürümlerin desteklendiği tarayıcılarda CSP direktiflerindeki https: ve http: dikkate alınmayacaktır.

Kaynak DeğeriÖrnekAçıklama
*img-src * Yıldız işareti data: blob: filesystem: şeması dışındaki bütün URL’lerden resim indirilmesine izin verir
‘none’object-src ‘none’Hiç bir içerikten object nesnesi kabul etmez.
‘self’script-src ‘self’Aynı alan adı ve IP’sinden script yüklenmesine izin verir.
data:img-src ‘self’ data:data:şemasından resim yüklenmesine izin verir (base64 encode edilmiş binary resimler).
subdomain.example.comimg-src subdomain.example.comResimler sadece subdomain.example.com adresinden yüklenmesine izin verir.
*.example.comimg-src *.example.comexample.com domainin bütün alt domainlerinden resim yüklenmesine izin verir.
https://cdn.comimg-src https://cdn.comhttps://cdn.com domaininden HTTPS protokolü kullanılmak şartıyla resim yüklenmesine izin verir.
https:img-src httpsHTTPS ile başlayan bütün domainlerden resim yüklenmesine izin verir.
‘unsafe-inline’script-src ‘unsafe inline’Sayfa içerisinde satır içi script kodların çalıştırılmasına izin verir.
‘unsafe-eval’script-src ‘unsafe-eval’Dinamik javascript kod çalıştırıcısına izin verir. eval() komutu ile içeriye kod çağrılmasına izin verir.

Örnekler

Aşağıdaki bir kaç Content-Security-Policy örnekleri mevcuttur.

Aynı domain’den olan bütün içeriklerin yüklenmesine izin vermek:

default-src ‘self’;

JavaScript dosyalarının aynı domain’den yüklenmesine izin vermek:

script-src ‘self’;

Google Analytics’i, google AJAX CDN’sini ve Aynı domain’den JavaScript içeriklerin yüklenmesine izin vermek:

script-src ‘self’ www.google-analiytics.com ajax.googleapis.com

Acemi Direktifi

Yeni başlayanların kullanabileceği bir direktif örneği. Aynı domain’den resimlere, scriptler, cssler ve AJAX’lara izin verir. Ama aynı zamanda object, media frame gibi nesneleri kullanılamaz hale getirir.

default-src ‘none’; script-src ‘self’; connect-src ‘self’, img-src ‘self’; style-src ‘self’

Content-Security-Policy Hata Mesajı

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.

Sunucu Taraflı Ayarlamalar

Sunucu taraflı kodlamalarla kullandığınız web sunucusu HTTP başlıkları göndermenize olanak sağlar. Aşağıda Ngnix için örnek gösterilmiştir.

add_header Content-Security-Policy “default-src ‘self’;”;

Kaynaklar :

https://developer.mozilla.org

https://ozgurwebgunleri.org.tr

https://www.netsparker.com.tr

https://www.netsparker.com.tr

http://www.trkodlama.com

0 cevaplar

Cevapla

Want to join the discussion?
Feel free to contribute!

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir