Chrome 45+ Yeni Özelliği Subresource Integrity ve Avantajları

Merhaba

Uzun zamandır “Acaba nasıl çözümlenebilir bu iş ?” diye düşündüğüm bir problem vardı. CDN Security. Yani javascript, css gibi statik kaynakların güvenliği. Uygulamalarımızın kendisini, yani backend sistemlerimizi son derece yüksek titiz şekilde güvenlik önemleri ile donatabiliyoruz. Bir çok kurum penetrasyon testi, kaynak kod analizi, WAF korumaları gibi süreçleri oturtmuş durumda. Ama web uygulamaları sadece ve sadece back-end sistemlerden ibaret değiller. Uygulamalarımızın kullanıcıları da uygulamaların kendileri kadar önemli. En nihayetinde var oluş nedeni kullanıcılar olan bir uygulamanın güvenlik endişleri arasında “client-site security” ‘nin olmaması mümkün değildir.

Örneğin; “Bizde SQL Injection yok. Kullanıcılarımızın tüm bilgileri şifreli olarak güvenle saklanmaktadır.” cümlesi olası bir javascript kütüphanesinde ki XSS zafiyeti sonucunda kullanıcının oturumunun çalınması sonrası tamamiyle anlamsız olacaktır. Çünkü kullanıcının oturumunu elde eden saldırgan, uygulamaya hedef kullanıcı hakları ile oturum sağlayacaktır ve veri tabanında ki şifreli bilgilerin ( Örneğin adres, isim vs) şifresiz haline doğrudan erişim sağlayabilecektir.

CDN Security

Javascript, CSS gibi statik içerikleri uygulamamızın çalıştığı domain üzerinden değilde, tek işi bu olan firmaların hizmet verdiği domainler üzerinden sunulabilir. Böylece caching gibi, içeriğin kullanıcıya en yakın cloud merkezinden ulaştırılması gibi teknolojiler ile hız kazanılabilmektedir. Bu da bize başka bir problemi ortaya çıkartır, “Ya CDN firması ele geçirilirse ? Sunduğumuz javascript’ler manipüle edilerek tüm kullanıcıların internet tarayıcıları ele geçirilebilir mi ?” sorusu çıkmaktır. Cevap ise malesef basit, net ve kısadır. Evet!

SEA

Geçtiğimiz sene 27 Kasım 2014 tarihinde Suriye Elektronik Ordusu çok ciddi bir siber saldırısında bu zafiyeti gördü ve kullandı. Aralarında yemeksepeti.com ‘un olduğu bir çok önemli kurum/websitesi “hacklendi”. Aslında olan ise tüm hacklenen firmaların kullandığı ortak CDN servisi olan gigya‘nın domaini SEA tarafından ele geçirilmişti. Bu sayede gelen tüm javascript kaynak taleplerine, orjinal içerik yerine alert(“Hacked by SEA”) içeriğini dönerek günlük belkide milyonlarca ziyaretçisi olan web sitelerinin tüm kullanıcılarına istediklerini yaptırabilir hale gelmişlerdi.


Browser Exploit Kit’lerine yönlendirip son derece güçlü bir botnet ağı oluşturmak yerine sadece pop-up açmakta hacktivizm’in ilginç nüanslarından biri olsa gerek.

Chrome’un yeni Subresource Integrity Özelliği

HSTS’ten sonra beğendiğim en güzel özelliklerden bir tanesi bu oldu. SEA örneğinde anlattığım olay şu soruları akıllara getirmektedir; “Javascript, CSS içeriklerinin değişmesini nasıl kontrol edeceğiz ? Nasıl haberdar olacağız ?” . Tüm kurumlar ana sayfalarında çıkan Hacked By SEA mesajı ile durumun farkına vardıkları acı bir gerçek.

Chrome bu durumu fark ederek integrity check özelliği getirdi. Javascript vs CSS kaynaklarınızı tanımlarken artık integrity adından bir attribute ile tanımlama yapabilmektesiniz.

correct_hash.css dosyasının hash’i hesaplanarak integrity olarak belirtildi. Böylece içeriği alıp getiren Chrome statik içeriği işlemeden önce hash kontrolü yapabilecek.

Yukarıdaki komut ile statik dosyanızın içeriğini kolayca oluşturabilirsiniz. Eğer bu özellik SEA olayında var olsaydı ve kurumlar kullansaydı gigya.com adresinden gönderilen javascript içeriği değiştiği için farklı bir hash oluşacak, bunu fark eden browser’lar ise javascript içeriği işlemeyip tüm kullanıcıların güvenliği sağlanabilecektir.

IDE’lerin bu özelliği otomatik olarak yazılım geliştiricilere sunması ise özelliğin kullanılabilirliği açısından son derece önemli. <script> ve <link> komutlarında seçilen source’a göre otomatik hash hesaplanıp attribute olarak gene otomatik şekilde eklenebilir.

Kaynak: https://googlechrome.github.io/samples/subresource-integrity/index.html