Site Izolasyon Mekanizması: uXSS'den Korkma, Content-Type'ı Set Etmemekten Kork!

Site-isolation Mekanizması ile Content-Type Header'ı Hiç Olmadığı Kadar Önemli

HTTP spesifikasyonuna göre boş olmayan her HTTP yanıtı, ilgili içeriğin tarayıcı tarafından nasıl yorumlanacağını belirleyen bir Content-Type headerı belirtmeli:

Mime Type Sniffing, sunulan içeriğin tipi belirtilmediği durumlarda, tarayıcıların sayfa görüntülenmesinde en doğru yolu bulabilmek için, içeriği değerlendirmesi işlemidir.

Kısaca sunulan belgede Content-Type header’ı ile içeriğin tipi belirtilmediği takdirde, tarayıcı içeriği "koklayarak", kaynağı en doğru biçimde görüntülemeye çalışır.

Özellikle de upload fonksiyonlarıyla beraber, sniffing işlemi bir takım tehlikeler arz edebilir. Örneğin, kullanıcının zararsız addedilen bir text dosyası upload ettiğini varsayalım. Eğer bu text dosyası HTML ve script tagları, JavaScript kodları içeriyorsa ve biz bu yüklenen dosyayı tekrar kullanıcıya sunarken bir Content-Type belirtmiyorsak, tarayıcı bu sayfanın içeriğini koklayarak bunun pek tabii bir "text/html" tipinde bir dosya olduğuna karar verecektir ve bu sayfadaki zararlı kodlar da çalışacaktır.

İşte bu gibi durumlarda, tarayıcının sayfa içeriğini koklayarak, inceleyerek servis edeceği tipe karar vermesinin önüne geçmek için X-Content-Type-Options headerı kullanılmaktadır.

Çok uzun süredir gündemimizde olan Mime Type Sniffing atakları ve tedbiren önerdiğimiz Content-Type headerının doğru biçimde set edilmesi (ve haricen X-Content-Type-Options: nosniff) seçeneği modern tarayıcılarda artık farklı bir önem kazanıyor. Neden mi? Modern tarayıcılarda, özellikle de Chrome'un son güncellemesi ile birlikte gelen site izolasyon mekanizmalarının işleyişinde sunulan kaynakların Content-Type 'ı büyük önem arz ediyor.

Site-isolation mı, o da ne?

Site izolasyonu, Chrome 63 ile gelen yeni bir özellik. Bu özelliğe göre, farklı bir sekmede, aynı sekmede, ya da bir iframe içerisinde yükleniyor olmasına bakılmaksızın, farklı origindeki sitelerin ayrı processler olarak çalıştırıldığı bir ekstra güvenlik mekanizması.

Same Origin Policy (SOP) varken buna ne gerek vardı?

Doğru! SOP farklı originlere ait kaynaklara erişimleri yöneten, istemci taraflı güvenliğin en önemli yapı taşı olmaya devam ediyor. Fakat Universal XSS (uXSS) gibi atak vektörleri SOP'u bypass edebildiğinde eldeki tüm mevziler teslim alınmış oluyor idi.

Universal XSS (uXSS), tarayıcının kendisindeki bir zafiyetten kaynaklanan ve farklı origindeki sitelerin DOM'una erişebilmemizi sağlayan bir XSS türü.

Site izolasyonu konseptine göre, HTML, JSON ve XML tipindeki içerikler, CORS headerları ile aksi belirtilmedikçe, farklı originden yapılan bir istekteki process'e teslim edilmeyerek, ayrı bir process olarak devam ettiriliyorlar. Yani farklı bir originden, JSON dosyasını sayfanıza dahil edebilseniz bile, sizin sayfanız harici bir process üzerinden işlem görecek. Böylece rendering mekanizmasında oluşacak herhangi bir zafiyetten ötürü bu kaynakların ifşası engellenmiş oluyor. Not etmekte fayda var, site izolasyonu sadece uXSS'e karşı değil, son günlerde gündemimizi meşgul eden CPU tabanlı ve speculative execution'dan kaynaklı oluşabilecek zafiyetin etkilerini azaltmak için de kullanılabilir.

Anahtar kelimeler: HTML, JSON ve XML

Yukarıda Content-Type'a modern tarayıcılarda eskisine nazaran atfettiğimiz önem de buradan kaynaklanıyor. Normal şartlar altında, Image, Javascript, Style gibi SOP'un cross originlerden yüklenmesine ve yükleyen sitenin contextinde çalışmasına müsaade ettiği dosyalarda bir değişiklik yok. Fakat HTML, JSON ve XML gibi, DOM'a referans veren ya da hassas bilgiler barındırabilecek dosya türleri için izolasyon mekanizmasının devreye alınması önemli. Burada da tarayıcının servis edilen kaynak türü hakkında doğru bilgilendirilmesi gerekiyor. Yani Content-Type headerının doğru bir biçimde set edilmiş olması ve sniffing devredışı bırakılmış olması önemli.

Chrome; URL, Content-Type headerı gibi ölçülerle ayrı bir process açılıp açılmayacağına karar veriyor. Bu hususta aşağıdaki Content-Type'lar önemli:

• text/html
• text/xml
• application/xml
• application/rss+xml
• application/json
• text/json
• text/x-json
• text/plain

Yanı sıra X-Content-Type: nosniff headerı da eklenmeli.

Birkaç önemli husus…

Chrome 63 ve üzeri tarayıcılarda site izolasyonunu varsayılan olarak kapalı durumda. Aktifleştirmek isterseniz, Chrome tarayıcı üzerinden chrome://flags/#enable-site-per-process adresine girmeniz ve site izolasyonunu etkinleştirmeniz gerekiyor. Bu değişiklikten hemen sonra tarayıcınızı yeniden başlatmalısınız. Site izolasyonunu sadece belirli originler için etkinleştirebilmek de mümkün. Bunun için Chrome başlatılırken aşağıdaki parametre kullanılabilir:

--isolate-origins=https://google.com,https://youtube.com

Güvenlik hakkında çok önemli bir ikaz olarak not etmekte fayda görüyoruz. Dosyaların byte byte servis edilmelerine imkan veren HTTP Range Request'lerin, hassas kaynaklarda (resource) devre dışı bırakılması gerekiyor. Peki ama neden? Çünkü bu tarz dökümanlarda Content-Type multipart/byteranges olarak servis ediliyor. Bu içerik tipi kaynağın ayrı bir process olarak çalıştırılması gereken Content-Type listesine dahil değil.

Site izolasyonunun etkinleştirilmesi ile beraber yüzde 10-20 arasında ekstra bir kaynak tüketimi de söz konusu olacak.

Site izolasyon özelliği hakkında, üreticinin de haberdar olduğu buglar şu şekilde özetlenebilir:

• Tüm siteler için izolasyon devreye alındığında, yüzde 10-20 arası bir ekstra yükten söz etmiştik. Sadece belirli sitelerin izole processler olarak çalışması sağlanarak bu rakam daha düşük bir seviyeye getirilebilir.
• HTML web sayfalarının yazıcı çıktılarında, farklı originlerin yüklendiği iframeler boş olarak gözüküyor.
• Bazı durumlarda, farklı origindeki sitelerin yüklendiği iframelerde tıklama ve sayfa kaydırma işlemleri beklendiği gibi çalışmıyor.

Site izolasyon mekanizması hakkında ayrıntılı bilgi için lütfen tıklayınız.