Siteler Arası Komut Dosyası Çalıştırma (XSS) Nedir, Nasıl Önlenir?

2. Siteler Arası Komut Dosyası Çalıştırma (XSS) Nedir?

Cross-Site Scripting (XSS), bir web uygulamasındaki güvenlik açığı kullanılarak kötü niyetli komut dosyalarının (çoğunlukla JavaScript) kullanıcıların tarayıcılarında çalıştırılmasına imkân tanıyan bir saldırı sınıfıdır.

XSS, doğrudan veritabanını değil, kullanıcıyı ve tarayıcıyı hedefler. Saldırgan, uygulamanın ürettiği sayfaların içerisine zararlı kod enjekte eder; bu kod, site güvenilir göründüğü için tarayıcı tarafından sanki uygulamanın kendi koduymuş gibi çalıştırılır.

Özetle XSS:

• Kullanıcı oturumlarını ele geçirebilir,
• Çerez, token ve kimlik bilgilerini çalabilir,
• İçeriği manipüle ederek kullanıcılara yanlış bilgi gösterebilir,
• Kullanıcı adına yetkili işlemler gerçekleştirebilir.

Fark: SQL Injection tipik olarak sunucu tarafındaki veritabanını hedeflerken, XSS istemci tarafında çalışır ve tarayıcı güveninden faydalanır.

3. XSS Nasıl Çalışır?

XSS saldırılarının temel mantığı, güvenilmeyen girdinin yeterince doğrulanmadan veya temizlenmeden çıktıya taşınmasıdır. Bu süreç üç basamakta özetlenebilir:

1. Enjeksiyon: Saldırgan, form alanı, URL parametresi, yorum alanı veya API isteği gibi bir giriş noktasına zararlı kod (ör. <script>...</script>) enjekte eder.
2. Yansıma / Depolama: Bu zararlı içerik uygulama tarafından yanıtta ham halde yansıtılır veya veritabanına kaydedilip daha sonra diğer kullanıcılara sunulur.
3. Tetiklenme: Kullanıcı ilgili sayfayı açtığında tarayıcı içeriği işler, zararlı script sayfanın bir parçası gibi çalışır ve tarayıcıda yetkili işlemler gerçekleştirebilir.

Tarayıcı, gelen içeriği uygulama tarafından üretilmiş “güvenli” içerik olarak gördüğü için, saldırgan kodu da aynı güven seviyesiyle yürütür. Bu noktada domain bağlamı devrededir ve zararlı script, ilgili site hangi kaynaklara erişebiliyorsa (çerezler, localStorage, DOM, API çağrıları vb.) onlara da erişebilir.

4. XSS Saldırılarının Temel Sebepleri

XSS zafiyetleri, çoğunlukla girdi doğrulama ve çıktı kodlama eksiklerinden kaynaklanır. Öne çıkan sebepler:

• Güvenilmeyen kaynaktan gelen verinin (kullanıcı girişi, üçüncü taraf API’ler, header’lar vb.) doğrulanmadan veya filtrelenmeden uygulamaya alınması,
• Alınan bu verinin, bağlama uygun kodlama yapılmadan doğrudan HTML, JavaScript veya DOM içine yerleştirilmesi,
• İstemci tarafında, innerHTML gibi riskli DOM API’lerinin kontrolsüz kullanımı,
• Çerçevelerin sağladığı otomatik kaçış mekanizmalarının devre dışı bırakılması (örn. templating motorlarında unsafe kullanım),
• Güvenlik testlerinin sınırlı kalması; yalnızca otomatik tarayıcılarla yetinilmesi.

Sonuç: Özel verilerin sızması, kötü içeriklere yönlendirme, kullanıcı oturumlarının çalınması ve istemci üzerinde zararlı işlemler XSS’in tipik çıktılarıdır.

5. XSS Açıklarını Nasıl Tespit Ederiz?

XSS zafiyetlerinin tespiti için hem otomatik araçlar hem de manuel kod/uygulama analizi gereklidir. Yalnızca tarama aracı kullanmak çoğu zaman yeterli değildir.

Otomatik Tarama: Web güvenlik tarayıcıları, sık bilinen XSS payload’ları ile uygulamayı test ederek potansiyel zafiyetleri işaretler. Ancak yanlış pozitif/negatif oranları sebebiyle her bulgunun uzman tarafından doğrulanması gerekir.

Manuel Analiz: OWASP yaklaşımına göre etkin bir XSS tespiti için:

• Girdilerin hangi noktalarda alındığının,
• Bu girdilerin hangi template, endpoint ve DOM alanlarına taşındığının,
• Hangi bağlamda (HTML body, attribute, JS string, URL, CSS vb.) kullanıldığının

detaylı biçimde incelenmesi gerekir.

İyi uygulama: Geliştirme sürecinde kod inceleme (code review), statik analiz ve OWASP ASVS kontrolleri ile erken aşamada XSS risklerini yakalamak, canlı ortamda tespit etmeye göre çok daha düşük maliyetlidir.

6. XSS Saldırı Türleri

XSS saldırıları genellikle üç ana kategori altında değerlendirilir:

6.1. Stored (Depolanan) XSS

Zararlı komut dosyası, veritabanı, log, mesajlaşma sistemi veya içerik yönetim sistemi gibi bir bileşene kalıcı olarak kaydedilir. İlgili içeriği görüntüleyen her kullanıcıda script otomatik olarak çalışır.

• Yorum alanları, forum mesajları, profil açıklamaları,
• Destek talepleri, log görüntüleme ekranları,
• Yönetim panellerinde listeleme ekranları

Stored XSS genellikle en tehlikeli tür olarak kabul edilir; çünkü etki alanı geniştir.

6.2. Reflected (Yansıyan) XSS

Kullanıcıdan alınan veri (örn. q parametresi, form verisi) aynı yanıt içerisinde doğrudan yansıtılır ve script, genellikle özel hazırlanmış bir link veya istek üzerinden tetiklenir.

Phishing e-postaları veya özel URL’ler, reflected XSS için tipik taşıyıcılardır.

6.3. DOM-Tabanlı XSS

DOM-based XSS’de zafiyet sunucu tarafında değil, tamamen istemci tarafı kodda ortaya çıkar. JavaScript, URL parçalarını veya kullanıcı girdilerini alarak DOM’a kontrolsüz şekilde enjekte eder.

Örneğin: element.innerHTML = location.hash.substring(1); gibi kullanımlar, doğrudan kullanıcı girdisini HTML’e taşıdığı için kritik risk oluşturur.

7. XSS’nin İşletmelere Etkileri Nelerdir?

XSS ihlalleri yalnızca teknik bir açık değildir; itibar, uyum ve iş sürekliliği üzerinde doğrudan etkisi vardır:

• Hassas veri sızıntısı: Çerezler, access token’lar, kişisel veriler ve ödeme bilgileri saldırganın eline geçebilir.
• Oturum ele geçirme: Kullanıcı veya yönetici oturumları çalınarak yetkili işlemler yapılabilir.
• İçerik manipülasyonu: Resmî site üzerinden yanlış bilgi yayılabilir, sahte formlar gösterilebilir.
• Malware yayılımı: Kullanıcı tarayıcılarına zararlı yazılımlar indirtilip çalıştırılabilir.
• Uyum riskleri: KVKK / GDPR kapsamında kişisel verilerin yetkisiz erişimi, veri ihlali bildirim yükümlülüğü ve idari yaptırımlar doğurabilir.
• Marka ve güven kaybı: Kullanıcıların uygulamaya olan güveni azalır; gelir kaybı ve uzun vadeli itibar zedelenmesi yaşanabilir.

8. XSS’nin Hedeflediği Diller ve Çerçeveler

XSS çoğunlukla JavaScript üzerinden gerçekleşse de, yalnızca JS ile sınırlı değildir. Aşağıdaki alanlar riskli bağlamlardır:

• HTML: Etiket, attribute ve inline event handler’lar (örn. onclick, onload),
• JavaScript: Dinamik oluşturulan script blokları, eval benzeri fonksiyonlar,
• CSS: Bazı eski tarayıcılar ve özel durumlar,
• Flash, VBScript: Artık daha az yaygın olsa da tarihi uygulamalar,
• Web framework’leri: Angular, React, Vue, ASP.NET, Django, Laravel vb. – çerçeveler güvenlik için yardımcı olur ancak yanlış kullanım XSS’i mümkün kılar.

Ortak payda: Temizlenmemiş ve bağlama uygun kodlanmamış kullanıcı girdisi her dil ve çerçevede XSS için potansiyel bir kapıdır.

9. XSS ve SQL Injection Arasındaki Farklar

XSS ve SQL Injection (SQLi) sıklıkla birlikte anılsa da, hedefledikleri katman ve etki mekanizmaları farklıdır:

SQL Injection

• Veritabanı katmanını hedefler; sunucu tarafı odaklıdır.
• Girdi parametrelerine SQL komutları enjekte edilir.
• Yetkisiz veri okuma, değiştirme, silme ve yönetimsel komut çalıştırma mümkün olabilir.
• Etki alanı: Veritabanı ve sunucu kaynakları.

Cross-Site Scripting (XSS)

• Kullanıcının tarayıcısını hedefler; istemci tarafı odaklıdır.
• HTML/JS çıktısına script enjekte edilir.
• Oturum çalma, kimlik hırsızlığı, içerik manipülasyonu ve zararlı yönlendirme sağlar.
• Etki alanı: Kullanıcı oturumu, tarayıcı ve görünür içerik.

10. XSS Test Araçları ve Yaklaşımlar

XSS tespitinde hem otomatik araçlar hem de manuel test teknikleri birlikte kullanılmalıdır:

• Web güvenlik tarayıcıları: Nessus, Nikto, OWASP ZAP, Burp Suite gibi araçlar XSS zafiyetlerini taramalar sırasında işaretleyebilir.
• Tarayıcı eklentileri: Geliştirici konsolu ve güvenlik eklentileri ile manuel payload denemeleri yapılabilir.
• API test araçları: SOAP UI / Postman üzerinden şablonlu XSS payload’ları ile REST/SOAP API’ler test edilebilir.
• Özel payload setleri: Farklı bağlamlar (attribute, JS string, HTML body, URL, JSON) için hazırlanmış payload koleksiyonları kullanılmalıdır.

Önemli: Otomatik tarama sonuçları tek başına yeterli değildir. Zafiyetlerin gerçek etkisinin görülebilmesi için mutlaka uzman analizi ve manuel doğrulama yapılmalıdır.

11. XSS ile Neler Yapılabilir?

Başarılı bir XSS saldırısı ile saldırgan, ilgili web uygulamasının yetkileri kapsamında çok geniş bir eylem setine sahip olur:

• Oturum kimliklerinin çalınması: Çerezler, JWT token’lar ve diğer kimlik belirteçleri saldırgana gönderilebilir.
• Hesap ele geçirme: Çalınan oturum bilgileriyle kullanıcı veya yönetici hesabına giriş yapılabilir.
• İçerik manipülasyonu: Form alanları, uyarı mesajları, butonlar ve linkler değiştirilerek kullanıcılar zararlı işlemlere yönlendirilebilir.
• Kötü amaçlı yazılım yayma: Kullanıcılara zararlı dosya indirtme veya tarayıcı eklentisi şeklinde malware yükleme girişimleri kurgulanabilir.
• Kimlik avı sayfaları: Gerçek site üzerinde sahte giriş ekranları gösterilerek kullanıcı adı/parola toplanabilir.
• Farklı sistemlere sıçrama: Elde edilen bilgilerle VPN, e-posta, CRM, ERP gibi sistemlere sızma girişimleri yapılabilir.

12. Siteler Arası Komut Dosyası Çalıştırmaya (XSS) Karşı Nasıl Korunulur?

XSS’e karşı korunma, çok katmanlı bir yaklaşım gerektirir. Tek bir ürün veya ayar başına buyruk çözüm sunmaz; güvenli kod geliştirme, altyapı kontrolleri ve test birlikte ele alınmalıdır.

12.1. Girdi Doğrulama (Input Validation)

• Beyaz liste yaklaşımı: Her alan için izin verilen karakter seti, uzunluk ve format tanımlayın.
• Kod, script veya HTML içermemesi gereken alanlarda bu tür içerikleri tamamen reddedin.
• Sunucu tarafı validasyonunu istemci tarafı validasyonunun alternatifi değil, tamamlayıcısı olarak uygulayın.

12.2. Çıkış Kodlama (Output Encoding)

Kullanıcıdan alınan veriyi bağlama uygun şekilde kodlamak, XSS önlemenin en kritik adımıdır.

• HTML bağlamı: Metni HTML body’de gösterirken HTML encode uygulayın.
• Attribute bağlamı: HTML attribute içinde kullanırken ek attribute encoding uygulayın.
• JavaScript bağlamı: JS string içinde kullanılacak veriyi JS için güvenli biçimde encode edin veya mümkünse script içine asla doğrudan yerleştirmeyin.
• URL bağlamı: Parametreleri URL encode edin.

12.3. Güvenli DOM Manipülasyonu

• innerHTML yerine textContent ve setAttribute gibi daha güvenli API’leri tercih edin.
• DOM-based XSS’e karşı şablon motorlarının otomatik kaçış yeteneklerini kullanın.
• URL parçalarını (hash, query string) doğrudan HTML’e taşımaktan kaçının.

12.4. WAF ve Content Security Policy (CSP)

• Web Application Firewall (WAF): Bilinen XSS payload’larının önemli bir kısmını bloklayarak ek bir savunma katmanı oluşturur; ancak tek başına yeterli değildir.
• Content Security Policy (CSP): Hangi kaynaklardan script çalıştırılabileceğini tanımlayarak zararlı script’lerin etkisini ciddi şekilde kısıtlar.
• İmkan varsa unsafe-inline kullanmaktan kaçının ve nonce / hash tabanlı CSP yapılandırmalarını tercih edin.

12.5. Güvenli Çerez ve Oturum Yönetimi

• HttpOnly: Çerezlerin JavaScript ile okunmasını engelleyerek XSS’in oturum çalma etkisini azaltın.
• Secure: Çerezlerin yalnızca HTTPS üzerinden iletilmesini sağlayın.
• SameSite: Cross-site isteklerde çerez gönderimini kontrol ederek riskleri düşürün.
• Oturum sürelerini makul tutun; kritik aksiyonlarda yeniden kimlik doğrulama isteyin.

12.6. Test, Eğitim ve Süreç

• Geliştirme yaşam döngüsüne (SDLC) güvenlik testlerini entegre edin (SAST, DAST, SCA).
• Geliştiricilere düzenli olarak OWASP Top 10 ve XSS odaklı güvenli kod geliştirme eğitimleri verin.
• Önemli değişiklikler sonrası hedefli uygulama güvenliği testleri ve pentest çalışmaları yürütün.

Sık Sorulan Sorular: XSS ve Uygulama Güvenliği

XSS ile ilgili en çok sorulan soruları ve kısa, anlaşılır cevaplarını aşağıda bulabilirsiniz. Teknik ekibinizin ve iş birimlerinin aynı sayfada buluşabilmesi için hem teknik hem de iş odaklı bir dil tercih edilmiştir.