1. GİRİŞ

Cross‑Site Scripting (XSS), web uygulamalarında kullanıcıya döndürülen içeriklerin saldırgan tarafından manipüle edilmesiyle tarayıcıda zararlı script'lerin çalıştırılmasına neden olan bir güvenlik sınıfıdır. XSS hâlen OWASP Top 10 içinde önemli bir yer tutar çünkü kullanıcı etkileşimi olan her uygulama potansiyel hedeftir. Modern SPA'lar, server‑rendered uygulamalar, mobil webview'ler ve third‑party widget'lar XSS yüzeyini genişletir. Bu makale mühendis ve mimarlara XSS'in teknik anatomisini, türlerini, tespit ve mitigasyon stratejilerini, framework‑odaklı çözümleri ve operasyonel pratikleri kapsamlı şekilde sunar.

Neden bugün önemli?

• Kullanıcı başına güvenli oturumlar ve kimlik bilgileri barındıran uygulamalar XSS ile hesap ele geçirilmesine açıktır.
• Third‑party içerikler ve client‑side rendering (CSR) XSS tehdidini yeni biçimlerde ortaya çıkarıyor.
• Regülasyon ve kullanıcı güveni; XSS kaynaklı veri sızıntıları maliyetli ve itibar zedeleyicidir.

Kimler için önemli?

• Frontend ve backend geliştiricileri
• Security mühendisleri ve pentest ekipleri
• Prod/sysadmin ve DevOps ekipleri
• Ürün sahipleri ve yöneticiler

2. KAVRAMSAL TEMELLER

2.1 XSS nedir — net tanım

XSS, bir web uygulamasının kullanıcıya gönderdiği içerik içinde saldırgan kontrollü script veya içerik parçalarının tarayıcıda çalıştırılması durumudur. Amacı genellikle çerez/oturum çalma, keystroke logging, content spoofing veya kullanıcıyı zararlı bir siteye yönlendirmektir.

2.2 Temel terminoloji

• Payload: Saldırganın gönderdiği zararlı JavaScript/HTML kodu.
• Context: Payload'ın yerleştirildiği bağlam — HTML body, attribute, JavaScript string, URL param vb.; bağlam doğru şekilde anlaşılmadan sanitization yetersiz kalır.
• Escaping / Encoding: Output'u tarayıcı bağlamına göre güvenli hale getirme tekniği.
• Sanitization: Girdi verisinden tehlikeli içeriklerin temizlenmesi veya yasaklanması.

2.3 XSS türleri (yüksek seviyede)

• Reflected XSS: Saldırgan payload'ı URL veya istek parametresine koyar, uygulama bu veriyi doğrulamadan yanıt içinde geri döndürür; hedef kullanıcı linke tıkladığında exploit gerçekleşir.
• Stored (Persistent) XSS: Payload veritabanı, mesaj, yorum gibi kalıcı yerde depolanır; diğer kullanıcılar bu içeriği görüntülediğinde script çalışır.
• DOM‑based XSS: Sunucu tarafı değişiklik yok; client‑side JavaScript DOM'u saldırgan kontrollü veriyle manipüle ederek XSS'e neden olur.

3. NASIL ÇALIŞIR? — TEKNİK MEKANİK, BAĞLAMLAR VE AKIŞ

3.1 Bağlam odaklı risk — neden context önemlidir?

Output'un yerleştirildiği bağlam (HTML element içi, attribute, JavaScript string, URL, CSS, HTML comment, textarea) payload'un nasıl çalışacağı ve hangi escaping tekniğinin uygulanacağını belirler. Örneğin attribute içinde """ veya "'" kaçışları gerekirken JavaScript string içinde backslash‑escape gerekir; tek tip sanitization çoğu zaman yetersizdir.

3.2 Reflected XSS akışı (örnek)

1. Kullanıcıya gönderilecek URL oluşturulur: https://site.example/search?q=
2. Site backend q parametresini alır ve sonucu HTML içinde gösterir: "Arama sonuçları için: q"
3. Eğer q uygun şekilde escaped edilmezse payload tarayıcıda çalışır; çerezler veya sessionStorage çalınabilir.

3.3 Stored XSS akışı (örnek)

1. Kullanıcı yorum formuna gönderir ve uygulama bunu doğrulamadan DB'ye yazar.
2. Başka bir kullanıcı veya admin panel bu yorumu görüntülediğinde script çalışır ve hedef sistemdeki yetkili session'ı ele geçirir.

3.4 DOM‑based XSS akışı

Modern client‑side uygulamalarda URL fragment, location.hash veya document.write gibi API'lerin saldırgan kontrollü veriyi doğrudan DOM'a yazması DOM‑based XSS'e yol açar. Server tarafında yanıt değişmediği için klasik WAF/DAST araçları bunu atlatabilir; client‑side kod incelemesi ve CSP önemli rol oynar.

3.5 Çeşitli tarayıcı bağlamları ve örnek payload'lar

- HTML body: <script>...</script> veya <img src=x onerror=...>
- Attribute: <div data‑x="..."> — burada " veya ' kaçıĢı kritik
- JavaScript string: <script>var s = '...';</script> — backslash escaping ve JSON encoding önemlidir
- URL: location.href veya location.hash kullanımı doğrudan DOM XSS'e sebep olur.

4. GERÇEK DÜNYA KULLANIMLARI VE VAKA ÖRNEKLERİ

4.1 Stored XSS via Comment Widgets

Yaygın bir vaka: blog veya makale yorumlarında sanitization yapılmaması. Saldırgan, script içeren bir yorum bırakır; birçok ziyaretçi bu yorumu görüntülediğinde tarayıcıda çalışır ve keystroke logging veya session hijacking gerçekleşir.

4.2 Reflected XSS via Search or Redirect Parameters

Saldırgan hazırladığı URL'yi e‑posta veya sohbet yoluyla dağıtır; hedef kullanıcının tıklaması ile exploit tetiklenir. Özellikle redirect parametresi içeren siteler open redirect + reflected XSS kombo riski taşır.

4.3 DOM XSS in Single‑Page Applications

SPA'lerde client kodunda location.hash veya innerHTML kullanımı DOM XSS'e yol açar. Bazen tek bir third‑party script veya plugin DOM'u tehlikeli biçimde manipüle ederek zincirleme XSS'e sebep olur.

5. AVANTAJLAR VE SINIRLAMALAR (MİTİGASYON ÇÖZÜMLERİNİN DEĞERLENDİRİLMESİ)

5.1 Escaping/Encoding

Context‑aware escaping kesinlikle en temel ve etkili tekniktir: HTML encode, attribute encode, JS string encode, URL encode, CSS encode. Avantajı uygulanması nispeten kolay ve düşük maliyetli olmasıdır. Sınırlaması ise geliştiricinin doğru bağlamı bilmesi ve her çıktıda doğru encoding'i uygulaması gerekliliğidir.

5.2 Sanitization ve Whitelisting

Input'tan potansiyel tehlikeli token'ların temizlenmesi veya sadece izin verilen HTML tag/attribute'larının kabul edilmesi (whitelist) güvenli bir stratejidir; özellikle WYSIWYG editor içeriği için kullanışlıdır. Ancak yanlış yapılandırılmış whitelist saldırılara izin verebilir.

5.3 Content Security Policy (CSP)

CSP tarayıcı bazlı ek bir güvenlik katmanı sağlar: inline script'leri yasaklama, sadece belirli kaynaklardan script izin verme, nonce veya hash‑bazlı izinler gibi. CSP exploit riskini azaltır ama mükemmel bir panzehir değildir; düzgün bir CSP kurmak zor ve legacy uygulamalarda uyarlamak maliyetli olabilir.

5.4 Framework ve Library‑Level Solutions

Modern frontend framework'ler (React, Angular, Vue) many safe defaults sağlar (otomatik escaping, safe template binding). Backend templating engine'leri de otomatik escaping sunar. Avantajı developer ergonomisini artırmasıdır; sınırlaması ise geliştiricinin unsafe API'leri kullanmaktan kaçınması gerektiğidir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production için tavsiyeler

• Output bağlamını belirleyin ve her output için bağlama uygun escaping uygulayın (server ve client tarafında).
• CSP kullanın; inline script ve eval çeşitlerini kısıtlayın, nonce/hash tabanlı izinlere geçiş planlayın.
• Frameworklerinizin güvenli template ve binding yöntemlerini kullanın; raw HTML injection API'lerini mümkün olduğunca devre dışı bırakın.
• WYSIWYG içerikleri için sağlam bir whitelist sanitization katmanı (ör. DOMPurify) kullanın ve HTML5 element/attribute listesi tutun.

Performans ve operasyon

• DAST/SAST ve DOM XSS tespiti için özel araçları CI/CD pipeline'ına ekleyin; PR aşamasında reflection/DOM patterns tarayın.
• Runtime monitoring: CSP violation reporting, security headers monitoring ve anomalous script execution log'larını toplayın.
• Third‑party içerikleri izole edin: sandboxed iframes, subresource integrity (SRI) ve strict origin policies kullanın.

Güvenlik kültürü

• Developer eğitimleri: XSS context, escaping ve secure patterns konusunda düzenli eğitim verin.
• Threat modeling: UI/UX değişiklikleri ve third‑party eklentiler için threat modeling yapın.
• Incident playbook: XSS exploit tespitinde hızlı containment ve remediation adımlarını belgeleyin.

8. SIK YAPILAN HATALAR

• Tek bir generic sanitization fonksiyonunun tüm bağlamlarda yeterli olduğunu varsaymak.
• Client‑side framework'e aşırı güvenmek ve server‑side validation/escaping'i atlamak.
• CSP konfigurasyonunu yetersiz veya çok gevşek tutmak—'unsafe‑inline' veya geniş kaynak izinleri vermek.
• Third‑party script'leri doğrudan güvenilir kabul etmek; supply chain risklerini göz ardı etmek.

9. GELECEK TRENDLER

AI destekli DOM analiz ve otomatik remediations

AI, client‑side kodun DOM manipülasyonlarını analiz edip potansiyel DOM‑XSS pattern'lerini gerçek zamanlı işaretleyebilecek; otomatik remediation suggestion'ları geliştiricilere sunulacaktır.

Runtime protection ve micro‑CSP

CSP teknikleri daha granular hale gelecek; komponent‑bazlı (micro‑CSP) yaklaşımlar iframe veya komponent scope'unda strict izinler sağlayacak. Ayrıca RASP benzeri runtime policy enforcement ile inline riskler anlık müdahale edilebilecek.

Standardization for third‑party widgets

Third‑party içeriklerin izolasyonu, security labels ve manifestler aracılığıyla standardize edilmesi bekleniyor; böylece widget'ların yüklediği script'lerin izinleri daha iyi kontrol edilebilecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. XSS'i tamamen ortadan kaldırmak mümkün mü?

   Teorik olarak tüm outputlar bağlam‑doğru şekilde escape edilip, CSP ve güvenli defaults uygulandığında XSS riski büyük ölçüde minimize edilebilir; ancak third‑party içerikler ve insan hatası nedeniyle "sıfır risk" pratikte zordur.

2. 2. React gibi framework'ler XSS'i önler mi?

   React otomatik olarak JSX içinde değerleri escape eder; ancak dangerouslySetInnerHTML gibi raw HTML API'leri kullanılırsa XSS riski geri döner. Framework güvenliği doğru API kullanımıyla sağlanır.

3. 3. CSP benim tek korumam olabilir mi?

   CSP ek bir savunma hattıdır ama tek başına yeterli değildir. Proper escaping, input validation ve secure defaults ile birlikte kullanılmalıdır.

4. 4. DOM‑based XSS nasıl test edilir?

   DOM XSS için DAST araçları, DOM veri akış analizörleri ve manual code review (client JS) gereklidir. Ayrıca automated DOM fuzzing araçları da işe yarar.

5. 5. WAF XSS'i engeller mi?

   WAF bilinen pattern'leri engelleyebilir fakat DOM‑based veya obfuscated payload'ları atlatabilir. WAF bir katman olarak faydalıdır fakat tek başına güvence vermez.

6. 6. XSS exploit tespitinde hangi loglar önemlidir?

   CSP violation report'ları, suspicious JS errors, unexpected outbound requests (exfiltration), anomalous DOM modifications ve user action logs önemlidir.

7. 7. WYSIWYG editörleri güvenli mi?

   Varsayılan olarak değil; editor çıktılarını sanitize etmek, whitelist kullanmak ve editor entegrasyonlarında strict kontroller uygulamak gerekir.

8. 8. XSS eğitiminde hangi konulara odaklanılmalı?

   Context‑aware escaping, secure template kullanım, CSP, DOM manipulation anti‑patterns ve third‑party content isolation başlıca konulardır.

Anahtar Kavramlar

• XSS: Cross‑Site Scripting — tarayıcıda saldırgan kontrollü script çalıştırılması.
• CSP: Content Security Policy — tarayıcı taraflı politikalar ile script kaynaklarını sınırlar.
• Escaping/Encoding: Output'u bağlama göre güvenli hale getirme tekniği.
• DOM‑based XSS: Client‑side kod tarafından yaratılan XSS türü.
• DOMPurify: Popüler whitelist sanitization kütüphanesi (örnek).

Öğrenme Yol Haritası

1. 0–1 ay: XSS türlerini ve temel örnekleri öğrenin; OWASP XSS eğitim materyallerini çalışın.
2. 1–3 ay: DOM ve client‑side JavaScript akışlarını inceleyin; küçük uygulamalar üzerinde reflected/stored XSS testleri yapın (safe test ortamlarında).
3. 3–6 ay: CSP uygulama, whitelist sanitization, DOM fuzzing tool'ları ve CI/CD entegrasyonu ile güvenlik kontrolleri kurun.
4. 6–12 ay: Red/blue team tatbikatları, runtime detection ve AI‑destekli DOM analizleri ile proaktif tespit ve remediation süreçleri kurun.