XSS (Cross-Site Scripting) Nedir?

XSS (Cross-Site Scripting) Nedir? sorusu, modern web uygulaması güvenliği süreçlerinde kritik bir yer tutmaktadır. XSS (Cross-Site Scripting), saldırganların güvenilir web platformlarına kötü amaçlı istemci taraflı kod enjekte etmesine olanak tanıyan, OWASP Top 10 listesinde kalıcı bir tehdit olarak yer alan kritik bir siber güvenlik zafiyeti türüdür [1]. Bu güvenlik açığı, kullanıcı tarayıcılarında kontrolsüz kod çalıştırılmasına yol açarak veri ihlali ve oturum çalma gibi ciddi riskler yaratır [1]. İşletme sahipleri ve teknik karar vericiler için bu açığı kavramak, dijital varlıkları korumanın, KVKK ve GDPR uyumluluğunu sağlamanın temel adımlarından biridir. Bu rehberde, zafiyetin mimari temellerini, türlerini ve kurumsal korunma stratejilerini analiz edeceğiz.

Cross-Site Scripting (XSS) Zafiyeti Nedir?

Siber güvenlik zafiyeti olarak adlandırılan Cross-Site Scripting (XSS), kötü niyetli aktörlerin meşru ve güvenilir web sitelerine zararlı betikler (scripts) yerleştirmesiyle ortaya çıkan bir kod enjeksiyonu açığıdır [1]. SQL Enjeksiyonu (SQL Injection) gibi doğrudan veri tabanını hedef alan açıkların aksine XSS, doğrudan uygulamanın son kullanıcılarını (istemci tarafını - client-side) hedef alır. Tarayıcı, sunucudan gelen kodun güvenilir bir kaynaktan üretildiğini varsaydığı için, bu kötü amaçlı komut dosyasını tamamen yetkilendirilmiş bir uygulama kodu gibi çalıştırır [1].

Yazılım geliştirme süreçlerinde kullanıcıdan alınan girdilerin (input) yeterli denetime tabii tutulmaması, bu zafiyetin ana kaynağını oluşturur. Web tarayıcısı, kendisine sunulan HTML belgesinin içerisindeki yapısal kodlar ile kullanıcıdan gelen dinamik verileri birbirinden ayıramaz. Saldırgan, girdi alanlarına düz metin yerine yapısal bir JavaScript kodu girdiğinde ve uygulama bu girdiyi doğrudan sayfaya yansıttığında, tarayıcı bu girdiyi yürütülebilir bir kod olarak algılar. Bu durum, siber saldırı vektörlerinin en tehlikeli olanlarından birinin tetiklenmesine yol açar.

Kurumsal organizasyonlar için bu açığın varlığı, sadece teknik bir aksaklık değil; aynı zamanda ciddi bir regülasyon ve finansal risk unsurudur. KVKK, GDPR ve PCI-DSS gibi uluslararası standartlar, müşteri verilerinin uçtan uca güvenli bir şekilde saklanmasını ve aktarılmasını zorunlu kılar. Başarılı bir XSS saldırısı, veri gizliliğini ihlal ederek şirketlerin yüksek hukuki yaptırımlarla ve ciddi marka itibarı kayıplarıyla karşılaşmasına neden olur. Güvenlik mimarisinin oluşturulmasında proaktif denetim süreçlerinin işletilmesi bu yüzden bir zorunluluktur.

XSS Saldırıları Mimari Olarak Nasıl Çalışır?

XSS saldırılarının çalışma prensibi, web mimarisinin temel yapı taşlarından biri olan Aynı Köken Politikası (Same-Origin Policy - SOP) sınırlarını aşmak üzerine kuruludur. SOP, bir web sitesinden yüklenen betiklerin, farklı bir kökene (origin) sahip kaynaklardaki verilere erişmesini kısıtlar. Ancak XSS saldırısında kötü amaçlı kodlar zaten doğrudan "güvenilir köken" üzerinden tarayıcıya ulaştığı için, tarayıcı SOP kurallarını ihlal etmeden bu zararlı komut dosyasına tüm hakları ve erişimleri tanır.

Bu sürecin işleyiş mekanizması üç temel aktör arasında gerçekleşir: Saldırgan, hedef web uygulaması (sunucu) ve kurban (son kullanıcının web tarayıcısı) [1]. İlk aşamada, saldırgan web uygulamasındaki bir girdi alanına (örneğin arama çubuğu, yorum formu veya profil düzenleme ekranı) özel olarak hazırlanmış bir JavaScript kodu yerleştirir. Bu kod genellikle @@CODE0@@ etiketleri arasına yerleştirilmiş veya HTML olay işleyicileri (event handlers - ör. @@CODE1@@, onerror) içine gizlenmiş payload'lardan oluşur.

İkinci aşamada, web uygulaması bu girdiyi filtrelemeden veri tabanına kaydeder veya doğrudan kullanıcıya dönecek olan HTTP yanıtına (HTTP response) ekler. Son aşamada ise, meşru bir kullanıcı bu sayfayı ziyaret ettiğinde veya özel hazırlanmış bağlantıya tıkladığında, tarayıcı sunucudan gelen HTML kodunu satır satır yorumlamaya başlar. Sıra enjekte edilmiş zararlı koda geldiğinde, tarayıcı bunu uygulamanın orijinal işlevi olarak kabul edip çalıştırır. Sonuç olarak, saldırganın komut dosyası kullanıcının tarayıcısında tam yetkiyle yürütülür ve oturum çerezlerini (cookies), oturum jetonlarını (tokens) veya hassas form verilerini siber saldırganın kontrolündeki uzak bir sunucuya sızdırabilir [1].

Kritik XSS (Cross-Site Scripting) Türleri Nelerdir?

XSS saldırıları, zararlı kodun sisteme nasıl dahil edildiğine, nerede depolandığına ve tarayıcı tarafından nasıl yorumlandığına bağlı olarak üç ana sınıfa ayrılır [1]. Bu kategorizasyon, doğru savunma hattının kurulması ve sızma testi (penetration testing) süreçlerinin doğru kurgulanması için teknik karar vericiler tarafından derinlemesine bilinmelidir. Her tür, farklı bir giriş noktası ve farklı bir tarayıcı içi yürütme mantığı kullanır.

Kalıcı ve Tehlikeli: Stored XSS (Depolanmış XSS)

Kalıcı XSS (Persistent XSS) olarak da bilinen Stored XSS, bu zafiyet ailesinin en tahrip edici türüdür [1]. Bu saldırıda, saldırgan tarafından gönderilen kötü amaçlı komut dosyası hedef web sunucusunun veri tabanında, mesaj geçmişinde, forum gönderilerinde veya kullanıcı profili gibi alanlarda kalıcı olarak depolanır [1]. Bir e-ticaret sitesindeki ürün yorumları veya bir kurumsal portalın geri bildirim ekranı bu saldırı için tipik birer hedef alanıdır.

Bir ziyaretçi bu kirli veriyi içeren sayfayı her talep ettiğinde, sunucu veri tabanından aldığı zararlı kodu HTML belgesine ekleyerek tarayıcıya gönderir. Saldırının kalıcı olması, kurbanın herhangi bir özel linke tıklamasına gerek kalmadan, sadece standart bir web sayfasını ziyaret etmesiyle sistemin enfekte olmasına yol açar. Bu durum, tek bir payload ile binlerce kullanıcının oturum bilgilerinin (session hijacking) aynı anda tehlikeye girmesine yol açabilir.

Sosyal Mühendislik Odaklı: Reflected XSS (Yansıyan XSS)

Reflected XSS (Non-Persistent XSS), kötü amaçlı kodun sunucuda depolanmadığı, doğrudan bir HTTP isteği ile gelip anlık olarak sunucudan geri yansıdığı saldırı türüdür [1]. Genellikle arama motorlarındaki arama çubukları, form hata mesajları veya kullanıcıya özel dinamik karşılama mesajlarında görülür. Saldırgan, parametre içeren güvensiz bir URL hazırlar (örneğin: https://example.com/search?q=<script>... </script>).

Bu URL sosyal mühendislik yöntemleriyle, e-posta oltalamalarıyla (phishing) veya kısaltılmış linklerle kurbanlara gönderilir. Kullanıcı bu bağlantıya tıkladığında, tarayıcı sunucuya parametre içeren bir istek gönderir. Sunucu, girdi denetimi yapmadan bu parametreyi sayfa içerisine yerleştirip yanıt olarak tarayıcıya geri yansıtır [1]. Kod o anlık çalışır ve işlem sonlanır; sunucu tarafında kalıcı bir iz bırakmadığı için tespiti ve analizi özel log inceleme yöntemleri gerektirir.

İstemci Taraflı Tehdit: DOM Tabanlı XSS (DOM-Based XSS)

DOM Tabanlı XSS, web uygulamasının sunucu tarafındaki kodlarından tamamen bağımsız olarak, tarayıcıda çalışan istemci taraflı (client-side) JavaScript kodlarındaki hatalardan kaynaklanır. Bu senaryoda zararlı payload, sunucuya gönderilen HTTP isteğine dahi dahil olmadan, tarayıcı içindeki Belge Nesnesi Modeli (Document Object Model - DOM) ağacının güvensiz bir şekilde manipüle edilmesiyle yürütülür.

Saldırgan, tarayıcıdaki bir JavaScript kodunun güvensiz bir "kaynaktan" (source - ör. @@CODE0@@, @@CODE1@@ veya @@CODE2@@) veri okuyup, bu veriyi doğrudan yürütülebilir bir "hedefe" (sink - ör. @@CODE3@@, @@CODE4@@ veya @@CODE5@@) yazmasını sağlar. Sunucu tarafında hiçbir filtreleme veya web uygulama güvenlik duvarı (WAF), DOM tabanlı XSS'i tek başına engelleyemez; çünkü payload sunucuya hiç ulaşmadan doğrudan kullanıcının kendi tarayıcısı içinde işlenir ve tetiklenir.

XSS Zafiyetinin Kurumlara ve Kullanıcılara Yönelik Yıkıcı Etkileri

Güvenlik açıklarının maliyeti çoğu zaman sadece yazılımsal yama maliyetleriyle sınırlı kalmaz. XSS, saldırgona kurbanın tarayıcı ortamında tam yetki tanıdığı için, yaratabileceği finansal, operasyonel ve prestij kayıpları ölçek fark etmeksizin tüm işletmeler için yıkıcı olabilir. İş karar vericilerinin bu etkileri risk matrislerinde doğru puanlaması kritik önem taşır.

Oturum Çalma (Session Hijacking) ve Yetki Devri

Bir XSS saldırısının en yaygın hedeflerinden biri oturum çalma (session hijacking) eylemidir. Web uygulamaları, kullanıcıların sisteme giriş yaptıktan sonra her sayfada şifre girmesini önlemek amacıyla oturum kimliklerini (session ID) tarayıcı çerezlerinde (cookies) depolar. Eğer bu çerezler doğru güvenlik parametreleriyle korunmuyorsa, enjekte edilen bir JavaScript kodu document.cookie komutuyla bu veriyi anında saldırganın kontrolündeki sunucuya aktarır.

Saldırgan, ele geçirdiği bu oturum kimliğini kendi tarayıcısına ithal ederek, kurbanın kullanıcı adı ve şifresine ihtiyaç duymaksızın sisteme kurbanın kimliğiyle giriş yapar. Eğer bu kullanıcı bir şirket yöneticisi veya sistem yöneticisi (admin) ise, saldırgan kurumsal ağ üzerinde tam yetki kazanır. Bu durum, veri silme, finansal transferler gerçekleştirme veya sisteme arka kapılar (backdoors) yerleştirme gibi kontrolü imkansız zincirleme felaketlere yol açar.

Kurumsal Veri İhlalleri ve İtibar Kaybı

XSS, doğrudan müşteri verilerinin sızdırılması amacıyla bir sıçrama tahtası olarak kullanılabilir. Tarayıcı üzerinde çalışan zararlı kodlar, sayfadaki form alanlarını manipüle ederek sahte giriş ekranları (phishing) oluşturabilir veya kullanıcının kredi kartı, kimlik numarası gibi kritik bilgilerini gerçek zamanlı olarak kaydedip dışarı sızdırabilir. Bu durum, şirketlerin doğrudan veri ihlali (data breach) yaşamasına sebebiyet verir.

Veri ihlallerinin tespiti sonrasında, KVKK ve GDPR uyumluluk kuralları çerçevesinde kurumlara milyonlarca liralık idari para cezaları kesilmektedir. Buna ek olarak, müşterilerin güvenini yitiren bir markanın pazar payı kaybı, hisse değeri düşüşleri ve prestij kaybı, teknik onarım bütçelerinin katbekat üzerine çıkmaktadır. Bilgi güvenliği yatırımları, bu gibi telafisi zor finansal kayıpları engellemek adına en rasyonel sigorta poliçesidir.

Web Uygulamalarını XSS Saldırılarından Korumak İçin Kritik Stratejiler

XSS zafiyetinden korunmak, tek aşamalı bir çözümle mümkün değildir. "Güvenli yazılım geliştirme yaşam döngüsü" (SSDLC) prensipleri doğrultusunda, uygulamanın mimari seviyesinde katmanlı bir savunma hattı inşa edilmesi gerekir. Sektör standardı haline gelmiş modern koruma yaklaşımları, kod tabanınızı ve altyapınızı bu saldırılardan korumanın yegane yoludur.

Girdi Doğrulama ve Temizleme (Input Validation & Sanitization)

Korunmanın ilk adımı, dış dünyadan gelen hiçbir veriye asla güvenmemek (Zero Trust veri yaklaşımı) prensibine dayanır. Kullanıcıdan alınan tüm girdiler, sunucu tarafında sıkı bir girdi doğrulama (input validation) sürecinden geçmelidir. Bu doğrulamada, yalnızca izin verilen karakterlerin sisteme girişine olanak tanıyan beyaz liste (allow-list) yaklaşımı benimsenmelidir. Örneğin, bir telefon numarası alanına sadece rakam ve "+" karakterinin girilebilmesi sağlanmalıdır.

Eğer kullanıcının zengin metin (Rich Text / HTML) girmesi zorunlu ise (blog yorumları veya ürün açıklamaları gibi durumlar), girdi temizleme (sanitization) işlemi uygulanmalıdır. Bu işlemde, girdi içerisindeki riskli HTML etiketleri (@@CODE0@@, @@CODE1@@, @@CODE2@@) ve olay işleyicileri (@@CODE3@@, onclick) güvenli kütüphaneler aracılığıyla ayıklanır. Geliştiricilerin bu temizlik işlemlerini kendi yazacakları düzenli ifadelerle (regex) yapmaya çalışması yaygın bir hatadır; bunun yerine endüstri standardı olan DOMPurify (istemci tarafı için) veya sunucu tarafındaki muadil kütüphaneler tercih edilmelidir.

Çıktı Kodlama (Output Encoding) Zorunluluğu

Girdi kontrolü ne kadar sıkı olursa olsun, veriler sisteme girerken değil, tarayıcıya geri gönderilirken (çıktı aşamasında) kodlanmalıdır. Çıktı kodlama (output encoding), kullanıcıdan alınan dinamik verilerin tarayıcı tarafından yürütülebilir kod olarak değil, salt metin (string literal) olarak yorumlanmasını sağlar. Bu sayede, girdi içindeki @@CODE0@@ gibi karakterler, tarayıcıya gönderilmeden önce @@CODE1@@ gibi zararsız HTML varlıklarına (HTML entities) dönüştürülür.

Çıktının nerede kullanılacağı (context), kodlama yöntemini belirlemede en kritik faktördür:

• HTML Gövdesi (HTML Body Context): Veri doğrudan sayfa içine yazılacaksa HTML entity encoding uygulanır.

• HTML Özniteliği (HTML Attribute Context): Veri bir input değerinin içine veya görselin alt etiketine yazılacaksa öznitelik kodlaması uygulanır.

• JavaScript Bağlamı (JavaScript Context): Dinamik veriler bir JavaScript değişkeninin içine atanacaksa, JS unicode kodlaması zorunludur.

Modern yazılım geliştirme framework'leri (React, Angular, Vue.js, ASP.NET MVC gibi) varsayılan olarak yerleşik çıktı kodlama mekanizmaları barındırır. Ancak, doğrudan ham HTML render etmeye izin veren esnek kod bloklarının (örneğin React'taki dangerouslySetInnerHTML özniteliği) kullanımı sırasında bu otomatik koruma devre dışı kalır. Geliştiricilerin bu esnek yapıları kullanırken ekstra dikkat göstermesi şarttır.

İçerik Güvenliği Politikası (CSP) Kullanımı

İçerik Güvenliği Politikası (Content Security Policy - CSP), XSS saldırılarının etkisini azaltmak ve sömürülmesini engellemek için geliştirilmiş son derece güçlü bir HTTP yanıt başlığıdır (response header) [1]. CSP, tarayıcıya web sitesinin hangi kaynaklardan betik, stil dosyası, görsel veya yazı tipi yükleyebileceğini bildiren kurallar bütünü sunar.

Örneğin, aşağıdaki gibi yapılandırılmış bir CSP başlığı:
Content-Security-Policy: default-src 'self'; script-src 'self' https://trustedscripts.com;

Tarayıcıya yalnızca sitenin kendi alan adından (@@CODE0@@) ve @@CODE1@@ adresinden gelen JavaScript dosyalarını çalıştırma izni verir. Bunun dışındaki herhangi bir sunucudan veya inline (satır içi) kod bloklarından gelen (enjekte edilmiş) betikler tarayıcı tarafından doğrudan engellenir ve çalıştırılmaz. CSP ayrıca, inline betiklerin (<script>alert(1)</script>) çalıştırılmasını varsayılan olarak yasaklayarak XSS saldırılarının büyük bir kısmını etkisiz hale getirir.

Güvenli Çerez (Cookie) Yapılandırması: HttpOnly ve Secure Flag

Oturum yönetiminde kullanılan çerezlerin güvenliği, XSS saldırısının en yıkıcı sonucu olan "oturum çalma" eylemini engellemek için kritik bir savunma hattıdır. Web uygulaması tarafından tarayıcıya gönderilen oturum çerezleri tanımlanırken mutlaka @@CODE0@@ bayrağı aktif edilmelidir. @@CODE1@@ olarak işaretlenen bir çereze, tarayıcıda çalışan hiçbir JavaScript kodu (document.cookie komutu dahil) erişemez.

Bu sayede, web sitenizde bir XSS açığı bulunsa ve saldırgan sisteme zararlı betik enjekte etmeyi başarsa bile, kurbanın oturum çerezlerini okuyamaz ve oturumunu çalamaz. Buna ek olarak, @@CODE0@@ bayrağı çerezlerin yalnızca HTTPS şifreli bağlantılar üzerinden iletilmesini garanti ederken, @@CODE1@@ özniteliği (Strict veya Lax değerleri ile) siteler arası istek sahteciliği (CSRF) risklerini minimize eder.

Kurumsal Sistemlerde XSS Zafiyetlerini Tespit Etme

Web uygulamalarındaki XSS açıklarının, kötü niyetli aktörlerden önce tespit edilip kapatılması, kurumsal siber savunmanın temel amacıdır. Bunun için yazılım geliştirme süreçlerine entegre edilmiş proaktif güvenlik testleri ve zafiyet taraması mekanizmaları kurulmalıdır. Sadece tek bir yönteme güvenmek yerine, hibrit bir test metodolojisi benimsenmelidir.

Zafiyet tespit süreçleri üç ana başlık altında toplanır:

• Statik Kod Analizi (SAST): Yazılım henüz geliştirme aşamasındayken (source code), kaynak kodları tarayarak potansiyel XSS açıklarını ve güvensiz kod bloklarını tespit eden otomatik analiz araçlarıdır. Kodun derlenmesine gerek kalmadan geliştiricilere anlık geri bildirim sağlar.

• Dinamik Uygulama Güvenlik Testleri (DAST): Çalışır durumdaki web uygulamasına dışarıdan otomatik saldırı payload'ları göndererek uygulamanın davranışını analiz eden sistemlerdir. Zafiyet taraması araçları (örneğin OWASP ZAP, Burp Suite Enterprise, Acunetix) bu grupta yer alır ve gerçek dünya saldırı senaryolarını simüle eder.

• Sızma Testi (Penetration Testing): Profesyonel siber güvenlik uzmanları tarafından gerçekleştirilen manuel analizlerdir. Otomatik araçların kaçırabileceği, karmaşık mantıksal hatalara dayalı veya DOM tabanlı XSS açıklarını bulmak için en etkili yöntemdir. Yılda en az bir kez düzenli sızma testi yaptırmak regülasyon uyumluluğu için de elzemdir.

Kurumların bu tarama teknolojilerini CI/CD (Sürekli Entegrasyon / Sürekli Dağıtım) süreçlerine dahil etmesi (DevSecOps yaklaşımı), zafiyetlerin canlı ortama çıkmadan çok önce, kod yazım aşamasında engellenmesini sağlar. Güvenliği yazılım yaşam döngüsünün en başına kaydırmak (Shift-Left Security), hem operasyonel maliyetleri düşürür hem de insan kaynaklı hataların önüne geçer.