XSS Nedir, Zararlı Betik Sayfaya Nasıl Giriyor?

---

Sitenizde bir yorum kutusu var ve biri oraya düz metin yerine bir betik yazdı. Sayfayı açan başka bir ziyaretçinin tarayıcısı o betiği sizin sitenizin kodu sanıp çalıştırdı. Saldırı tam olarak bu noktada oldu ve sunucunuzda hiçbir dosya değişmedi.

Burada bu açığın nasıl tanımlandığını, betiğin sayfaya hangi yoldan girdiğini, tarayıcının onu neden güvenilir saydığını ve tarayıcı tarafında hangi savunmanın bulunduğunu OWASP ile MDN belgelerine bakarak ele alıyoruz.

Tanım nereden geliyor?​

OWASP'ın siteler arası betik çalıştırma sayfası, XSS saldırılarını bir enjeksiyon türü olarak tanımlıyor: zararlı betiklerin, başka türlü zararsız ve güvenilen sitelere enjekte edilmesi.

Sayfa saldırının işleyişini de anlatıyor. Saldırgan, bir web uygulamasını kullanarak genellikle tarayıcı tarafında çalışan bir betik biçimindeki zararlı kodu başka bir son kullanıcıya gönderiyor. Yani hedef sunucu değil, sayfayı açan diğer ziyaretçi.

Açık nerede oluşuyor?​

OWASP'ın cümlesi burada çok net: bu saldırıların başarılı olmasını sağlayan kusurlar oldukça yaygın ve bir web uygulamasının kullanıcıdan aldığı girdiyi doğrulamadan ya da kodlamadan ürettiği çıktının içinde kullandığı her yerde ortaya çıkıyor.

Bu tanım, açığın yerini de gösteriyor: sorun girdinin alınmasında değil, alınan girdinin çıktıya olduğu gibi konmasında.

• Girdi: Kullanıcıdan gelen metin, adres parametresi, form alanı.
• Kritik an: Bu verinin sayfaya yazılırken doğrulanmaması veya kodlanmaması.
• Sonuç: Tarayıcı, gelen içeriği sayfanın kendi kodu gibi çalıştırıyor.

Tarayıcı neden itiraz etmiyor?​

Sayfaya göre son kullanıcının tarayıcısının, betiğin güvenilmemesi gerektiğini anlamasının bir yolu yok; betiği çalıştırıyor. Tarayıcı kodun güvenilir bir kaynaktan geldiğini düşündüğü için de sonuç ağırlaşıyor.

OWASP bu noktada neyin risk altında olduğunu sayıyor: zararlı betik, tarayıcının o siteyle birlikte tuttuğu çerezlere, oturum belirteçlerine veya diğer hassas bilgilere erişebiliyor. Sayfa, bu betiklerin HTML sayfasının içeriğini yeniden yazabildiğini de belirtiyor.

Püf nokta' Alıntı:

Oturum belirteci tarayıcıdaysa, sayfada çalışan her betik onu görebilir.

Genişletmek için tıkla ...

Enjeksiyon ailesinin diğer üyesi​

XSS bir enjeksiyon türü olduğu için mantığı tanıdık gelecektir: veri, veri olarak kalması gerekirken komut olarak yorumlanıyor. Aynı mantığın veritabanı tarafındaki karşılığını ve kendi sitenizde nasıl sınanacağını SQL enjeksiyonu yazımızda ele almıştık.

Fark, kodun nerede çalıştığı. Birinde sorgu sunucuda, diğerinde betik ziyaretçinin tarayıcısında çalışıyor.

Tarayıcı tarafında hangi savunma var?​

MDN'in içerik güvenlik politikası rehberi, CSP'yi belirli güvenlik tehditlerinin riskini önlemeye veya azaltmaya yardımcı olan bir özellik olarak tanımlıyor. Rehbere göre politika, siteden tarayıcıya gönderilen ve siteyi oluşturan kodun neler yapabileceğine sınır koyan bir dizi yönergeden oluşuyor.

Aynı rehber birincil kullanım amacını da yazıyor: bir belgenin hangi kaynakları, özellikle hangi JavaScript kaynaklarını yükleyebileceğini denetlemek. Bu, saldırganın kurbanın sitesine zararlı kod enjekte edebildiği XSS saldırılarına karşı bir savunma olarak kullanılıyor.

Rehber, politikanın başka amaçlara da hizmet ettiğini ekliyor: tıklama hırsızlığına karşı gömülmeyi kısıtlamak, sayfaların HTTPS üzerinden yüklenmesini sağlamaya yardımcı olmak ve istemci tarafı XSS'e karşı güvenilir tür kullanımını zorunlu kılmak.

Açığı bulduğunuzda ne yapmalı?​

Bir açığı fark ettiğinizde ilk soru, kime ve nasıl bildirileceği oluyor; bunun yolunu açık bildirimi yazımızda anlatmıştık. Yayımlanmış bir kaydın ciddiyetini okumak için de CVSS puanı yazımız işinizi görür.

Savunma tek katmanda kurulmuyor​

MDN'in rehberi politikanın önce tarayıcıya nasıl ulaştığını ve genel hatlarıyla neye benzediğini anlatarak başlıyor; ardından hangi işler için kullanılabileceğini sıralıyor. Bu sıralamanın kendisi de bir şey söylüyor: politika tek bir düğme değil, ayrı ayrı açılan kısıtlardan oluşuyor.

Pratikte bu, sunucu tarafındaki kodlamanın yerine geçen bir çözüm olmadığı anlamına geliyor. Girdi çıktıya doğru biçimde yazılmıyorsa, politika yalnız zararın büyüklüğünü sınırlıyor.

Bu yüzden iki katmanı birlikte düşünmek gerekiyor: uygulamanın kullanıcı verisini nasıl işlediği ve tarayıcıya hangi sınırların bildirildiği. Birincisi açığın oluşmasını, ikincisi oluştuğunda ne kadar ilerleyebileceğini belirliyor.

Sık Sorulan Sorular​

XSS nedir?
OWASP'ın tanımıyla, zararlı betiklerin başka türlü zararsız ve güvenilen sitelere enjekte edildiği bir enjeksiyon saldırısı türü.

Saldırının hedefi kim?
Sayfaya göre saldırgan, web uygulamasını kullanarak zararlı kodu başka bir son kullanıcıya gönderiyor.

Açık tam olarak nerede oluşuyor?
Uygulamanın, kullanıcıdan aldığı girdiyi doğrulamadan veya kodlamadan ürettiği çıktının içinde kullandığı her yerde.

Betik neleri görebiliyor?
OWASP, tarayıcının o siteyle tuttuğu çerezlere, oturum belirteçlerine ve diğer hassas bilgilere erişilebildiğini söylüyor.

CSP bunu engelliyor mu?
MDN, CSP'nin belgenin yükleyebileceği JavaScript kaynaklarını denetlediğini ve bunun XSS'e karşı bir savunma olarak kullanıldığını belirtiyor.

Özetle​

XSS, kullanıcı girdisinin doğrulanmadan veya kodlanmadan çıktıya konması sonucu ortaya çıkan bir enjeksiyon açığı. Zararlı betik ziyaretçinin tarayıcısında, sitenin kendi kodu sanılarak çalışıyor ve çerezlere, oturum belirteçlerine erişebiliyor. Sunucu tarafında girdinin nasıl işlendiği kadar, tarayıcıya hangi kaynakları yükleyebileceğini söyleyen politika da savunmanın parçası.

Sitenizde kullanıcıdan gelen metnin ekrana basıldığı kaç ayrı yer olduğunu sayabilir misiniz?

Güncelleme: 1 Eylül 2026. OWASP'ın siteler arası betik çalıştırma sayfası ve MDN'in içerik güvenlik politikası rehberi kontrol edildi.

---