Çapraz Site Komut Dosyası (XSS), en yaygın ve tehlikeli web uygulama açıklarından biri olmaya devam ediyor. Yıllardır OWASP Top Ten listesini domine ederek saldırganların, diğer kullanıcılar tarafından görüntülenen web sayfalarına kötü amaçlı komut dosyaları enjekte etmesine olanak tanıyor. Temel kavram—kullanıcı girdisine fazla güvenmek—basit olsa da, önleme stratejileri karmaşıktır ve nüanslıdır. Geliştiriciler olarak, basit regex filtrelerinin ötesine geçmeli ve sıkı girdi doğrulaması, bağlam duyarlı çıkış kodlaması ve modern çerçeve korumalarını birleştiren katmanlı bir savunma stratejisi benimsemelidir.
Manzarayı Anlamak: Üç Tür XSS
Önlemeye dalmadan önce, her biri biraz farklı bir savunma yaklaşımı gerektirdiğinden, XSS'nin üç temel varyantı arasındaki farkı anlamak kritik öneme sahiptir:
- Yansıtılan XSS: Kötü amaçlı komut dosyası mevcut HTTP isteğinden gelir. Sıkça bir phishing bağlantısı aracılığıyla iletilir. Uygulama, girdiyi uygun şekilde temizlemeden kullanıcıya yansıtır.
- Saklı (Kalıcı) XSS: Kötü amaçlı komut dosyası, hedef sunucuda kalıcı olarak saklanır; örneğin bir veritabanında, yorum alanında veya forum gönderisinde. Bir kullanıcı bu veriyi her çağırdığında komut dosyası yürütülür.
- DOM tabanlı XSS: Açık, sunucu tarafı kodu yerine istemci tarafı kodunda bulunur. Saldırgan, mağazanın tarayıcısındaki DOM ortamını değiştirerek istemci tarafı komut dosyalarının beklenmedik şekilde yürütülmesine neden olur.
Teslim mekanizmaları farklılık gösterse de, kök neden her zaman aynıdır: uygulama yürütülebilir kod ile güvenilir veri arasında ayrım yapmaz.
Altın Kural: Bağlam Duyarlı Çıkış Kodlaması
XSS'ye karşı en etkili savunma, girdiyi filtrelemek değil, tarayıcıda render edilen tüm verilerin belirli bağlamı için doğru şekilde kodlandığını sağlamaktır. Tarayıcılar, bir etiketin içinde, bir özniteliğin içinde, bir komut dosyası bloğunun içinde veya bir CSS stilinde olup olmadığına bağlı olarak HTML'i farklı yorumlar. Bağlamı hesaba katmamak, başarılı saldırıların en yaygın nedenidir.
Aşağıdaki, verinin otomatik olarak kaçış karakteri (escape) yapılmadığı bir sunucu tarafı şablon motorunda (Python'un Jinja2'si veya Node'un EJS'si gibi) tehlikeli bir uygulamayı düşünün:
<!-- GÜVENLİKSİZ KOD -->
<div>
Merhaba, <script>{user_input}</script>!
</div>Eğer user_input değeri alert('XSS') ise, resulting HTML şu hale gelir: Hello, !, bu da komut dosyasını hemen yürütür. Çözüm, < ve > gibi özel karakterlerin HTML varlık karşılıklarına (< ve >) dönüştürüleceği şekilde çıkışı kodlamaktır:
<!-- GÜVENLİ KOD -->
<div>
Merhaba, <%= user_input %>!
</div>React, Angular veya Vue gibi modern çerçevelerde, çıkış kodlaması genellikle varsayılan davranıştır. Birleştirme sözdizimini (örneğin React'te {userInput}) kullandığınızda, çerçeve içeriği DOM'a eklemekten önce otomatik olarak kaçış karakteri yapar ve bu da saklı ve yansıtılan XSS'ye karşı önemli bir koruma katmanı sağlar.
DOM Tabanlı XSS'ye Karşı Savunma
DOM tabanlı XSS, açığın HTML render etme yerine JavaScript yürütme içinde bulunduğu için benzersiz bir zorluk sunar. Saldırganlar, doğrulama olmadan kullanıcı kontrolündeki verileri kabul eden güvensiz DOM API'lerinden yararlanır.
Yaygın tehlikeli API'ler arasında document.write(), innerHTML ve location.hash bulunur. Bu işlevleri güvensiz girdilerle kullanmak felaketle sonuçlanır.
<!-- TEHLİKELİ DOM JAVASCRIPT -->
<script>
// Asla temizlenmemiş veri ile innerHTML kullanmayın
document.getElementById('output').innerHTML = location.hash.substring(1);
</script>Bunu önlemek için, metin eklemek için textContent veya güvenli DOM manipülasyon yöntemleri kullanın. HTML eklemeniz gerekiyorsa, eklemeden önce girdiyi temizleyen güvenilir bir kütüphane kullanın. Ayrıca, İçerik Güvenlik Politikası (CSP), DOM tabanlı XSS için kritik bir güvenlik ağı olarak görev yapar. Komut dosyalarının hangi kaynaklardan yüklenip yürütülebileceğini kısıtlayarak, bir enjeksiyon gerçekleşse bile CSP birçok XSS yükünü etkisiz hale getirebilir.
İkincil Katman Olarak Girdi Doğrulaması
Çıkış kodlaması birincil savunma olsa da, girdi doğrulaması değerli bir ikincil katman görevi görür. Bu strateji, sıkça "beyaz liste" olarak adlandırılır; kabul edilebilir girdinin nasıl göründüğünü tanımlar ve geri kalanını reddeder. Örneğin, bir alan bir e-posta adresi bekliyorsa, geçerli e-posta formatlarını sıkı bir şekilde eşleştiren bir regex kullanın. Yaş bekliyorsa, girdinin makul bir aralıktaki bir tam sayı olduğundan emin olun.
Bununla birlikte, yalnızca girdi doğrulamasına güvenmeyin. <script> veya onerror= gibi belirli anahtar kelimeleri kara listeye almak, saldırganların kodlama, harf durumu değişiklikleri veya yeni olay işleyicileri kullanarak bu filtreleri atlaması nedeniyle etkisizdir. Doğrulama, enjeksiyona karşı tek güvenlik bariyeri olarak değil, iş kurallarını uygulamak için kullanılmalıdır.
Sonuç
XSS'yi önlemek çok yönlü bir yaklaşım gerektirir. Tüm kullanıcı girdisinin kötü amaçlı olduğunu varsayarak başlayın. Çıkış kodlamasını varsayılan olarak ele alan modern çerçevelerden yararlanın. Özel çözümler oluştururken bağlam duyarlı kodlama uygulayın. Güvensiz API'ler için istemci tarafı JavaScript'i denetleyerek DOM tabanlı saldırılara karşı savunma yapın. Son olarak, sağlam bir son savunma hattı sağlamak için İçerik Güvenlik Politikası (CSP) başlıklarını dağıtın. Bu uygulamaları geliştirme yaşam döngünüze entegre ederek, XSS riskini önemli ölçüde azaltabilir ve daha güvenli, güvenilir web uygulamaları oluşturabilirsiniz.