Modern Browserlarda SOP Davranışı, WP Setup Attack ve JSONP Güvenliği

Modern Browserlarda Same-Origin-Policy Macerası

Same-Origin Policy web güvenliğinin merkezinde duran bir konsept. Dolayısıyla iyi anlaşılması web güvenliği açısından olmazsa olmazlardan biri. Sadece konsept olarak SOP'un anlaşılması değil; modern browserların söz SOP'a geldiğinde sergilediği davranışlar da bir o kadar önemli.

Modern browserların Same-Origin Policy konusundaki davranışları konusunda yayınlanan son araştırma, okuyucunun bu yöndeki merakını doyuracak nitelikte.

Usenix'in 26'sı gerçekleşecek güvenlik sempozyumunda sunulacağı ilan edilen araştırma daha girişte çok önemli bir gerçeğe vurgu yapıyor: İstemci tarafında güvenlik arz eden her bir özelliğin münhasıran bir origin check'ine sahip olduğu gerçeği.

Javascript DOM Access, Cookie, LocalStorage ve SessionStorage, XMLHttpRequest vb aynı kaynak doğrulamasının yapıldığı alanlardan bazıları. SOP denilince aklımıza gelen ise bu altgruplardan Javascript- DOM erişimini düzenleyen Same-Origin Policy altgrubu. Araştırma özellikle DOM-SOP'a odaklanarak, tespit edilen bulguları paylaşıyor.

Bulgulara geçmeden önce yine araştırmadaki haklı tespitlerden birini daha paylaşmak istiyoruz. Belki böylece iki originin basit bir mukayesesi gibi görünen Same Origin Policy'nin yıllara yayılan by-passlarının sebepleri de anlaşılmış olacak. Makaledeki tespite göre, Web Origin'i tanımlayan (RFC 6494), DOM'u tanımlayan spesifkasyona rağmen DOM erişimlerini belirleyen bir spesifikasyon maalesef mevcut değil. Bu yüzden sadece teknolojiler arası değil, browser üreticileri arasında bile yıllardır süre gelen farklılıklar mevcut.

Araştırma 10 majör browserda gerçekleşen 544 farklı test neticesinde browserların SOP erişim yönetiminde Origin'e ilaveten üç farklı özelliği daha dikkate aldığını belirtiyor. Bu özellikler ise şunlar: Kaynağı embed eden HTML öğesi, CORS ve sandbox özellikleri.

SOP-DOM erişimlerini açıklarken dosya sistemlerindeki Okuma, Yazma ve Çalıştırma analojisine müracaat etmesi de konseptin okuyucu zihninde billurlaşması açısından kayda değer bir nokta.

Araştırmanın ayrıntıları için ilgili makaleye müracaat edebilirsiniz.

Wordpress Fresh Setup Attack

Wordpress dünya üzerinde 70 milyondan fazla web sitesinde kullanılan ve TOP 10 milyon web sitesi üzerinde yüzde 27'lik kullanım oranına sahip bir blog scripti.

Wordpress'in kullanımındaki bu yaygınlığın iştah kabartacağı malum. Wordpress güvenlik ürünü olan Wordfence'in paylaştığı istatistikler de bu iddiamızı doğrular nitelikte. Özellikle de Haziran ayı istatistikleri, ilginç bir noktaya dikkat çekiyor:

/wp-admin/setup-config.php

Wordpress indirilip sunucuya deploy edildiği zaman, hali hazırda bir config dosyasına sahip değil. Bunun yerine wp-config-sample.php adında bir dosya mevcut. Bu dosya ismini wp-config.php olarak değiştirip, elle editlemek mümkün olduğu gibi; bir sihirbaz yardımı ile yapabilmek de mümkün. wp-admin/setup-config.php yeni bir Wordpress kurulumu ile gelen böylesi bir sihirbaz.

Bu sihirbaz vasıtası ile, Wordpress config dosyanıza hangi veritabanı sunucusuna bağlanılacak, blogun başlığı ve dili gibi ayarları yazabiliyorsunuz.

Sunucunuzda bulunan böylesi bir dosyanın ne zararı olabilir ki? Saldırganların farkettikleri kuruluma hazır bir Wordpress'de, /wp-admin/setup-config.php yardımı ile saldırgan kendi veritabanı bilgilerini blog için ekleyebilir. Böylece okunacak dataların kendi kontrolündeki bir veritabanından sunulmasını sağlayabilen saldırgan, blogun admin paneline erişim elde edebilir. E peki sonra? Kıyıda köşede unutulan bir blog scriptinin kime ne zararı olabilir?

Wordpress template ve plugin editörleri vasıtası ile PHP kod çalıştırabilmek mümkün. Bu yolla saldırgan admin paneline erişim elde ettiği Wordpress blog scripti üzerinden PHP kodları çalıştırabilir.

Tedbiren, kurulum yapılana kadar kontrollü erişimin sağlanması için, .htaccess dosyası yolu ile sadece kendi IP'nizden erişimlere izin verebilirsiniz.

order deny,allow
deny from all
allow from <your ip>

Kocayan Kurt JSONP ve Güvenlik Maskaralıkları

Bugün cross-domain API isteklerinde modern bir yaklaşım olan CORS ağırlıklı olarak kullanılsa da, JSONP'ye de rastlamak mümkün. Hatta sizi neden JSONP kullanmak zorunda olduğunuza dair ikna etmeye çalışan servisler bile görebilirsiniz.

JSONP özetle, Same Origin Policy'nin kısıtladığı XMLHTTPRequest'in farklı bir origindeki siteye istek yapıp, yanıtını okuma kısıtına karşı geliştirilen bir çözüm olduğunu hatırlamakta fayda var:

Same Origin Policy'e göre bir A sitesi, farklı origindeki bir B sitesinden script yükleyip kendi kontekstinde çalıştırabilir. Bunun için dönen yanıtın geçerli bir script olması gereklidir. Bu kuraldan hareketle siteler, iletişimde olmak istedikleri sitelere bir script yüklemesi isteğinde bulunup, dönen yanıtı kendi kontekstlerindeki bir fonksiyona yönlendirecek, incelikli bir çözüm ile bu yasağı aşmışlar idi.

JSONP'nin çeşitli implementasyonları olsa da, en bilinen yöntemlerinden biri istek URL'i ile birlikte bir callback fonksiyonunu göndermek.

Zaman içerisinde hatalı JSONP implementasyonlarının yol açacağı Same-Origin Method Execution, Rosetta Flash, Reflected File Download gibi bir dizi zafiyet raporlandı. Geçmişe tatlı bir yolculuk, arkaik bir yöntemin kambur gibi taşındığı sitelerde hata avcılığı ya da JSONP'nin işleyişi ve yumuşak karnına dair dinlendirici bir yazı okumak isterseniz, Security-Cafe'de yayınlanan Practical JSONP Injection yazısını okumanızı tavsiye ederiz.