Bir Web Sitesine Güvenirsiniz. Peki Ya O Web Sitesi Size Karşı Kullanılırsa?

Adres doğru. HTTPS kilidi yerinde. Tasarım her zamanki gibi. Kısacası her şey normal görünüyor.

Fakat siz fark etmeden, tarayıcınızda çalışan kodun bir kısmı aslında o web sitesine değil, bir saldırgana ait olabilir.

Üstelik bunun gerçekleşmesi için bilgisayarınıza virüs bulaşmasına ya da şüpheli bir dosya indirmenize bile gerek yoktur.

Sadece güvenilir olduğunu düşündüğünüz bir web sitesini ziyaret etmeniz yeterli olabilir.

Kulağa biraz abartılı geliyor olabilir. Ancak bu senaryo, web güvenliğinde yıllardır bilinen ve hâlâ en yaygın güvenlik açıklarından biri olan Cross-Site Scripting (XSS) ile mümkündür.

Bir önceki yazıda SQL Injection saldırılarından bahsetmiş ve kullanıcı girdisinin yanlış işlenmesinin veritabanını nasıl tehlikeye atabildiğini görmüştük.

Bu kez hedef veritabanı değil.

Hedef, doğrudan sizsiniz.

XSS Nedir?

XSS (Cross-Site Scripting), bir web uygulamasının kullanıcıdan aldığı veriyi güvenli bir şekilde işlememesi sonucunda, saldırganın hazırladığı istemci tarafı kodunun (çoğunlukla JavaScript) başka kullanıcıların tarayıcılarında çalıştırılmasına imkân veren bir güvenlik açığıdır.

İlk bakışta teknik bir tanım gibi görünebilir. Ancak mantığı aslında oldukça basittir.

Tarayıcınız, ziyaret ettiğiniz web sitesinden gelen kodlara güvenir. Çünkü bunların sitenin geliştiricileri tarafından gönderildiğini varsayar.

Sorun, web uygulamasının kullanıcıdan gelen içerikleri de aynı güvenle işlemeye başlamasıyla ortaya çıkar.

Eğer uygulama, kullanıcı tarafından girilen veriyi güvenli hâle getirmeden sayfaya yerleştirirse, tarayıcı bu içeriğin saldırgana ait olduğunu anlayamaz.

Onu da web sitesinin bir parçası gibi görür.

İşte XSS tam olarak bu güven ilişkisinden yararlanır.

SQL Injection'dan Farkı Nedir?

İlk yazıda gördüğümüz SQL Injection ile XSS'in ortak bir noktası vardır:

Her ikisi de kullanıcıdan gelen verinin yanlış işlenmesinden kaynaklanır.

Ancak hedefleri tamamen farklıdır.

SQL Injection, sunucu tarafındaki veritabanını hedef alır.

XSS ise kullanıcının tarayıcısını hedef alır.

Başka bir ifadeyle SQL Injection'da saldırgan sunucuya istediğini yaptırmaya çalışırken, XSS'te kullanıcının gördüğü ve etkileşim kurduğu sayfayı manipüle etmeye çalışır.

Bu yüzden XSS, çoğu zaman teknik bir saldırıdan çok bir güven istismarıdır.

Kullanıcı güvenilir olduğunu düşündüğü bir web sitesine güvenir; tarayıcı da o güveni saldırgan adına kullanır.

XSS Nasıl Ortaya Çıkar?

Bir haber sitesinde yorum yaptığınızı düşünün.

Yazdığınız yorum birkaç saniye sonra herkes tarafından görülebiliyor.

Normal şartlarda bu yorum yalnızca düz metin olarak görüntülenmelidir.

Ancak uygulama, kullanıcıdan gelen içeriği güvenli hâle getirmeden sayfaya yerleştiriyorsa, tarayıcı bunun yalnızca bir yorum olmadığını düşünebilir.

Ve saldırganın hazırladığı içerik, o sayfayı ziyaret eden diğer kullanıcıların tarayıcılarında çalışabilir.

Aslında sorun oldukça basittir:

Uygulama, kullanıcıdan gelen veriyi güvenilir içerikten ayırt edememektedir.

Bunu somutlaştıralım. Yorum kutusuna şu metni yazan bir kullanıcı düşünün:

<script>alert(document.cookie)</script>

<script>alert(document.cookie)</script>

Eğer uygulama bu girdiyi güvenli hâle getirmeden doğrudan sayfaya yazdırıyorsa, tarayıcı bunu bir yorum metni olarak değil, çalıştırılacak bir JavaScript kodu olarak yorumlar. Yukarıdaki basit örnek yalnızca bir uyarı penceresi açar; fakat alert() yerine kullanıcının oturum çerezini bir sunucuya gönderen birkaç satırlık kod konulduğunda, saldırgan o kullanıcının oturumunu ele geçirebilir.

XSS'in Üç Farklı Türü

Her XSS saldırısı aynı şekilde gerçekleşmez.

Reflected XSS

Bu tür saldırılarda zararlı içerik kalıcı olarak saklanmaz.

Genellikle saldırgan, özel olarak hazırlanmış bir bağlantıyı kullanıcıya gönderir. Kullanıcı bağlantıyı açtığında uygulama, URL'den gelen veriyi güvenli şekilde işlemeyerek sayfaya geri yansıtır.

Bu nedenle özellikle sosyal mühendislik ve oltalama saldırılarında sıkça görülür.

Stored XSS

Stored XSS, etkisi bakımından en ciddi türlerden biridir.

Burada saldırganın eklediği içerik uygulamanın veritabanında saklanır.

Örneğin bir forum mesajı, blog yorumu veya kullanıcı profiline eklenen zararlı içerik, aynı sayfayı ziyaret eden tüm kullanıcıları etkileyebilir.

Yani saldırı tek bir kişiyi değil, yüzlerce hatta binlerce kullanıcıyı hedef alabilir.

DOM-Based XSS

Bu türde sorun sunucuda değil, istemci tarafındaki JavaScript kodundadır.

Sayfa yüklendikten sonra çalışan JavaScript, kullanıcıdan gelen veriyi güvenli şekilde işlemezse güvenlik açığı tamamen tarayıcı içerisinde oluşabilir.

Özellikle modern tek sayfa uygulamalarında (SPA) bu tür açıklara karşı dikkatli olunmalıdır.

Peki Bir Saldırgan Bununla Ne Yapabilir?

İnternette XSS örnekleri incelendiğinde çoğu zaman ekranda açılan küçük bir uyarı penceresi görürsünüz.

Aslında bu yalnızca güvenlik açığının var olduğunu göstermek için kullanılan zararsız bir örnektir.

Gerçek saldırılar ise çok daha sessiz gerçekleşir.

Başarılı bir XSS saldırısı sonucunda saldırgan:

kullanıcıyı sahte giriş sayfalarına yönlendirebilir,
sayfanın içeriğini değiştirerek yanlış bilgiler gösterebilir,
kullanıcı adına belirli işlemlerin gerçekleştirilmesine zemin hazırlayabilir,
zararlı sitelere yönlendirme yapabilir,
uygulamanın istemci tarafındaki davranışını değiştirebilir.

En tehlikeli kısmı ise şudur:

Kullanıcı çoğu zaman olağan dışı hiçbir şey fark etmez.

XSS'e Karşı Nasıl Korunabiliriz?

İyi haber şu ki XSS, doğru yazılım geliştirme alışkanlıklarıyla büyük ölçüde önlenebilir.

OWASP'ın önerdiği temel yaklaşımlar şunlardır:

Output Encoding: Kullanıcıdan gelen veriyi bulunduğu bağlama uygun şekilde kodlayarak tarayıcının bunu çalıştırılacak kod yerine düz metin olarak yorumlamasını sağlamak.
Input Validation: Beklenmeyen verileri doğrulamak ve mümkün olduğunca sınırlandırmak.
Content Security Policy (CSP): Tarayıcının hangi kaynaklardan kod çalıştırabileceğini kontrol altına almak.
Modern framework'lerin yerleşik korumalarını doğru kullanmak: React, Angular ve Vue gibi framework'ler, ekrana yazdırılan veriyi varsayılan olarak otomatik encode ederek birçok XSS riskini azaltır. Ancak geliştirici bu korumayı bilerek devre dışı bıraktığında güvenlik açığı geri döner:
React'te dangerouslySetInnerHTML kullanımı, HTML'i sanitize etmeden doğrudan sayfaya yazar.
Angular'da bypassSecurityTrustHtml gibi bypassSecurityTrustAs* fonksiyonları, framework'ün yerleşik güvenlik kontrolünü devre dışı bırakır.
Vue'da v-html direktifi de aynı şekilde ham HTML'i doğrudan render eder.

Bu yöntemler bazen gerçekten gerekli olabilir (örneğin bir WYSIWYG editörden gelen içeriği göstermek için), ama bu durumlarda veriyi DOMPurify gibi bir kütüphaneyle sanitize etmeden kullanmak, framework'ün sağladığı korumayı tamamen ortadan kaldırır.

Hiçbir yöntem tek başına yeterli değildir. Güvenli uygulamalar, bu katmanları birlikte kullanır.

Sonuç

SQL Injection bize kullanıcı girdisine güvenmenin veritabanı için ne kadar büyük bir risk oluşturduğunu göstermişti.

XSS ise aynı hatanın bu kez kullanıcıların tarayıcılarını hedef alabildiğini gösteriyor.

Aslında her iki saldırının da temelinde aynı hata yatıyor:

Kullanıcıdan gelen veriye gereğinden fazla güvenmek.

Güvenli yazılım geliştirmek, yalnızca güçlü sunucular kurmak ya da en yeni teknolojileri kullanmak değildir.

Bazen güvenliği belirleyen şey, ekrana yazdırdığınız tek bir satır veriyi nasıl işlediğinizdir.

Bir sonraki yazıda ise kullanıcı hiçbir şeyden şüphelenmezken onun adına işlem yapılmasını mümkün kılan bir başka önemli web güvenliği açığını, Cross-Site Request Forgery (CSRF) saldırılarını inceleyeceğiz.

Kaynakça

YAZAR

Contents