Web Trackerlar Browserların Parola Yöneticilerini İstismar mı Ediyor?

Session Replay scriptlerinin yarattığı tehlikeyi akademik bir çalışmayla analiz eden Princeton Üniversitesi'nden bir grup araştırmacı, bu defa browserların parola yönetim mekanizmasını istismar eden web tracking teknojilerini mercek altına aldı. Haftanın Hackleri'nde de yer yerdiğimiz Session Replay'in ayrıntılarına erişmek için lütfen tıklayınız.

Daha başlarken not etmekte fayda var, sözünü ettiğimiz tarayıcı davranışları 11 yıldır web güvenliği dünyasında konuşulan bir hadise. 4 yıl önce bu konuda yapılan akademik bir çalışma da mevcut.

Analitik dashboardlarında geri dönüşümlerle ilgili ayrıntılı bilgilere ulaşırken çoğumuzun sormayı ihmal ettiği bir soru var. Bu kadar data nasıl elde ediliyor? Kullanıcıların lokasyon, cinsiyet, yaş gibi demografik bilgilerinin yanı sıra, kimi zaman bu servisler eposta adresleri gibi bilgilere de ulaşabiliyor. Peki ama nasıl?

Haftanın Hackleri'nin bu yazısında yine Same Origin Policy'ye bir atıf yaparak, gizlilik ve güvenliği etkileyen bu durumun teknik analizini yapacağız. Yalnız bu kadar değil, browserların işleyişi, kullanıcı ve geliştiriciler açısından da başvurulabilecek tedbirlere değineceğiz.

Haydi başlayalım…

Güvenli parola ilkelerine sıkı sıkıya bağlı iseniz, üye olduğunuz her servis için ayrı ayrı, yeterli uzunluk ve karmaşıklığa sahip parolalar kullanıyorsunuz, demek. Peki bu parolaları nerede saklıyorsunuz?

Tüm modern tarayıcıların bu ihtiyaca cevaben sunduğu parola yöneticilerini bir çözüm olarak düşünebilirsiniz. Browser parola yöneticileri, form verilerini saklayıp, ilgili alanlara rastladığı zaman otomatik olarak doldurmasına benzer bir işlemi parolalar için de yapmaktadır.

Burada çok önemli bir nüans var. Adres, telefon, isim vb. kişisel bilgiler için form alanlarında type ve name attribute'unun eşleşmesi aranırken (örneğin adres için kaydedilen değer bir başka site gezilirken yine benzer bir ad ve tipe sahip form alanı için kullanılacaktır.) parolalar için bu doğrulama Same Origin Policy'den aşina olduğumuz origin eşleştirmesi ile yapılmaktadır. Yani bir siteye ait parola saklandığı zaman, bu parolanın ait olduğu web sitesinin origin'i de bu parola ile birlikte saklanmakta, ancak ve ancak aynı şema, domain ve port üçlüsüne rastlanıldığı takdirde sitedeki kullanıcı adı ve parola alanları browserın parola yöneticisi tarafından doldurulmaktadır. Ayrıntılar için lütfen tıklayınız.

Diğer kişisel bilgilerin formlara sorgusuz sualsiz doldurulmasının kullanıcı gizliğine verdiği zarar epey tartışıldı. Gizliliğe dair endişelerden birkaçına örnek verecek olursak saldırgan kontrolündeki bir siteye gizlenen adres, telefon, ad, soyad gibi input alanlarının browser tarafından doğrulanması ve böylece kimliğinizin ifşa olmasını sayabiliriz. Yine incognito /private mode'da gezindiğinizi düşünürken browserların bu özelliği nedeniyle ofsayta düşebilirsiniz.

Tracking scriptleri de, eklendikleri siteye gizli (hidden) bir form ekleyerek, bu form alanlarına username ve password bilgilerinin browser tarafından doldurulmasını sağlıyor ve username / parola bilgisini elde ediyor.

Parola mı? Evet! Neyse ki araştırmacıların aktardığına göre test ettikleri 50 bin vakada elde edilen parola bilgisinin tracking serverlarına gönderildiğine rastlanılmamış. Sadece elde edilen eposta adreslerinin hash değeri (MD5, sha1 ve bazen sha256 ile) tracking scriptlerinin kontrolündeki bir sunucuya ya da iş birliğinde oldukları diğer tracking servislerine gönderildiği belirtiliyor.

SOP Neredesin?

Peki tracking scriptleri, farklı bir originde olmalarına rağmen, nasıl benim kendi sitemin DOM'una erişip, input kutularındaki değerleri okuyabiliyor?

SOP kuralları gereği, bir site farklı bir origindeki siteden script yüklemesi yapabilir. Fakat bu yüklenen script, kendisinin, yani scripti yükleyen sitenin kontekstinde çalışacaktır. Dolayısıyla bu tracking scriptininin bizim sitemizin DOM'una hidden form ekleyip, sonra da bu form elemanlarının değerlerini okuyabilmesine şaşırmamalı.

Peki elde ettiği dataları farklı sunucuya göndermesine SOP bir şey demeyecek mi? SOP gereği cross-origindeki bir siteye XHR isteği yapabilir fakat dönen yanıtı okuyamazsınız. Elbette CORS gibi düzenlemelerle bu mümkün. Ayrıntılar için Same Origin Policy yazımıza müracaat edebilirsiniz.

Araştırmacılar analizlerini Alexa Top 1 milyon site içerisinden 50 bin domain üzerinde gerçekleştiriyorlar. Bu 50 bin site, Top 15 bindeki sitelerin tamamını, Top 15 bin ve Top 100 bin'den rastgele seçilmiş 15 bin siteyi ve son olarak Top 10 bin ile Top 1 milyon site arasından rastgele seçilmiş 20 bin siteyi içeriyor.

Araştırmadaki kritik bir ayrıntı muhtemelen çözüm olarak okurların aklına gelebilecek yönteme de cevap niteliği taşıyor. Araştırmacılara göre login sayfaları, diğer sayfalara göre yüzde 25 daha az üçüncü parti scriptler içeriyor.

Öyle ise login formlarımızın bulunduğu sayfalardan üçüncü parti scriptleri kaldırarak bu işe kesin bir çözüm bulabilir miyiz?

Elbette hayır! Yukarıda da dile getirdiğimiz gibi browserların parola yöneticileri şifreleri kaydederken origin'e göre kaydediyor. Dolayısıyla her ne kadar üçüncü parti bir script dosyası içermese de https://www.example.com/login sayfasından parola yöneticisine kaydedilen bir parola https://www.example.com/dashboard URL'inde karşılaşılan bir formda da kullanılacak. Dolayısıyla bu yöntem de sadra şifa olmayacak!

Üçüncü parti scriptleri tamamen kaldırsak bile, browserlarınızın bu özelliği bir noktada daha atak vektörü olarak kullanılabilir. Bu zafiyet Eric Lawrence tarafından NameTag Vulnerability olarak anılıyor. Bizce de isabetli!

Şayet sitemiz bir XSS zafiyeti içeriyorsa saldırgan enjekte ettiği komutlar yardımıyla sitemize bir form yerleştirip, parola yöneticisinin forma doldurduğu parolaları ele geçirebilir.

"Ne gerek var, zaten XSS ile cookie'yi elde edebiliyoruz." dediğinizi duyar gibiyim.

Ama bu sözünü ettiğimiz saldırı, cookie'nin çalınmasından daha ehemmiyetli. Zira Cookie'yi çalabilmek httpOnly gibi güvenlik flaglerinin varlığında mümkün değilken, browser parola yöneticisinin davranışı normal biçimde devam etmektedir. Üstelik saldırgan parola yöneticisi yoluyla parolayı elde ederek, Password Reuse Attack yani kullanıcının kullandığı diğer servislerde de aynı parolayı kullanabileceği ihtimali üzerine bina edilen yöntem ile saldırısını boyutlandırabilir.

Peki Çözüm?

Çözüm noktasında kullanıcılar, site sahipleri ve browser üreticilerine ayrı ayrı görevler düşüyor.

Kullanıcılar örneğin Chrome ve Firefox browserlarda aşağıdaki ayarları set edebilirler:

Chrome browser için:

Yukarıdaki seçenek etkinleştirildiğinde, yalnızca form alanının tıklanması ile birlikte açılan dropdown'dan account seçildiği takdirde diğer alanlar doldurulacaktır.

Firefox kullanıcıları ise adres çubuğuna about:config yazarak, ayarlar sayfasını açmalı ve listeden signon.autofillForms'i bularak, varsayılan değeri false olarak işaretlemeli. Yine bu sayfa vasıtası ile HTTP yani güvensiz bağlantı üzerinden yüklenen sitelerde de autofill desteğini kapatabilmek mümkün.

Tarayıcıların davranışlarına dair birkaç önemli ayrıntıyı Cure53'ün yayınladığı Browser Security Whitepaper'dan alıntılayacak olursak:

Site sahiplerinin login için farklı bir URL, örneğin bir subdomain kullanmaları da araştırmacıların önerileri arasında (Örn: login.example.com). Not etmekte fayda var, bu tasarım ve mühendislik açısından oldukça yük getirecektir. Örneğin Cookielerin scope'larını buna göre ayarlamanız gerekecektir. Cookieler hakkında ayrıntılı bilgi için Netsparker Türkiye Blogu'nda yayınlanan HTTP İşleyişi ve Güvenliği Açısından Cookie ve Session Yönetimi başlıklı yazımıza müracaat edebilirsiniz.

Autocomplete=On/Off?

Autocomplete özelliği ilgili form alanları için autocomplete fonksiyonunu devredışı bırakmaya yarayan bir attribute. Fakat ne yazık ki 2014 yılından bu yana browserlar tarafından çoğunlukla görmezden geliniyor. Ayrıntılar için Mozilla Developer Network'teki araştırmaya göz atabilirsiniz.

Araştırmanın ayrıntılarına ulaşmak için lütfen tıklayınız.