Ekim 2025’ten bu yana NVD’ye eklenen 6.630 WordPress kaydının 2.100’den fazlası, yani yaklaşık %32’si tek bir türden: siteler arası betik, İngilizce kısaltmasıyla XSS (Cross-Site Scripting). Hiçbir tür bu kadar sık çıkmıyor; ikinci sıradaki eksik yetki kontrolü bunun yarısı kadar. Bu yazıda XSS’in ne olduğunu, WordPress’te neden bu kadar yaygın olduğunu ve bir site sahibi olarak hangi kayıtlara öncelik vermeniz gerektiğini anlatıyoruz.
Tanım
OWASP’ın tanımıyla XSS, kötü niyetli bir betiğin zararsız ve güvenilen bir web sitesine enjekte edildiği bir saldırı türüdür. MITRE’nin zayıflık listesinde karşılığı CWE-79: “web sayfası üretilirken girdinin uygun biçimde etkisizleştirilmemesi”. Basitçe söylemek gerekirse, bir eklenti kullanıcıdan aldığı bir metni sayfaya basarken içindeki kodu temizlemezse, o kod sayfayı açan herkesin tarayıcısında sitenin kendi kodu gibi çalışır.
Tarayıcı açısından bu kodu sitenin gerçek koduyla ayırt etmenin bir yolu yoktur. Kod, ziyaretçinin o sitedeki oturumuyla ne yapılabiliyorsa onu yapabilir.
İki ana tür, iki farklı tehlike
OWASP XSS’i iki ana sınıfa ayırır; üçüncüsü, DOM tabanlı XSS, daha az görülür.
Kalıcı (stored) XSS. Betik sunucuda, örneğin veritabanında saklanır ve o içeriği isteyen herkese gönderilir. Yorum alanı, form girişi, ürün açıklaması, kısa kod özelliği tipik yerlerdir. Bir kez yerleştirilen kod, silinene kadar her ziyarette çalışır.
Yansıtılan (reflected) XSS. Betik saklanmaz; adres satırındaki bir parametreyle gelir ve sayfada geri yansıtılır. İşlemesi için kurbanın hazırlanmış bir bağlantıyı açması gerekir. CVSS vektöründe bu “kullanıcı etkileşimi gerekli” (UI:R) olarak görünür.
WordPress kayıtlarında kalıcı tür açık ara önde. Çektiğimiz verideki açıklamalarda “Stored Cross-Site Scripting” ifadesi, “Reflected Cross-Site Scripting” ifadesinden yaklaşık yedi kat daha sık geçiyor.
WordPress’te neden bu kadar çok
Rakamın büyüklüğü, WordPress’in kötü yazıldığı anlamına gelmez; eklenti ekosisteminin yapısından kaynaklanır.
Birincisi, sayfa oluşturucu ve eklenti paketleri yüzlerce kısa kod ve blok sunar. Her birinin onlarca özelliği vardır (renk, bağlantı, başlık, simge) ve her özellik HTML’e yazılırken ayrı ayrı kaçırılmalıdır. Biri unutulduğunda yeni bir kayıt doğar. Çektiğimiz verideki kalıcı XSS kayıtlarının üçte birinden fazlasında açıklamada kısa kod geçiyor.
İkincisi, düzeltmesi de kolaydır. WordPress’in kendi belgesi bağlama göre hangi işlevin kullanılacağını açıkça yazar: HTML içinde gösterilecek metin için esc_html, bağlantılar için esc_url, HTML öznitelikleri için esc_attr, izin verilen HTML için wp_kses. Belge kaçırmanın olabildiğince geç, yani tam çıktı anında yapılmasını önerir. Kayıt metinleri de aynı noktaya işaret ediyor: çektiğimiz verideki XSS kayıtlarının yaklaşık %80’inin açıklamasında “yetersiz girdi temizleme ve çıktı kaçırma” ya da benzeri bir ifade geçiyor.
Kim kullanabilir
Türün riskini anlamak için XSS kayıtlarında gereken rol dağılımına bakmak yeterli:
| Gereken rol | XSS kaydı (yaklaşık) |
|---|---|
| Katkıcı | 810 |
| Hesap gerekmiyor | 710 |
| Yönetici | 260 |
| Abone | 220 |
| Yazar ve editör | 110 |
Katkıcı düzeyi kayıtlar çoğunlukla kısa kod ya da blok özellikleri üzerinden gelen kalıcı XSS’tir: katkıcı bir taslağa betik yerleştirir, editör ya da yönetici taslağı açınca çalışır. “Hesap gerekmiyor” grubunun önemli bir kısmı yansıtılan XSS’tir ve bir kullanıcının bağlantıya tıklamasını gerektirir; XSS kayıtlarının 585’inde UI:R işareti var. Hesapsız ve tıklama gerektirmeyen kalıcı XSS kayıtları ise en tehlikeli gruptur: örneğin herkese açık bir iletişim formunun girişleri yönetim panelinde temizlenmeden gösteriliyorsa, betik bir yönetici formu açtığı anda çalışır.
Yönetici düzeyindeki XSS kayıtları, rol yazımızda anlattığımız gibi, çoğu zaman yalnız çoklu sitelerde ya da betik ekleme yeteneğinin kapatıldığı kurulumlarda anlam taşır. Ayrıntı kullanıcı rolleri yazısında.
Hesapsız XSS kayıtlarını ikiye ayırın
“Hesap gerekmiyor” etiketli yaklaşık 710 XSS kaydı aslında iki farklı gruptan oluşuyor ve bunları ayırmak öncelik sırasını değiştiriyor. Bunların 360 kadarında CVSS vektörü kullanıcı etkileşimi istiyor: saldırgan bir bağlantı hazırlar ve sitenizdeki birinin, çoğu zaman bir yöneticinin, onu açmasını bekler. Kalan 340 kadarında etkileşim gerekmiyor. Bu ikinci grup, örneğin herkese açık bir formdan, bir yorum alanından ya da adres satırından gelen ve veritabanına yazılan girdilerin sonradan temizlenmeden gösterildiği durumları kapsar.
Sitemizdeki kayıt satırlarında bu ayrımı açıkça yazıyoruz: etkileşim gerekiyorsa satırdaki Türkçe metinde “bir kullanıcının hazırlanmış bir bağlantıya tıklaması ya da sayfayı açması gerekiyor” cümlesi bulunur. Hesapsız ve etkileşimsiz bir XSS kaydı gördüğünüzde onu orta puanına rağmen yüksek öncelikli sayın.
Temalar da bu türden payını alıyor. Son bir yılın 126 tema kaydının 45’i XSS; tema kayıtlarında en sık tür yine bu. Temaların kısa kodları ve özelleştirici (customizer) alanları, eklentilerdeki gibi kaçırılmadan sayfaya basıldığında aynı sonucu doğuruyor.
Puanlar neden çoğunlukla orta
XSS kayıtlarının yaklaşık dörtte üçü orta sınıfta, ortanca puan 6,4. Kritik puan alan XSS kaydı yok denecek kadar az. Bunun nedeni CVSS’in etki tarafında XSS’e genellikle “düşük gizlilik, düşük bütünlük” vermesi: betik doğrudan sunucuda değil, tarayıcıda çalışır.
Ama puan, betiğin kimin tarayıcısında çalışacağını bilmez. Bir yöneticinin tarayıcısında çalışan betik, onun oturumuyla yeni bir yönetici hesabı açabilir ya da tema dosyası düzenleyebilir. Bu yüzden XSS’i “orta puanlı, bekleyebilir” diye sınıflandırmadan önce iki soruyu sorun: Kod nerede gösteriliyor, yönetim panelinde mi, herkese açık sayfada mı? Kimin girdisiyle tetikleniyor?
Site sahibi ne yapabilir
Güncelleme. XSS’in tek gerçek çözümü düzeltilmiş sürümdür. İyi haber: düzeltme genellikle küçük olduğu için hızla gelir. Eklentiler listesindeki ürünlerin büyük çoğunluğunda güncel sürüm, bilinen XSS kayıtlarından etkilenmiyor görünüyor.
Rolleri sıkılaştırın. Katkıcı düzeyi XSS’in önüne geçmenin yolu katkıcıların kim olduğunu bilmektir. Dışarıdan yazar alıyorsanız onlara katkıcı rolü verin ama taslaklarını açmadan önce eklentilerinizin güncel olduğundan emin olun.
Kullanmadığınız sayfa oluşturucu eklentilerini silin. Bir eklenti paketinin yüzlerce kısa kodu, siz kullanmasanız bile katkıcıların taslaklarında çalışır. Devre dışı bırakılmış eklentinin kısa kodları çalışmaz; silinmiş eklentinin dosyaları da sunucuda kalmaz.
Yönetim oturumunu ayırın. Yansıtılan XSS bir bağlantıya tıklamanızı gerektirir. Yönetici olarak oturum açıkken e-postadan ya da mesajdan gelen bağlantılara tıklamamak, bu grubu büyük ölçüde etkisiz kılar.
İçerik Güvenliği Politikası (CSP). Sunucu tarafında ayarlanabilen bu başlık, tarayıcıya hangi kaynaklardan betik çalıştırabileceğini söyler. WordPress’te eklentilerin satır içi betik kullanması nedeniyle sıkı bir CSP kurmak zordur ve siteyi bozabilir; barındırma firmanızla ya da geliştiricinizle birlikte denemeniz gereken bir adımdır, ilk adım değil.
Kayıtları takip etmek
Son 12 ayda XSS kaydı çıkan ürünlerin listesi, ay ay dağılım ve en yeni kayıtlar XSS tür sayfasında. Son 30 günün kayıtlarını puan ve role göre süzmek için son açıklar sayfasını kullanabilirsiniz.