XSS Koruması: Çeşitli Frameworklerde Bağlama Özgü Savunmalar

XSS'in Temel Taşı: Bağlama Özgü Çıktı Kodlama (Context-Aware Output Encoding)

Önceki derste, enjeksiyonu önlemek için veriyi "sanitize" etmemiz veya parametreli sorgular kullanmamız gerektiğini gördük. XSS için de benzer bir mantık geçerlidir, ancak burada "sanitize" etme eylemi çok daha karmaşıktır. Çünkü verinin nereye yazılacağına bağlı olarak farklı karakterler tehlikeli hale gelir. Örneğin, < karakteri bir <div> elementi içinde tehlikeliyken, bir JavaScript string'i içinde zararsız olabilir. Tersine, tek tırnak (') karakteri bir <div> içinde zararsızken, bir JavaScript string'ini erken kapatarak kod enjeksiyonuna olanak tanıyabilir.

Bu nedenle, etkili bir XSS savunması tek bir "kaçış" (escape) fonksiyonuna dayanamaz; bağlama duyarlı olmak zorundadır. Bu temel prensibi ve farklı bağlam türlerini anlamak için OWASP'ın bu konudaki kılavuzu mükemmel bir başlangıç noktasıdır.

Artık teorik temeli anladığımıza göre, bu prensiplerin önde gelen web framework'lerinde nasıl uygulandığını karşılaştıralım.

Framework'ler Arası Karşılaştırma

Her modern framework, XSS'e karşı yerleşik koruma mekanizmaları sunar. Ancak bu korumaların varsayılan davranışları, kapsamları ve bilinçli olarak devre dışı bırakılabilecekleri "kaçış yolları" (escape hatches) farklılık gösterir.

1. Django (Python)

Django, sunucu taraflı render (SSR) yapan framework'ler arasında en sağlam XSS korumalarından birine sahiptir.

• Varsayılan Davranış: Django'nun şablon motoru, bir değişkene ({{ degisken }}) basılan tüm verileri varsayılan olarak HTML-encode eder. Bu, < karakterini <'e, > karakterini >'e dönüştürerek en temel HTML enjeksiyonlarını engeller.
• Kaçış Yolları: Django, geliştiricilere bu korumayı bilinçli olarak aşmaları için birkaç yol sunar. İşte bu noktalar, kod incelemesinde odaklanmanız gereken kritik sink'lerdir.

Aşağıdaki Semgrep kılavuzu, Django'daki bu tehlikeli desenleri mükemmel bir şekilde özetlemektedir.

2. Spring (Java) & Thymeleaf

Spring Boot ile genellikle kullanılan Thymeleaf şablon motoru, Django'ya benzer şekilde, bağlama duyarlı otomatik kaçış özelliği sunar.

• Varsayılan Davranış: Thymeleaf, bir değişkenin kullanıldığı bağlamı anlar ve uygun kaçış yöntemini otomatik olarak uygular.
  • th:text="'<script>alert(1)</script>'" : Bu, <script>... etiketini HTML entity'lerine dönüştürerek (<script>...) güvenli bir şekilde ekrana basar.
  • th:attr="data-id=${degisken}": Değişkeni nitelik bağlamı için uygun şekilde kodlar.
  • JavaScript inlining: let username = /*[[${kullaniciAdi}]]*/ 'default'; ifadesinde Thymeleaf, kullaniciAdi değişkeninin bir JavaScript string'i içinde olduğunu anlar ve " veya ' gibi karakterleri \" veya \' şeklinde doğru bir şekilde kaçırır.
• Kaçış Yolu: Otomatik kaçışı devre dışı bırakmak için th:utext (unescaped text) kullanılır. th:utext kullanımı, mark_safe gibidir ve kod incelemesinde mutlaka sorgulanması gereken bir durumdur.
• Anti-Pattern: OWASP kılavuzunda da belirtildiği gibi, Spring Interceptor veya Servlet Filter gibi mekanizmalarla tüm parametreleri global olarak encode etmeye çalışmak hatalı bir yaklaşımdır. Çünkü bu katman, verinin nihayetinde hangi bağlamda (HTML, JS, CSS) render edileceği bilgisine sahip değildir ve yanlış kodlama yaparak hem güvenliği sağlayamaz hem de uygulamayı bozabilir.

3. React (JavaScript)

React gibi istemci taraflı (client-side) framework'lerde XSS dinamiği, sunucu taraflı render'dan farklıdır. Burada sink'ler, doğrudan DOM'u manipüle eden JavaScript fonksiyonlarıdır.

• Varsayılan Davranış: React, JSX içinde {} süslü parantezlerle render edilen tüm ifadeleri varsayılan olarak string'e çevirir ve HTML olarak yorumlamaz. Bu, en yaygın Reflected XSS saldırılarına karşı güçlü bir koruma sağlar. Örneğin, <div>{userInput}</div> yazdığınızda, userInput içinde <script> etiketleri olsa bile bunlar metin olarak görünecektir.
• Kaçış Yolu: React'in en bilinen tehlikeli "kaçış yolu" dangerouslySetInnerHTML prop'udur. Adından da anlaşılacağı gibi, bu prop'u kullanmak, React'in varsayılan XSS korumasını tamamen devre dışı bırakır ve sağlanan string'i doğrudan HTML olarak DOM'a enjekte eder.
• Diğer Zafiyet Vektörleri:
  • URL Enjeksiyonu: React, bir <a> etiketinin href özelliğine atanan javascript:alert(1) gibi bir URL'i engellemez. Bu, JSX'in kendisi güvenli olsa bile, nitelikler üzerinden XSS'e yol açabilir.
  • DOM Manipülasyonu: innerHTML, outerHTML gibi doğrudan DOM manipülasyonu yapan vanilla JavaScript fonksiyonlarının kullanımı da React'in korumalarını atlar.

Bu tehlikeli kullanımları ve çözümlerini anlamak için aşağıdaki video mükemmel bir kaynaktır.

4. ASP.NET (C#)

ASP.NET Core'da kullanılan Razor şablon motoru da varsayılan olarak güçlü XSS korumaları sunar.

• Varsayılan Davranış: Razor, @ karakteri ile basılan tüm değişkenleri otomatik olarak HTML-encode eder. Bu, Django ve Thymeleaf'e benzer bir varsayılan güvenlik duruşudur.
• Kaçış Yolu: Bu otomatik kodlamayı atlamak için Html.Raw() metodu kullanılır. string bir değeri IHtmlContent tipine dönüştürerek Razor'a "bu içeriğin güvenli olduğunu ve doğrudan render edilmesi gerektiğini" söyler. Html.Raw(kullaniciGirdisi) kullanımı, kod incelemelerinde kırmızı bayrak olmalıdır.
• Bağlam Farkındalığı: Razor, HTML body ve attribute'lar için varsayılan olarak güvenli olsa da, JavaScript bağlamları için geliştiricinin daha dikkatli olması gerekir. Değişkenleri doğrudan <script> blokları içine yazmak, JavaScript kaçış kurallarının uygulanmasını gerektirir. Bunun için System.Text.Encodings.Web.JavaScriptEncoder gibi sınıflar kullanılabilir.

Özet ve Katmanlı Savunma

Aşağıdaki tablo, tartıştığımız framework'lerin XSS'e karşı yaklaşımlarını özetlemektedir:

Derinlemesine Savunma: Content Security Policy (CSP)

Çıktı kodlama, XSS'e karşı birincil savunma hattıdır. Ancak bir hata yapılması durumunda devreye girecek ikinci bir savunma katmanı olarak Content Security Policy (CSP) kritik bir rol oynar. CSP, sunucudan tarayıcıya gönderilen bir HTTP yanıt başlığıdır ve tarayıcının hangi kaynaklardan (script'ler, stiller, resimler vb.) içerik yükleyebileceğini kısıtlayan bir beyaz liste (allow-list) tanımlar.

CSP, özellikle nonce (number used once) tabanlı politikalarla uygulandığında son derece etkilidir. Bu yaklaşımda, sunucu her sayfa isteği için rastgele bir nonce değeri üretir, bu değeri hem CSP başlığına hem de güvendiği <script> etiketlerine ekler. Saldırganın enjekte ettiği script bu nonce değerini bilmediği için tarayıcı tarafından çalıştırılmaz. Bu ileri düzey teknikler, bir sonraki "İstemci Taraflı Saldırılar" modülünde daha detaylı incelenecektir.

Kapanış

Bu derste, farklı web framework'lerinin XSS'e karşı nasıl farklı ancak temelde benzer prensiplere dayanan savunma mekanizmaları sunduğunu karşılaştırdık.

Ana Çıkarımlar:

• XSS Savunması Bağlam Gerektirir: Tek bir kaçış fonksiyonu yeterli değildir; savunma, verinin render edildiği bağlama (HTML, attribute, JS, CSS, URL) göre yapılmalıdır.
• Framework'ler Varsayılan Olarak Güvenlidir: Modern sunucu taraflı framework'ler (Django, ASP.NET/Razor, Spring/Thymeleaf) varsayılan olarak çıktıları kodlayarak güçlü bir başlangıç noktası sunar.
• "Kaçış Yollarına" Dikkat: mark_safe, Html.Raw, th:utext gibi fonksiyonlar, bu güvenliği bilinçli olarak devre dışı bırakır ve kod incelemelerinde en çok odaklanılması gereken yerlerdir.
• İstemci Tarafı Farklıdır: React gibi istemci tarafı kütüphaneler, DOM'a doğrudan HTML enjekte eden dangerouslySetInnerHTML gibi fonksiyonlar etrafında farklı bir risk modeli sunar. Çözüm, genellikle HTML sanitizasyonudur.
• Katmanlı Savunma Esastır: Mükemmel çıktı kodlamaya ek olarak, CSP gibi mekanizmalar, olası bir hatanın istismar edilmesini önleyen kritik bir ikinci savunma hattı sağlar.

Bu dersle birlikte, kod inceleme metodolojimizin temel analitik yaklaşımlarını tamamlamış olduk. Bir sonraki modülde, bu derslerde edindiğimiz bilgileri kullanarak daha karmaşık enjeksiyon saldırılarını analiz etmeye başlayacağız. İlk olarak, bir saldırganın doğrudan bir yanıt alamadığı durumlarda bile veritabanından bilgi sızdırmasına olanak tanıyan Kör SQL Enjeksiyonu (Blind SQL Injection) ve bant dışı (out-of-band) veri sızdırma tekniklerini inceleyeceğiz.