XSS (siteler arası betik çalıştırma) nedir ve neden tehlikelidir?

Bir habere yorum yazdığınızı düşünün. Yazdığınız yorum sayfaya ekleniyor ve o sayfayı açan herkes onu görüyor. Normalde orada düz bir metin olması beklenir. Ama o yorum alanı, yazdığınız şeyi gerçekten yalnızca metin olarak mı görüyor, yoksa içine koyduğunuz bir kodu çalıştırır mı? İşte XSS bu sorunun yanlış cevabından doğuyor.

XSS, “cross-site scripting” ifadesinin kısaltması, Türkçede siteler arası betik çalıştırma olarak geçer. Kısaca şu demek: Saldırgan, kendi küçük kodunu (çoğu zaman bir JavaScript betiği) güvenilir bir sitenin bir köşesine yerleştiriyor. Siz o sayfayı açtığınızda, tarayıcınız o kodu sitenin kendi kodu sanıp çalıştırıyor.

Bunun neden bu kadar etkili olduğunu anlamak için tarayıcıların nasıl çalıştığına bakmak gerekiyor. Tarayıcılar, bir sitenin kodunun başka bir sitenin verilerine dokunmasını engelleyen sıkı bir kural uyguluyor. Bankanızın sekmesiyle bir oyun sitesinin sekmesi birbirinin içine bakamaz. Bu kurala “aynı köken politikası” deniyor ve web güvenliğinin temel taşlarından biri. XSS bu kuralı atlatmanın en kestirme yolu, çünkü saldırganın kodu artık başka bir siteden değil, güvendiğiniz sitenin kendisinden geliyor. Tarayıcı, bir sayfadaki kodun oraya saldırgan tarafından mı yoksa sitenin kendisi tarafından mı konduğunu ayırt edemez. Güvendiği siteye neredeyse her şeye izin verir.

Zararı ne olabilir?

Kod sizin tarayıcınızda, hem de güvendiğiniz sitenin içinde çalıştığı için, sizin o sitede yapabildiğiniz çoğu şeyi yapabilir:

• Oturumunuzu çalabilir. Siteler sizi tanımak için tarayıcınıza bir oturum çerezi bırakır. Bu çerezi ele geçiren saldırgan, parolanızı hiç bilmeden hesabınıza girmiş gibi davranabilir. Çok faktörlü doğrulama bile bu durumda işe yaramayabilir, çünkü saldırgan zaten doğrulanmış bir oturumu taşıyor.
• Sizin adınıza işlem yapabilir. Siz farkında olmadan bir mesaj gönderebilir, bir ayarı değiştirebilir, e-posta adresinizi değiştirip hesabınızı tamamen ele geçirebilir.
• Sizi kandırabilir. Sayfanın görünümünü değiştirip “oturumunuz sona erdi, tekrar giriş yapın” diyen sahte bir form gösterebilir. Adres çubuğunda doğru site yazdığı için bu sahte forma güvenmemek çok zor.
• Yayılabilir. Bir sosyal ağda XSS açığı varsa, kod her kurbanın profiline kendini kopyalayabilir ve solucan gibi yayılabilir. Bu bir kurgu değil, 2005’te MySpace’te bir XSS solucanı yirmi saatte bir milyondan fazla profile yayıldı.

Bir yönetim panelindeki XSS ise çok daha tehlikeli. Saldırgan kodunu bir yöneticinin göreceği bir yere, örneğin bir destek talebine ya da bir kullanıcı adına bırakırsa, yönetici o sayfayı açtığında kod onun yetkileriyle çalışır. Sitede yazdığımız GitLab güncellemesinde kapatılan açıklardan biri tam da buydu: Özel hazırlanmış bir depo üzerinden başka kullanıcıların oturumlarını etkileyen kalıcı bir XSS. Yönetim arayüzlerindeki bir XSS, saldırganın yöneticinin yetkileriyle ayar değiştirmesine, yeni hesap açmasına ve bazen sunucunun tamamına uzanan bir zincirin ilk halkasını kurmasına izin verebiliyor.

Üç türü

Yansıyan (reflected) XSS. Zararlı kod bir bağlantının içine gizlenir. Örneğin bir sitenin arama sayfası, aradığınız kelimeyi “şunu aradınız” diye ekrana geri basıyorsa ve bunu güvenli şekilde yapmıyorsa, saldırgan arama kelimesinin yerine kod koyduğu bir bağlantı hazırlar. Siz o bağlantıya tıklayınca kod bir anlığına sayfaya yansır ve çalışır. Bu türün çalışması için kurbanın bağlantıya tıklaması gerekir, bu yüzden genellikle oltalama e-postalarıyla birlikte kullanılır.

Depolanan (stored) XSS. Kod siteye kalıcı olarak kaydedilir: bir yoruma, bir profil açıklamasına, bir ürün yorumuna, bir destek talebine. O sayfayı açan herkes etkilenir ve kimsenin bir bağlantıya tıklamasına gerek kalmaz. Bu yüzden en tehlikeli türdür.

DOM tabanlı XSS. Sunucu hiçbir hata yapmaz, sorun tamamen tarayıcıda çalışan kodda ortaya çıkar. Sayfanın kendi JavaScript kodu, adres çubuğundan ya da başka bir kaynaktan aldığı veriyi güvenli olmayan bir biçimde sayfaya ekler. Modern, tek sayfalık uygulamalarda giderek daha sık görülüyor ve sunucu tarafındaki güvenlik denetimleri tarafından genellikle fark edilmiyor.

Nasıl korunulur?

Temel fikir SQL injection’daki ile akraba: Kullanıcıdan gelen şeyi, olduğu yere göre doğru işlemek. XSS’te bu, gelen metni sayfaya basarken onu kod değil, düz yazı olarak ele almak demek. Buna kaçışlama (escaping) ya da kodlama (encoding) deniyor. Bir kullanıcı yorumuna <script> yazsa bile, o metin ekranda zararsız bir yazı olarak görünür, çalışan bir koda dönüşmez.

Burada önemli bir incelik var: Doğru kaçışlama, metnin sayfada nereye konduğuna göre değişiyor. Bir paragrafın içine, bir HTML özelliğinin içine, bir JavaScript değişkeninin içine ya da bir bağlantı adresinin içine konan metin, her biri için farklı şekilde işlenmeli. Bu yüzden elle kaçışlama yapmak hataya açık. Modern yazılım çatılarının çoğu bunu varsayılan olarak doğru yapıyor. Sorunlar genellikle geliştiricinin bu korumayı bilerek ya da bilmeyerek devre dışı bıraktığı yerlerde çıkıyor.

Bunun üstüne birkaç katman daha eklenir:

• Gelen veriyi beklenen biçime göre denetlemek. Bir isim alanına kod benzeri işaretlerin hiç girmemesi gibi. Kullanıcıların biçimlendirilmiş metin yazabildiği yerlerde, izin verilen etiketleri sınırlayan ve gerisini temizleyen güvenilir bir kütüphane kullanmak.
• Content-Security-Policy kullanmak. Bu güvenlik başlığı tarayıcıya “bu sayfada yalnızca şu kaynaklardan gelen koda izin ver” der. Böylece araya sızan bir kod çalışmaya çalışsa bile tarayıcı onu durdurabilir. Sayfaya gömülü betikleri tamamen yasaklayan katı bir politika, XSS’e karşı en güçlü ikinci savunma hattı. Bu site de katı bir Content-Security-Policy kullanıyor ve hiç <script> içermiyor. Bir sitenin bu başlığı kullanıp kullanmadığını güvenlik başlıkları rehberimizdeki yöntemle beş dakikada kontrol edebilirsiniz.
• Oturum çerezlerini HttpOnly olarak işaretlemek. Böyle işaretlenmiş bir çereze sayfadaki kod erişemez. Yani bir XSS açığı olsa bile çerez kolayca çalınamaz. Bu, açığı kapatmaz, ama en yaygın zararını sınırlar.
• Önemli işlemlerde yeniden doğrulama istemek. E-posta adresi ya da parola değiştirmek gibi işlemlerde parolanın tekrar sorulması, XSS ile ele geçirilen bir oturumun hesabı tamamen ele geçirmesini zorlaştırır.

Kullanıcı olarak ne yapabilirsiniz?

XSS sitenin hatası, bu yüzden bir kullanıcı olarak yapabilecekleriniz sınırlı. Ama birkaç alışkanlık riski azaltıyor. Tarayıcınızı güncel tutun. Garip görünen, uzun ve anlamsız karakterlerle dolu bağlantılara, güvendiğiniz bir sitenin adresini taşısalar bile dikkat edin. Bir sitede gezinirken aniden “tekrar giriş yapın” diyen bir pencere çıkarsa, o pencereye bilgi girmek yerine sayfayı kapatıp siteye adres çubuğundan yeniden girin. İşiniz bittiğinde önemli sitelerden çıkış yapmak da, çalınabilecek açık bir oturum bırakmamak demek.

Özetle XSS, bir sitenin kullanıcıdan gelen metne fazla güvenip onu kod gibi çalıştırmasından doğar. O metni her zaman “yalnızca yazı” olarak görmek ve araya birkaç savunma katmanı daha koymak, bu açığı büyük ölçüde kapatır.