Clickjacking: Bastığın Yerleri Buton Diyerek Geçme, Tanı!

Clickjacking saldırısı teorik olarak 2002 yılında bir sayfanın başka bir sayfayı opacity (saydamlık) değeri düşük bir iframe içerisinde yükleyerek, kullanıcı farkında olmadan esas sitedeki öğeleri tıklayabileceği ve sitede "state" değişikliklerine yol açılabileceği senaryosu ile ortaya kondu.

Ne var ki 2008 yılına kadar bu saldırı gözardı edildi. Ta ki saldırının isim babası Jeremy Grossman ve Robert Hansen kullanıcı bilgisayarında Clickjacking kullanılarak Adobe Flash Player'ın izinlerine dair yetki alınmasının mümkün olduğunu kanıtlayana kadar.

Jeremy Grossman'in click ve hijacking kelimelerinden türettiği bu tabir sonraki yıllarda adından sürekli söz ettirmeyi başardı.

Clickjacking saldırısı sonuçlarına dair kimi kategorizasyona da tabii tutulup farklı isimlerle de anıldı. Örneğin Facebook üzerindeki bir clickjacking atağı ile bir saldırganın kendisine beğeni toplaması LikeHijacking gibi isimlerle de literatürde göründü.

Clickjacking, Frame Busting gibi yöntemlerle savuşturulmaya çalışılsa da en etkili çözüm 2009 yılında Microsoft'dan geldi. Internet Explorer 8 browserı ile birlikte bu işin köküne kibrit suyu döken Microsoft, X-Frame-Options HTTP yanıtını browser'a implemente etti. Peşi sıra tüm majör browserlarda desteklenen X-Frame-Options headerı hakkında bir RFC standardı ise 7034 kodu ile 2013 yılında yayınlandı.

Peki ClickJacking Saldırısı Nasıl Gerçekleşiyor?

Bu işlemlerin tamamı kullanıcının (ya da kurbanın) kendi browserı üzerinden gerçekleştiği için eBay için tetiklenen bu isteğe, browser kendisinde tuttuğu credentials (örneğin Cookie) bilgilerini de ekliyor. Yani bu işlem kullanıcı yetkileri ile gerçekleşiyor. Resimde görülen örnekte eBay sitesi opacity değeri düşük bir iframede yükleniyor. Bu sebeple kullanıcı tarafından görülemiyor. eBay'in yüklendiği iframe'in opacity değeri düşük olduğu için kullanıcı Buy butonunu değil de Free butonunu görüyor. Kullanıcı Free butonuna bastığında, aslında bu butonun üzerine binen eBay'deki Buy butonuna tıklamış oluyor. Buy butonuna tıklandığında da eBay sitesi, bu buton için kurgulanan gerekli işlemleri yapıyor.

Clickjacking, kullanıcılarımızı, yani zincirin zayıf halkasını hedef alan bir saldırıdır.

Resim: https://www.tinfoilsecurity.com/blog/what-is-clickjacking

Facebook Clickjacking diyor, Fixlerim Demiyor!

21 Aralık tarihinde yayınladığı bir blog postta, bir güvenlik araştırmacısı arkadaşlarının Facebook duvarlarında paylaşılan benzer paylaşımlardan hareketle bir sahtecilik olayı tespit ediyor.

Bir karikatür uygulamasının onay ekranının gözüktüğü gönderide önce uygulamaya girerken iki soru ile karşılaşılıyor. Sonrasında da 16 yaşından büyük olduğunuza dair bir konfirmasyon ekranının ardından, bir de bakıyorsunuz ki sizin Facebook duvarınızda da aynı gönderi paylaşılmış.

Zafiyeti inceleyen araştırmacı AWS üzerinden servis edilen koda ulaşıyor:

Bu framelerin aşağıdaki Facebook URL'inde sonlandığını farkediyor:

https://mobile.facebook.com/v2.6/dialog/share?app_id=283197842324324&href=https://example.com&in_iframe=1&locale=en_US&mobile_iframe=1

Bu URL'e doğrudan erişildiğinde Facebook duvarınızda paylaşım yapmanız için ekran beliriyor.

Oui yani (Evet) yazan butona tıkladığınızda aslında Facebok sayfasındaki "Post" butonuna basmış oluyorsunuz ve gönderi sizin duvarınızda gözüküyor. Böylece bu dolandırıcılık dalga dalga yayılmış oluyor.

İşin garibi araştırmacı bu URL'i ziyaret ettiğinde Clickjacking'e bir çözüm olarak önerilen X-Frame-Options yanıt header'ının tam da olması gerektiği gibi set edildiğini görüyor.

X-Frame-Options: DENY

Yani Facebook.com'un kendisi de dahil hiçbir sitenin bu URL'i iframe içerisinde görüntüleyememesi gerekiyor

Fakat nasıl oluyor da buna rağmen bu gönderi yayılıyor, diye olayın üzerine giden araştırmacımız, tüm majör browserlarda X-Frame-Options header'ının doğru implemente edilip edilmediğini kontrol ediyor. Sonuç X-Frame-Options header'ının beklendiği şekilde çalıştığı yönünde oluyor.

Araştırmacı bu defa ihtimalleri Facebook Android uygulamasındaki built-in browser'ın bu talimatı yok saydığı yönünde yoğunlaştırıyor. Sonrasında fark ediyor ki aslında mobil bir cihazdan giriş yapıldığında Facebook X-Frame-Options header'ını yanıt mesajı ile birlikte gönderilmiyor.

Facebook zafiyeti fix'lemeyi reddediyor. Fakat tedbir olarak Post butonuna basıldıktan sonra bir de sizden tekrar bu gönderiyi onaylamanızı isteyen ikinci bir ekran görüntülenmesini sağlıyor.

Bazen Küçük Bir Attribute Hayat Kurtarır

Yapılan geliştirme ile beraber bu ikinci onay ekranına tıklayınca, paylaşım mesajının ve paylaşılacak kişilerin seçildiği son ekran küçük bir href attribute'ü ile tehlikeyi savıyor. Href elemanının target attribute'üne eklenen "_blank" yani hedef URL'in yeni bir pencerede işlenmesi, tüm oyunu şimdilik bozuyor.

Tabii bu açılan yeni ekranda XFO'yu Deny olarak set etmeyi ihmal etmemişler. Facebook bu zafiyetin fixi için kulağı epey tersten tutmuşa benziyor. Bunun sebebi de feature'ın çalışma şeklini muhafaza etmek istemiş olmaları, olsa gerek. 

Peki clickjacking zafiyetine dair hangi önlemleri almak gerekiyor?

Ziyaretçilerimizi Clickjacking vb. saldırılardan korunmanın en temel yolu, sayfalarımızın iframe, frame gibi yollarla embed edilmesini engellemek ya da buna bir kısıtlama getirmektir. Bunu yapmak için güvenlik headerlarından biri olan X-Frame-Options'ı kullanabiliriz. Yukarıda da görüldüğü üzere bu header'ın eksikliği gündemde olunca, doğal olarak clickjacking ve benzeri zafiyetler kaçınılmaz oluyor. Bu yüzden X-Frame-Options veya Content-Security-Policy headerı doğru bir biçimde implemente edilmeli.

X-Frame-Options değerinin, alabileceği üç farklı değer vardır.

X-Frame-Options: DENY | SAMEORIGIN | ALLOW-FROM URL

DENY: Sitenin hiçbir şekilde iframe ya da benzeri bir yol ile embed edilmesine izin vermez.

SAMEORIGIN: Sitenin yalnızca şema + hostname + port olarak eşleştiği bir site tarafından embed edilmesine izin verir. Örneğin, https://www.example.com yalnızca https://www.example.com üzerinden yüklenebilir.

ALLOW-FROM URL: Yalnızca belirtilen URL tarafından sitenin embed edilmesine izin verir.

X-Frame-Options'da iki önemli noktayı hatırlatmakta fayda var. Chromium tabanlı browserlarda X-Frame-Options kısmi olarak desteklenmektedir. Örneğin ALLOW-FROM özelliği kullanılamamaktadır.

ALLOW-FROM URL Parametresi ile yalnızca 1 adet domain'i whitelist edip, sitemizi iframe içerisinde yüklemesine izin verebiliriz.

Önemli noktalar

• X-Frame-Options header'ı bütün sayfaların HTTP yanıtlarında yer almalıdır.
• X-Frame-Options yerine, Content-Security-Policy frame-ancestors direktifi kullanılabilir.

Content-Security-Policy: frame-ancestors 'none'; // Hiçbir URL sayfayı iframe içerisinde yükleyemez.
Content-Security-Policy: frame-ancestors 'self'; // SAMEORIGIN parametresindeki işlevin aynısı.

X-Frame-Options ile birlikte yalnızca bir URL'i whitelist'e alırken, CSP frame-ancestors ile birden fazla domain'i, güvenilir URL'ler listesinde belirtip, sayfalarımızı iframe olarak yüklemelerine izin verebiliriz.