XSS Auditor'ların Hayatımızdan Çıkmasını Beklerken

Kategori: Web Güvenliği - Güncellenme: 13 Mayıs 2019 - Ziyahan Albeniz

Samuel Beckett'in meşhur avangard oyunu Godot'yu Beklerken, umutsuz ve pasif insanların nasıl bir hayalin ardına sığınıp eylemsizliklerini meşrulaştırdıklarını anlatır. Godot'yu Beklerken bir sahne oyunu olarak kalmamış, adeta benzer durumları ifade eden bir deyim haline dönüşmüştür.

Browser üreticilerinin X-XSS-Protection headerı ve XSS Auditor'lar konusundaki gelgitlerini de Beckhet'in meşhur oyununa nazire yaparak XSS Auditor'ların "Hayatımızdan Çıkmasını Beklerken" olarak ifade edebiliriz. Zira üreticilerin bu husustaki kararlarına müdahil olmak çoğunlukla mümkün değil.

Aslında bu konuyu 23 Temmuz 2018'de yayınladığımız bir blog postta, Microsoft Edge'in X-XSS-Protection'ın yıkıcı etkisini azaltmak için yaptığı bir değişiklikten ötürü konu almıştık.

Bu Konu Neden Tekrar Gündemimize Girdi?

XSS Auditor'lar, Reflected XSS saldırılarına karşı bir güvenlik mekanizması sunuyor. Temel çalışma mantığı istek yapılan URL'deki bir girdinin, HTML sayfasında tespit edilmesi üzerine kurulu. URL'deki script enjeksiyon desenine yanıtta rastladığı anda, script kodunun çalışması durduruluyor. Hatta kimi seçeneklerde sayfanın render edilmesi tamamıyla engelleniyor.

Eklemekte fayda var, Stored XSS, DOM XSS, mXSS gibi XSS türlerinde maalesef yukarıda özetlediğimiz çalışma prensibi dolayısıyla XSS Auditor'lar işlevsiz kalıyor.

İstek:

http://www.example.com/?param=<script>alert(1);</script>

Yanıt:

…
<div>…
<script>alert(1);</script>
</div>
…

Yukarıdaki durumda tarayıcı, query string'deki bir değerin sayfaya yansıdığını gördüğünde, sayfaya yansıyan kodun çalışmasını engelleyecektir. Tarayıcıların bunu birkaç şekilde yapmaları mümkün.

  1. İlgili kod bloğunu pasifize ederek,
  2. Tüm sayfanın yüklenmesini engelleyerek.

Tarayıcıların bu husustaki tercihleri farklılık gösteriyor. Örneğin Edge'in XSS Auditor davranışını tamamen pasif duruma aldığını söylemiştik. Yani herhangi bir şekilde script kodunun çalışmasına müdahil olmayacak. Sizin bunu hususen X-XSS-Protection headerı ile aktif hale getirmeniz gerekiyor.

X-XSS-Protection güvenlik headerı 2008 yılında IE 8 tarayıcılar ile hayatımıza giren bir özellik. Kullanımı ve parametre varyasyonlarına değindiğimiz HTTP Güvenlik Headerı yazımızı okumak için lütfen tıklayınız. Özetle tarayıcıların XSS Auditorları'nın davranışlarını yönetebildiğimiz bir güvenlik headerı.

Bir gelişme de Google Chrome cephesinden. Yakın bir zamana kadar Chrome tarayıcılarda XSS Auditor doğrudan doğruya "block" özelliğini kullanıp tüm sayfanın yüklenmesini engelliyor idi:

XSS-Auditor1

2016'da alınan bu karar, geçtiğimiz günlerde başka bir davranışla değiştirildi.

Chrome 74'den itibaren (v74.0.3729.108) XSS Auditor'da yapılan bir değişik ile tüm sayfanın yüklenmesini bloke etmek yerine, sadece zararlı görülen kod bloğunun çalışması engellemeye başladı.

Örneğin:

<html>
<head>
</head>
<body>
<h1>hello world!</h1>
</body>
<script>document.body.innerHTML+= "<div>I am a block, attacker wants to prevent</div>";</script>
<script>document.body.innerHTML+= "I am another block";</script>
</html>

XSS-Auditor2

URL'den sağlanan bir girdi ile saldırgan bu özelliği kötüye kullanıp, sayfadaki bir kısım kodun yorumlanmasını engelleyebilecek.

XSS-Auditor3

Kaş Yaparken Göz Çıkarmak

Yıllara yayılan bir şekilde XSS Auditor'ların saldırganlar tarafından hedef sayfalardaki bir dizi kodun devre dışı bırakılması için kullanıldığını biliyoruz. Burada saldırganlar çok önemli bir çalışma prensibini kötüye kullanıyor. Bu prensip XSS Auditor mekanizmasının URL'deki desene HTML içeriğinde rastlaması durumunda, o kodun çalışmasını durdurma prensibidir.

XSS-Auditor4

Frame Buster mekanizmalarını devre dışı bırakmak için, XSS Auditor'ların kullanıldığını biliyorduk. Geçen yıllar, yaratıcı tekniklerde çıtanın yükseldiğini kanıtlıyor.

Örneğin Twitter'da terjanq ismini kullanan güvenlik araştırmacısı Chrome'daki bu son güncelleme ile birlikte bir DOM validator'ı nasıl bypass ettiğini, yazdığı write-up ile paylaştı.

Frame Busting mekanizmasından bir örnek verelim. Geliştiricinin aşağıdaki kod vasıtası ile sitesinin frame içerisinde yüklendiğini tespit ederse, top navigation'ı yani tüm bir sekmenin kendi sitesine yönlendirilmesini sağlıyor.

<script>
if(top != self) {
  top.location = self.location;
}
</script>

Saldırgan ise varsayılan olarak etkin durumda olan XSS Auditor filter mekanizması ile bunu bypass ediyor:

<iframe src="http://www.victim.com/?v=<script>if">

XSS-Auditor5

Bu ve benzeri pek çok vakadan hareketle Edge browserlarda pasif duruma alınırken, Chrome tercihini XSS Auditor davranışını blocking'den filter'a geçirmek yönünde kullandı. Bu da gelecek günlerde daha fazla bypass write-up'ı göreceğimiz anlamına geliyor.

Araştırmacılar modern tarayıcılarda Content-Security-Policy headerının artık X-XSS-Protection vb. mekanizmalara ihtiyaç bırakmayacak kadar iyi olduğunu belirtiyor. (Bunlardan biri de Mozilla ekibinden Frederik Braun.)

Federik Braun, Chrome'daki son güncellemeye dair de bir blog yazısı kaleme alıp kaygılarını dile getirdi.

Peki Biz Ne Öneriyoruz?

Tarayıcıların XSS Auditor'larındaki varsayılan davranışı X-XSS-Protection headerı kullanarak blocking mode'unu devreye alacak şekilde yönetilmeli:

X-XSS-Protection:1; mode=block;

Sayfalarınızdaki kodlar yukarıdaki Frame Busting örneğinde de görüleceği, sayfanızın iframe vasıtası ile yüklenmesi şeklinde de bloke edilebilir. Bunun için sayfalarınızın farklı siteler tarafından iframe içerisinde yüklenip yüklenemeyeceğini Content-Security-Policy frame-ancestors seçeneği yahut X-Frame-Options headerı ile yönetebilirsiniz.

X-Frame-Options: DENY;  // Sayfanızın kendi origininiz dahil, herhangi bir site tarafından iframe içerisinde yüklenmesini engeller.

X-Frame-Options: SAMEORIGIN; // Sayfanızın yalnızca aynı origin'e sahip siteler tarafından, iframe içerisinde yüklenebilmesini sağlar.

CSP frame-ancestors headerı sayesinde ise sitenizi iframe içerisinde yükleyecek siteleri tek tek whitelist edebilirsiniz, örneğin:

Content-Security-Policy: frame-ancestors'self';

HTTP güvenlik headerları konusunda ayrıntılı bilgiye Netsparker Türkiye Blogu'nda yayınlanan ayrıntılı makalemizden erişebilirsiniz.

Netsparker

Tam isabet, hızlı ve kolay kullanım

DEMO SÜRÜMÜNÜ İNDİR