Clickjacking Saldırısı Nedir ve Nasıl Önlenir?

Clickjacking, Türkçesiyle "tıklama hırsızlığı", kullanıcıyı gördüğünden bambaşka bir şeye tıklattırma sanatıdır. Saldırgan sizin gerçek sitenizi tamamen şeffaf bir iframe içine gömer, üstüne kendi sahte butonlarını yerleştirir ve kullanıcı "Ödülü Al" ya da "Videoyu Oynat" yazan masum bir düğmeye bastığını sanarken, aslında altta gizlenen gerçek "Hesabı Sil" veya "Parayı Gönder" butonuna basmış olur. Sunucunuzda tek bir açık yoktur, kodunuz kusursuz olabilir; ama tarayıcı sayfanızı bir iframe içine gömmeye izin verdiği sürece saldırgan bu güveni kötüye kullanabilir.

Bu yazıda clickjacking'in görünmez iframe mantığını adım adım açacağım, saldırganın gerçek dünyada bu tekniği hangi biçimlere büründürdüğünü örnekleyeceğim ve en önemlisi, kendi sitenizi bu saldırı sınıfından nasıl koruyacağınızı göstereceğim. İki temel savunma vardır: eski ama hâlâ geçerli X-Frame-Options başlığı ve onun modern, esnek muadili olan Content-Security-Policy'nin frame-ancestors yönergesi. Bunları Nginx, Apache ve uygulama katmanı için hazır örneklerle vereceğim; sonunda da korumanızı iki dakikada nasıl test edeceğinizi anlatacağım. Amacım, bir sistem yöneticisinin müşterisine anlatır gibi, hem mantığı hem de uygulanabilir çözümü elinize tutuşturmak.

Clickjacking Nasıl Çalışır#

Clickjacking'in tek bir zafiyet sömürmediğini baştan netleştirelim; saldırı, tarayıcıların iki temel yeteneğini kötüye kullanır: bir sayfayı başka bir sayfanın içine iframe olarak gömebilmek ve CSS ile bu iframe'i görünmez yapabilmek. Saldırgan kendi kontrolündeki bir sayfa hazırlar. Bu sayfanın en altına, hedef sitenizi (diyelim ki hosting kontrol panelinizin bir işlem butonunu) bir iframe içinde yükler.

Ardından CSS'in iki özelliğiyle bu iframe'i gözden kaçırılamayacak kadar sinsi hale getirir. opacity: 0 iframe'i tamamen saydam yapar, yani kullanıcı orada bir çerçeve olduğunu göremez. z-index ise katmanların üst üste dizilme sırasını belirler; saldırgan görünmez iframe'i en üste, kullanıcının gördüğü sahte içeriği ise onun altına koyar. Böylece ekranda cazip bir buton görünür ama fare tıklaması, o butonun tam üzerine hizalanmış görünmez gerçek butona iner.

Mantığı somutlaştıran basit bir örnek şöyle görünür:

<style>
  /* Kullanıcının gördüğü sahte tuzak */
  .tuzak {
    position: absolute;
    top: 300px;
    left: 260px;
    z-index: 1;
  }
  /* Gerçek hedef sayfa: görünmez ama tıklanabilir, en üstte */
  iframe {
    position: absolute;
    top: 0;
    left: 0;
    width: 800px;
    height: 600px;
    opacity: 0;      /* tamamen şeffaf */
    z-index: 2;      /* sahte butonun üstünde */
    filter: alpha(opacity=0);
  }
</style>

<button class="tuzak">Bedava Hediyeni Al!</button>
<iframe src="https://panel.example/hesap/sil"></iframe>

Bu sayfayı açan bir kullanıcı ekranda yalnızca "Bedava Hediyeni Al!" yazan çekici bir buton görür. Ama tıkladığı anda fare imleci, o butonun tam üzerine milimetrik hizalanmış görünmez iframe'deki gerçek "Hesabı Sil" butonuna basar. Kullanıcı zaten panel.example'a giriş yapmışsa oturum çerezi otomatik gönderilir ve işlem gerçekleşir. Kurban ne olduğunu bile anlamaz; ekranda hiçbir uyarı belirmez.

Saldırının işe yaraması için üç şartın bir araya gelmesi gerekir: hedef sitenin iframe içine gömülebilir olması, kurbanın o siteye giriş yapmış (oturumlu) olması ve tıklamayla tetiklenen kritik bir işlemin bulunması. İşte savunmanın çıkış noktası da tam olarak birinci şarttır: sitenizin iframe içine gömülmesini engellerseniz, saldırgan diğer iki şartı sağlasa bile hiçbir şey yapamaz.

UI Redressing ve Türevleri#

Clickjacking, "UI redressing" (arayüz kılık değiştirme) denen daha geniş bir saldırı ailesinin en bilinen üyesidir. Temel fikir hep aynıdır: kullanıcıya gördüğünden farklı bir arayüzle etkileşim kurdurmak. Zamanla bu ana fikrin birkaç yaratıcı türevi ortaya çıktı ve bunları tanımak, savunmanın kapsamını doğru çizmenize yardımcı olur.

Likejacking, sosyal medyanın altın çağında çok yaygındı. Saldırgan Facebook'un "Beğen" butonunu görünmez bir iframe içine gömer, üstüne "Bu videoyu izlemek için tıkla" gibi bir tuzak koyardı. Kullanıcı videoyu izlemeye çalışırken farkında olmadan zararlı bir sayfayı beğenir, böylece içerik onun tüm arkadaş listesine yayılır ve saldırı kendini viral biçimde çoğaltırdı.

Cursorjacking, imlecin gerçek konumu ile ekranda gösterilen konumu arasında bir sapma yaratma tekniğidir. CSS ile özel bir imleç tanımlanır; kullanıcı imleci bir yerde sanır ama gerçek tıklama noktası birkaç santim ötededir. Böylece "Kabul Etmiyorum" butonuna bastığını düşünürken aslında "Kabul Ediyorum" butonuna basar.

Filejacking ve drag-and-drop saldırıları daha karmaşıktır. Kullanıcının dosya sürükleyip bırakma gibi masum bir hareketini görünmez bir alana yönlendirerek hassas veriyi saldırgana taşıtırlar. Aşağıdaki tablo bu türevleri özetliyor:

Bu türevlerin hepsinin ortak paydası, hedef arayüzün başka bir sayfanın içine gömülebilmesidir. Dolayısıyla iyi haber şudur: iframe gömmeyi engelleyen tek bir savunma, bu ailenin neredeyse tamamını aynı anda kapatır. Bir sonraki bölümlerde ele alacağımız iki başlık, işte bu tek noktadan çözümdür.

Gerçek Dünyadan Clickjacking Örnekleri#

Clickjacking akademik bir kavram değil; internet tarihinde defalarca gerçek zararlar vermiş bir saldırı türüdür. Terim ilk kez 2008'de güvenlik araştırmacıları Robert Hansen ve Jeremiah Grossman tarafından ortaya atıldığında, gösterdikleri ilk örnek Adobe Flash Player'ın ayar panelini hedef alıyordu. Görünmez bir iframe içine gömülen bu panel üzerinden, kullanıcının web kamerasına ve mikrofonuna erişim izni farkında olmadan verdirilebiliyordu. Yani kullanıcı sıradan bir oyun oynadığını sanırken, kamerasını saldırgana açıyordu.

Sosyal medya devleri de uzun süre bu saldırının hedefi oldu. Facebook'un likejacking dalgaları, "Bu kızın yaptığına inanamayacaksınız" tarzı tuzak başlıklarla milyonlarca hesabı zararlı sayfaları beğenmeye yöneltti. Twitter da 2009'da benzer bir "don't click" solucanıyla sarsıldı: kullanıcılar "tıklama" yazan bir butona basınca, görünmez iframe aracılığıyla aynı mesajı otomatik tweet'liyor ve saldırı üstel biçimde büyüyordu.

Bu örneklerin ortak dersi şudur: hedef sitelerin hiçbirinde geleneksel anlamda bir "açık" yoktu. Facebook'un beğeni butonu tam olması gerektiği gibi çalışıyordu; Twitter'ın tweet mekanizması kusursuzdu. Zafiyet, bu meşru butonların üçüncü taraf sayfalarca iframe içine gömülebilmesiydi. Bugün büyük platformların tümü frame koruma başlıkları kullanıyor; ama kendi kurduğunuz panel, WordPress sitesi veya özel uygulamanız bu korumayı otomatik olarak almaz. Onu bilinçli biçimde eklemek sizin sorumluluğunuzdadır.

Kritik bir nokta: clickjacking'e en açık sayfalar, tek tıkla ciddi sonuç doğuran sayfalardır. Hosting panelinizdeki "hesabı sonlandır", bir yönetim arayüzündeki "kullanıcıyı sil" butonu bunların başında gelir. Bu yüzden önce "hangi işlemler tek tıkla geri dönüşü zor sonuç üretiyor" diye bakın; koruma önceliğinizi oraya verin.

X-Frame-Options ile Koruma#

Clickjacking'e karşı ilk ve en eski savunma X-Frame-Options HTTP yanıt başlığıdır. Mantığı son derece basittir: sunucu, her yanıtta tarayıcıya "bu sayfa iframe içine gömülebilir mi, gömülebilirse hangi koşulda" bilgisini bir başlık olarak yollar. Uygulamayı fiilen yapan tarayıcının kendisidir; sunucu sadece kuralı söyler, tarayıcı uygular. Bu yüzden koruma yalnızca başlığı destekleyen (yani tüm modern) tarayıcılarda çalışır.

Başlığın iki pratik değeri vardır. DENY, sayfanın hiçbir yerde, kendi siteniz dahil, iframe içine gömülmesine izin vermez. SAMEORIGIN ise yalnızca aynı alan adı (aynı köken) içinden gömmeye izin verir; başka bir siteden gelen gömme girişimini engeller. Üçüncü bir değer olan ALLOW-FROM bir zamanlar belirli bir alan adına izin vermek için kullanılırdı ama artık kullanımdan kaldırıldı ve modern tarayıcılarda çalışmaz; onun işini artık CSP frame-ancestors görür.

Başlığın ham hali şöyle görünür:

X-Frame-Options: SAMEORIGIN

Pratikte çoğu site için doğru seçim SAMEORIGIN'dir, çünkü kendi içinizde meşru gömme ihtiyaçlarını (örneğin bir yönetim panelinin önizleme çerçevesini) korurken dışarıdan gelen saldırıyı keser. Ama giriş sayfası, ödeme ekranı veya kritik işlem butonları gibi hiçbir koşulda başka bir sayfaya gömülmesi gerekmeyen sayfalarda DENY daha güvenlidir. Kural olarak "bu sayfanın herhangi bir iframe içinde görünmesi için meşru bir sebebim var mı?" diye sorun; cevabınız hayırsa DENY seçin.

X-Frame-Options'ın tek zayıf noktası, tek bir alan adına izin verememesidir: ya hiç kimse (DENY), ya sadece kendiniz (SAMEORIGIN). Birden fazla güvenilir ortağınızın sitenizi gömmesine izin vermeniz gereken senaryolarda bu yetersiz kalır. İşte tam burada devreye modern muadili girer.

CSP frame-ancestors ile Modern Koruma#

X-Frame-Options iyi iş görür ama eski bir başlıktır ve esnek değildir. Modern web'de aynı işi, çok daha ince ayarla, Content-Security-Policy başlığının frame-ancestors yönergesi yapar. Bu yönerge, sayfanızı hangi kaynakların (alan adlarının) iframe, frame, embed veya object içine gömebileceğini bir liste halinde tanımlamanıza olanak tanır.

frame-ancestors 'self' ifadesi, X-Frame-Options: SAMEORIGIN ile aynı anlama gelir: yalnızca kendi kökeniniz gömebilir. frame-ancestors 'none' ise DENY karşılığıdır, kimse gömemez. Ama asıl gücü, birden fazla güvenilir alan adına izin verebilmesindedir:

# Hiç kimse gömemez (en katı)
Content-Security-Policy: frame-ancestors 'none'

# Sadece kendi kökeniniz
Content-Security-Policy: frame-ancestors 'self'

# Kendiniz + iki güvenilir ortak
Content-Security-Policy: frame-ancestors 'self' https://ortak.example https://partner.example

X-Frame-Options ile CSP frame-ancestors arasındaki temel farkları netleştirelim:

Şimdi kritik soru: hangisini kullanmalı? Cevap "ikisini birden". Modern bir tarayıcı her iki başlığı da görürse frame-ancestors yönergesini dikkate alır, X-Frame-Options'ı yok sayar. Eski bir tarayıcı ise frame-ancestors'ı anlamaz ama X-Frame-Options'ı uygular. Yani ikisini birlikte tanımlamak, hem en geniş tarayıcı yelpazesinde koruma sağlar hem de bir güvenlik ağı bırakır. Çakışma veya çift koruma sorunu yaşamazsınız; tam tersine, biri diğerinin boşluğunu kapatır.

Bir uyarı: frame-ancestors yalnızca gerçek bir HTTP yanıt başlığı olarak çalışır. Onu HTML içine <meta http-equiv> etiketiyle koyarsanız tarayıcı yok sayar. Bu yüzden bu yönergeyi mutlaka sunucu tarafında, yanıt başlığı olarak eklemeniz gerekir. CSP'nin bütününü daha derin merak ediyorsanız, HTTP güvenlik başlıkları rehberimiz tüm başlık ailesini bir arada ele alıyor.

Sunucu Yapılandırması: Nginx, Apache ve Uygulama Katmanı#

Teoriyi kapattık; sıra bu başlıkları gerçekten devreye almakta. En temiz yöntem, korumayı uygulama kodunda değil sunucu düzeyinde eklemektir; böylece hangi teknolojiyle yazılmış olursa olsun tüm sayfalarınız aynı koruma altına girer. Aşağıda Nginx, Apache ve uygulama katmanı için hazır örnekleri veriyorum.

Nginx tarafında, server bloğunun içine iki add_header satırı eklersiniz. Buradaki always parametresi hayati önemdedir: onsuz, 404 veya 500 gibi hata sayfalarında başlıklar düşer ve saldırgan tam da bir hata sayfasını gömerek korumayı atlatabilir.

server {
    listen 443 ssl;
    server_name siteniz.com;

    # Eski tarayıcılar için güvenlik ağı
    add_header X-Frame-Options "SAMEORIGIN" always;
    # Modern tarayıcılar için asıl koruma
    add_header Content-Security-Policy "frame-ancestors 'self'" always;

    # ... diğer yapılandırma
}

Değişiklikten sonra nginx -t ile yapılandırmayı sınayıp systemctl reload nginx ile devreye alın. Nginx'te sinsi bir tuzağa dikkat edin: bir location bloğunda yeni bir add_header tanımlarsanız, üst bloktaki tüm add_header satırları o alt blok için geçersiz olur. Bu yüzden güvenlik başlıklarını mümkün olduğunca üst düzeyde, tek bir yerde toplayın.

Apache tarafında mod_headers modülünün etkin olması gerekir. Başlıkları VirtualHost içine ya da .htaccess dosyasına ekleyebilirsiniz; ikincisi özellikle paylaşımlı hosting ortamlarında pratiktir çünkü sunucunun ana yapılandırmasına dokunmaz.

<IfModule mod_headers.c>
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set Content-Security-Policy "frame-ancestors 'self'"
</IfModule>

Modülü a2enmod headers ile etkinleştirip systemctl restart apache2 ile yeniden başlatabilirsiniz. Bir uygulama sunucusu (örneğin Node.js/Express) kullanıyorsanız, başlıkları kod düzeyinde de ekleyebilirsiniz:

app.use((req, res, next) => {
  res.setHeader("X-Frame-Options", "SAMEORIGIN");
  res.setHeader("Content-Security-Policy", "frame-ancestors 'self'");
  next();
});

Son olarak, bir CDN veya ters proxy (Cloudflare, kendi Nginx proxy katmanınız vb.) kullanıyorsanız, başlıkların en dış katmanda ayarlandığından emin olun. Kullanıcının tarayıcısına ulaşan son yanıt hangi katmandan çıkıyorsa, geçerli olan başlıklar oradakilerdir; alt katmanda doğru ayarlanmış bir başlık, üstte ezilirse etkisiz kalır. Bir WordPress sitesinde çalışıyorsanız .htaccess yöntemi genellikle en hızlı yoldur; ancak eklentilerin de bu başlıkları ezmediğini kontrol etmek gerekir. WordPress özelinde güvenlik sıkılaştırmasının tüm ayrıntılarını WordPress güvenliği rehberimizde bulabilirsiniz.

Frame Busting ve Ek Savunma Katmanları#

Frame koruma başlıkları yaygınlaşmadan önce, geliştiriciler clickjacking'e karşı JavaScript tabanlı "frame busting" (çerçeve kırma) kodları yazardı. Fikir şuydu: sayfa bir iframe içinde açıldığını tespit ederse, kendini en üst pencereye taşır ya da içeriği gizler. Klasik örneği şöyledir:

// Eski frame busting yaklaşımı — artık tek başına GÜVENİLMEZ
if (window.top !== window.self) {
  window.top.location = window.self.location;
}

Bu yöntem bugün için yetersizdir ve tek başına asla güvenmemelisiniz. Saldırganların bu kontrolleri atlatmanın onlarca yolu vardır: iframe'e sandbox özniteliği ekleyip JavaScript'i kısıtlamak veya çift iframe teknikleri kullanmak gibi. Ayrıca kullanıcının JavaScript'i kapalıysa koruma tamamen devre dışı kalır. Frame busting, HTTP başlıklarının yaygınlaşmadığı bir dönemin çözümüdür; artık asıl savunma başlıklardır.

Clickjacking savunmanızı bütünleyen başka katmanlar da vardır. Oturum çerezlerinize SameSite=Lax veya SameSite=Strict eklemek, çapraz siteden tetiklenen isteklerde çerezin gönderilmesini kısıtlayarak clickjacking'in "oturumlu kullanıcı" şartını zayıflatır:

Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict; Path=/

Kritik işlemlerde ise tek tıkla sonuç üretmeyi bırakın; bir onay adımı ekleyin. "Hesabı silmek istediğinize emin misiniz?" diyen bir ara ekran veya işlemi tamamlamadan önce şifre/2FA kodu istemek, clickjacking'i pratikte işlevsiz bırakır çünkü saldırgan tek bir gizli tıklamayla bu çok adımlı akışı tamamlayamaz. Ağ tarafında bir web uygulama güvenlik duvarı (WAF) da anormal istek desenlerini yakalayarak savunmanızı derinleştirir. Güvenlik hiçbir zaman tek bir başlığa değil, üst üste binen katmanlara dayanır.

Korumanızı Nasıl Test Edersiniz#

Başlıkları eklediniz; peki gerçekten çalışıyorlar mı? Bunu doğrulamanın en hızlı yolu komut satırıdır. curl ile sadece yanıt başlıklarını çekip ilgili satırları süzebilirsiniz:

curl -sI https://siteniz.com | grep -iE 'x-frame-options|content-security-policy'

Çıktıda hem X-Frame-Options: SAMEORIGIN hem de Content-Security-Policy: frame-ancestors 'self' satırlarını görüyorsanız, sunucu yapılandırmanız doğru çalışıyor demektir. Hiçbir şey görmüyorsanız büyük ihtimalle always / Header always parametresini unuttunuz ya da başlığı yanlış blokta tanımladınız.

Daha görsel bir test için basit bir HTML sayfası oluşturup kendi sitenizi bir iframe içine gömmeyi deneyin:

<h3>Clickjacking testi</h3>
<iframe src="https://siteniz.com" width="800" height="600"></iframe>

Bu dosyayı yerel makinenizde bir tarayıcıda açın. Koruma doğru çalışıyorsa iframe boş kalır ve tarayıcının geliştirici konsolunda "iframe içine gömme engellendi" (Refused to display ... in a frame because it set X-Frame-Options veya CSP frame-ancestors ihlali) benzeri bir hata görürsünüz. Eğer siteniz iframe içinde sorunsuz açılıyorsa, koruma devrede değildir ve saldırıya açıksınız demektir.

Çevrimiçi araçlar da işinizi kolaylaştırır. securityheaders.com gibi ücretsiz tarayıcılar sitenizin adresini girdiğinizde tüm güvenlik başlıklarınızı analiz eder ve frame koruma başlıklarının olup olmadığını açıkça raporlar. İlk taramada başlıklar eksikse düşük not alırsınız; bu rehberdeki iki başlığı ekledikten sonra tekrar taradığınızda notunuzun belirgin biçimde yükseldiğini görürsünüz. Bu, yaptığınız işin somut ve ölçülebilir bir kanıtıdır; özellikle müşteriye rapor sunarken çok işe yarar.

Sıkça Sorulan Sorular#

Clickjacking ile CSRF aynı şey mi?#

Hayır, farklı saldırılardır ama akrabadırlar. Her ikisi de kurbanın oturumunu kötüye kullanır, ancak yöntemleri ayrıdır. CSRF, kullanıcının hiçbir tıklaması olmadan arka planda sahte bir istek göndertir; kurban zararlı sayfayı açar açmaz istek tetiklenir. Clickjacking ise kullanıcının bir tıklamasına ihtiyaç duyar; onu görünmez bir butona basmaya kandırır. Kabaca söylersek CSRF "isteği senin adına ben gönderirim", clickjacking ise "isteği sen gönderirsin ama farkında olmadan" der. Savunmaları da farklıdır: CSRF için token ve SameSite çerez, clickjacking için frame koruma başlıkları kullanılır. Sağlam bir uygulama ikisine karşı da ayrı ayrı önlem alır.

X-Frame-Options mı yoksa CSP frame-ancestors mı kullanmalıyım?#

En doğru cevap ikisini birden kullanmanızdır. X-Frame-Options eski ama daha geniş tarayıcı desteğine sahip bir güvenlik ağıdır; frame-ancestors ise modern standarttır ve birden fazla alan adına izin verme gibi esnek yetenekler sunar. Modern bir tarayıcı ikisini birden gördüğünde frame-ancestors yönergesini dikkate alır, eski bir tarayıcı ise X-Frame-Options'a düşer. Böylece hiçbir çakışma yaşamadan en geniş koruma yelpazesini elde edersiniz. Sadece birini seçmek zorunda kalırsanız, geleceğe dönük olduğu için frame-ancestors'ı tercih edin; ama pratikte ikisini birlikte eklemenin hiçbir maliyeti yoktur.

frame-ancestors başlığını HTML meta etiketiyle ekleyebilir miyim?#

Hayır, bu yönerge yalnızca gerçek bir HTTP yanıt başlığı olarak çalışır. frame-ancestors, report-uri ve sandbox gibi bazı CSP yönergeleri, HTML içine <meta http-equiv> etiketiyle konulduğunda tarayıcı tarafından bilinçli olarak yok sayılır. Bunun sebebi, bu yönergelerin sayfanın nasıl gömüleceğine dair kararı, HTML işlenmeye başlamadan önce, yani yanıt başlıkları okunurken vermesi gerekmesidir. Dolayısıyla clickjacking korumasını mutlaka sunucu yapılandırmasından (Nginx, Apache) veya uygulama kodundan, gerçek bir başlık olarak eklemelisiniz. Meta etiketiyle koyduğunuz bir frame-ancestors sizi hiç korumaz.

Sitem başka bir sitede meşru olarak gömülüyor, DENY kullanırsam bozulur mu?#

Evet, bozulur; bu yüzden değeri ihtiyacınıza göre seçmelisiniz. Eğer sitenizin bir bölümü meşru olarak başka bir alan adı tarafından iframe içinde gösteriliyorsa (örneğin bir ödeme widget'ı ya da bir ortağın sayfasına gömülü bir araç), DENY bu gömmeyi de engelleyerek işlevi kırar. Böyle durumlarda ya aynı köken içindeyseniz SAMEORIGIN kullanın, ya da farklı ama güvenilir alan adlarına izin vermek için CSP frame-ancestors 'self' https://guvenilir-ortak.example biçiminde açık bir liste tanımlayın. Genel kural şudur: gömülmesi gereken sayfalarda ihtiyaç duyduğunuz kökenleri beyaz listeye alın, gömülmesine hiç gerek olmayan sayfalarda (giriş, ödeme, kritik işlemler) ise DENY ile tamamen kapatın.

Clickjacking'e karşı yalnızca JavaScript frame busting yeterli mi?#

Hayır, JavaScript tabanlı frame busting tek başına yeterli ve güvenilir değildir. Bu yöntem başlıkların yaygınlaşmadığı eski bir dönemin çözümüdür ve atlatılmasının pek çok yolu vardır: saldırgan iframe'e sandbox özniteliği ekleyerek JavaScript'i kısıtlayabilir, çift iframe teknikleri kullanabilir veya kullanıcının JavaScript'i kapalıysa koruma zaten hiç devreye girmez. Asıl ve güvenilir savunma, sunucunun gönderdiği X-Frame-Options ve CSP frame-ancestors başlıklarıdır; çünkü bunları uygulayan tarayıcının kendisidir ve atlatılmaları çok daha zordur. JavaScript frame busting'i olsa olsa küçük, tamamlayıcı bir ek katman olarak düşünün, asla ana savunma olarak değil.

Bir hosting panelinin veya yönetim arayüzünün frame korumasına gerçekten ihtiyacı var mı?#

Kesinlikle var, hatta en çok ihtiyaç duyan sayfalar bunlardır. Hosting panelleri, yönetim arayüzleri ve giriş ekranları tam olarak clickjacking'in en çok işine yarayan hedeflerdir; çünkü tek bir tıklamayla hesap silme, hizmet iptal etme, ödeme onaylama gibi geri dönüşü zor işlemler içerirler. Saldırgan bu panelleri görünmez bir iframe içine gömüp kullanıcıya kritik butona bastırabilirse ciddi zarar verir. Bu tür arayüzlerde X-Frame-Options: DENY veya CSP frame-ancestors 'none' kullanmak en güvenli tercihtir, çünkü bir yönetim panelinin başka bir sayfaya gömülmesi için neredeyse hiçbir meşru sebep yoktur. Clou.TR panelinde bu korumaların yerinde olması da bu yüzden bilinçli bir tercihtir.

Kapanış#

Clickjacking, karmaşık bir zafiyet sömürmeden yalnızca tarayıcının iframe ve şeffaflık yeteneklerini kötüye kullandığı için sinsi ama bir o kadar da kolay önlenebilir bir saldırıdır. Sitenizin başka bir sayfaya gömülmesini engellediğiniz an, bu saldırı ailesinin neredeyse tamamını tek hamlede kapatmış olursunuz. Bunun için ihtiyacınız olan tek şey, iki satır sunucu yapılandırması: eski tarayıcılar için X-Frame-Options, modern tarayıcılar için CSP frame-ancestors. Bunları kritik sayfalarda DENY/'none', gerisinde SAMEORIGIN/'self' olarak ayarlayıp curl ve securityheaders.com ile doğrulamak, dakikalar süren ama etkisi büyük bir güvenlik kazanımıdır.

Bu tür sıkılaştırmaları kendiniz uğraşmadan hazır almak isterseniz, Clou.TR olarak yardımcı olabiliriz. Hosting paketlerimiz ve WordPress hosting altyapımız güvenli başlık yapılandırmalarıyla gelir; sunucunuzun bütününün profesyonelce sertleştirilmesini isterseniz sunucu yönetimi hizmetimiz frame koruma dahil tüm güvenlik başlıklarını sizin adınıza yapar. Uygulamanızın önüne bir web uygulama güvenlik duvarı (WAF) koyarak kötü niyetli istekleri kaynağında filtreleyebilir, tam kontrol isteyen ekipler içinse sanal ve fiziksel sunucu çözümlerimizle altyapınızı baştan güvenli kurabilirsiniz. Güvenli bir web varlığı katman katman inşa edilir; ilk katmanı bugün ekleyin, gerisini birlikte tamamlayalım.