Kalıcı Cross-Site Scripting (Stored XSS)

SSL Sertifika Analizi Açık Port Tespiti Web Uygulama Tarama DNS Güvenlik Denetimi HTTP Başlık Analizi Yanlış Yapılandırma Tespiti Yazılım Parmak İzi Alt Alan Adı Tarama
SSL Sertifika Analizi Açık Port Tespiti Web Uygulama Tarama DNS Güvenlik Denetimi HTTP Başlık Analizi Yanlış Yapılandırma Tespiti Yazılım Parmak İzi Alt Alan Adı Tarama

Tüm Kayıtlar

Sitenizi Tarayın

Sitenizi bu zafiyete karşı kontrol edin

Otomatik bir tarama başlatın ve sitenizin etkilenip etkilenmediğini görün — sade dille bulgular ve çözümlerle.

Taramaya Başla
Kategori Enjeksiyon / Cross-Site Scripting
Tipik Önem Derecesi Yüksek
OWASP A03:2021 – Enjeksiyon
CWE CWE-79 – Web Sayfası Oluşturma Sırasında Girdinin Uygunsuz Nötrleştirilmesi
Diğer Adlar Kalıcı XSS, Persistent XSS, Second-Order XSS, Tip-2 XSS
Etkilenen Sistemler Kullanıcı tarafından sağlanan içeriği depolayan ve görüntüleyen web uygulamaları (forumlar, yorum sistemleri, CMS platformları, profil sayfaları, sohbet uygulamaları, yönetici panelleri)
Standartlar ve Referanslar OWASP Top 10 A03:2021, CWE-79, W3C Content Security Policy Düzey 3

Genel Bakış

Kalıcı Cross-Site Scripting (Stored XSS), bir web uygulamasının kullanıcı denetimindeki girdiyi yeterli temizleme yapmadan bir arka uç veri deposuna (veritabanı, günlük dosyası, mesaj kuyruğu vb.) kaydetmesi ve ardından bu veriyi uygun çıktı kodlaması olmaksızın HTTP yanıtında işlemesi durumunda ortaya çıkar. Kötü niyetli yükün bir URL'ye gömüldüğü ve tek bir gidip-gelmede çalıştırıldığı Yansıtılan XSS'den farklı olarak, Stored XSS yükleri kalıcıdır: etkilenen sayfayı görüntüleyen her kullanıcının tarayıcısı, çoğunlukla yalnızca sayfayı ziyaret ederek, enjekte edilen betiği çalıştırır.

Stored XSS, CWE-79 (Web Sayfası Oluşturma Sırasında Girdinin Uygunsuz Nötrleştirilmesi) kapsamında sınıflandırılır ve OWASP Top 10 A03:2021 – Enjeksiyon ile eşleşir. Saldırı kendi kendine yayılan bir yapıya sahip olduğundan ve kurbanın özel hazırlanmış bir bağlantıya tıklamasını gerektirmediğinden, genellikle Yansıtılan XSS'den daha tehlikeli kabul edilir.

Nasıl Çalışır?

Saldırı yaşam döngüsü üç ayrı aşamadan oluşur:

  1. Enjeksiyon: Saldırgan, uygulamanın kabul ettiği herhangi bir girdi yüzeyi (yorum alanları, kullanıcı profilleri, ürün incelemeleri, dosya adları, günlüklerde saklanan HTTP başlıkları vb.) aracılığıyla genellikle bir <script> etiketi, olay işleyici niteliği veya kodlanmış bir varyant olan bir yük gönderir.
  2. Kalıcılık: Uygulama, temizlenmemiş yükü bir veri deposuna kaydeder. Bu noktadan itibaren yük, gelecekteki her ziyaretçi için çalışmaya hazır bekler.
  3. Çalıştırma: Meşru bir kullanıcı (veya yönetici) depolanan veriyi içeren sayfayı talep ettiğinde, sunucu yükü HTML yanıtına ekler. Tarayıcı, enjekte edilen betiği meşru uygulama kodundan ayırt edemediğinden, köken (origin) bağlamında çalıştırır.

Temel teknik özellikler:

  • Çalıştırma, kurbanın tarayıcısında uygulamanın kökeni altında gerçekleşir; bu da betiğe çerezlere (oturum belirteçleri dahil), localStorage'a, sessionStorage'a ve DOM'a erişim sağlar.
  • Yükler oturum çerezlerini saldırgan kontrolündeki bir sunucuya sızdırabilir, kurban adına eylemler gerçekleştirebilir (CSRF eşdeğeri), kullanıcıları kimlik avı sayfalarına yönlendirebilir veya zararlı yazılım indirilmesini tetikleyebilir.
  • Naif girdi filtrelerini atlatmak için çok dilli (polyglot) yükler ve kodlama hileleri (HTML varlıkları, Unicode kaçışları, base64, SVG vektörleri, CSS ifadeleri) yaygın olarak kullanılır.
  • İkinci aşamalı XSS, depolanan verilerin daha sonra farklı bir sayfa veya bağlamda—genellikle bir bakım ya da yönetim arayüzünde—güvensiz biçimde dahil edildiği bir varyanttır ve standart testlerde keşfedilmesi daha güçtür.
  • HttpOnly çerez bayrağı, JavaScript'in çerezleri doğrudan okumasını engeller; ancak XSS yoluyla gerçekleştirilebilen tüm oturum ele geçirme sınıflarını (örneğin, kimliği doğrulanmış isteklerin sahte olarak oluşturulması) engellemez.

İş Etkisi

Stored XSS, etkilenen her ziyaretçi için otomatik olarak çalıştığından, patlama yarıçapı güvenliği ihlal edilmiş sayfanın trafiğiyle orantılı olarak büyür. Belgelenmiş sonuçlar şunlardır:

  • Hesap ele geçirme: document.cookie sızdırma yoluyla elde edilen oturum belirteçleri, saldırganların kurbanların şifrelerini bilmeden onları taklit etmesine olanak tanır.
  • Kimlik bilgisi toplama: Enjekte edilen betikler, oturum açma formlarının üzerine yazabilir veya düz metin kimlik bilgilerini toplamak için sahte kimlik doğrulama iletişim kutuları ekleyebilir.
  • Ayrıcalık yükseltme: Bir yönetici etkilenmiş bir sayfayı görüntülediğinde, saldırgan tüm uygulamayı tehlikeye atacak şekilde yönetici düzeyinde erişim elde edebilir.
  • Kötü amaçlı yazılım dağıtımı: Betikler, kullanıcıları sessizce exploit kitlerına yönlendirebilir veya zararlı yazılım indirilmesini tetikleyebilir.
  • Düzenleyici maruziyet: Kişisel verilere yetkisiz erişim, GDPR, KVKK, HIPAA, PCI DSS ve benzer çerçeveler kapsamında ihlal bildirimleri ve para cezaları doğurabilir.
  • İtibar hasarı: Kamuoyuna mal olmuş XSS olayları, özellikle e-ticaret, bankacılık ve sağlık hizmetleri platformlarında kullanıcı güvenini zedeler.
  • Veri bütünlüğünün bozulması: Betikler ekrandaki içeriği değiştirebilir ve kullanıcıların sahte bilgilere (örneğin, manipüle edilmiş finansal rakamlar) dayalı kararlar almasına yol açabilir.

Nasıl Giderilir?

Savunma, birden fazla katmanda kontrol gerektirir. Tek bir önlem tek başına yeterli değildir.

  1. Bağlama duyarlı çıktı kodlaması: Kullanıcı tarafından sağlanan tüm veriler, depolama noktasında değil, işleme noktasında kodlanmalıdır. Çıktı bağlamına uygun kodlama kullanın: HTML gövdesi/nitelikleri için HTML varlık kodlaması, satır içi betikler için JavaScript dize kaçışı, href/src nitelikleri için URL kodlaması, stil bağlamları için CSS kaçışı. OWASP Java Encoder, Microsoft AntiXSS veya framework'e özgü şablonlama motorları (React'ın JSX'i, Angular'ın interpolasyonu, Django'nun otomatik kaçışı) gibi kütüphaneler doğru kullanıldığında bunu otomatik olarak uygular.
  2. Girdi doğrulama ve temizleme: Beklenen biçimlere uymayan girdiyi reddedin veya temizleyin. Zengin metin (HTML) kabul etmesi gereken alanlar için iyi bakımı yapılan bir izin listesi tabanlı HTML temizleme kütüphanesi kullanın (örneğin, istemci tarafı için DOMPurify, Python için bleach, .NET için HtmlSanitizer). Engel listesi yaklaşımları, kodlama atlatma tekniklerine karşı yetersizdir.
  3. İçerik Güvenlik Politikası (CSP): Satır içi betikleri ('unsafe-inline') yasaklayan ve betik kaynaklarını güvenilir kaynaklarla sınırlayan katı bir CSP başlığı (Content-Security-Policy) dağıtın. Meşru satır içi betikler için nonce veya hash kullanan bir politika en güçlü korumayı sağlar. CSP, derinlemesine savunma kontrolüdür ve sunucu tarafı düzeltmelerin yerine geçmemelidir.
  4. HttpOnly ve Secure çerez bayrakları: JavaScript erişimini engellemek için tüm oturum çerezlerinde HttpOnly ayarını yapın. Yalnızca HTTPS üzerinden iletimi zorlamak için Secure bayrağını etkinleştirin.
  5. Alt Kaynak Bütünlüğü (SRI): Dışarıdan yüklenen betikler için, müdahaleyi tespit etmek amacıyla SRI hash'leri kullanın.
  6. Trusted Types API: Modern tarayıcılarda, DOM enjeksiyon havuzlarının ham dize kabul etmesini engellemek için Trusted Types API'sini (require-trusted-types-for 'script') zorunlu kılın.
  7. Güvenlik kod incelemesi ve DAST: Statik analiz (SAST) hatlarına XSS test senaryoları ekleyin ve tüm girdi yüzeylerinde dinamik uygulama güvenlik testi (DAST) gerçekleştirin. Sensagraph, sürekli tarama sırasında Stored XSS güvenlik açıklarını otomatik olarak tespit eder.
  8. Web Uygulaması Güvenlik Duvarı (WAF): Bir WAF, bilinen XSS kalıpları için ikincil bir tespit ve engelleme katmanı sağlayabilir; ancak birincil kontrol olmamalıdır.

Referanslar

Sıkça sorulan sorular

Yansıtılan XSS'de kötü amaçlı yük HTTP isteğine (örneğin bir URL parametresi) eklenir ve hemen yanıtta geri yansıtılır; depolanmaz. Stored XSS'de ise yük kalıcı bir veri deposuna yazılır ve etkilenen sayfayı yükleyen tüm sonraki ziyaretçilere sunulur. Bu, kurbanın özel hazırlanmış bir bağlantıyla hiç etkileşime girmesine gerek olmadığı anlamına gelir ve bu nedenle çok daha tehlikelidir.

HttpOnly, JavaScript'in document.cookie üzerinden çerez değerlerini okumasını engeller ve bu sayede belirli oturum belirteci hırsızlığı vektörünü azaltır. Ancak XSS yüklerinin kimliği doğrulanmış eylemler gerçekleştirmesini (sahte istek oluşturma), DOM'u manipüle etmesini, tuş vuruşlarını toplamasını veya kullanıcıları yönlendirmesini engellemez. Yararlı bir derinlemesine savunma önlemidir ama temel güvenlik açığının çözümü değildir.

İyi yapılandırılmış bir CSP, satır içi betik yürütmesini engelleyerek ve betiklerin yüklenebileceği kaynakları kısıtlayarak XSS yüklerinden kaynaklanan zararı önemli ölçüde sınırlayabilir. Ancak CSP, güvenlik açığının kendisini ortadan kaldırmaz; yanlış yapılandırmalar, 'unsafe-inline' kullanımı veya aşırı izin verici kaynak listeleri onu etkisiz kılabilir. CSP, sunucu tarafı çıktı kodlaması ve girdi temizlemenin yanı sıra derinlemesine savunma önlemi olarak ele alınmalıdır.

Yaygın enjeksiyon noktaları arasında yorum ve forum gönderi alanları, kullanıcı profil alanları (adlar, biyografiler, web sitesi URL'leri), ürün incelemeleri, dosya yükleme adları, sohbet mesajları, destek talebi açıklamaları ve değeri daha sonra bir HTML sayfasında işlenen herhangi bir alan sayılabilir. Bir yöneticinin oturumunu ele geçirmek tüm uygulama kontrolünü sağlayabileceğinden, yönetim arayüzleri ve günlük görüntüleyiciler yüksek değerli hedeflerdir.

Depolama sırasında temizleme, hiç yapılmamasından iyidir; ancak iki nedenden ötürü tek başına yeterli değildir. Birincisi, veriler her biri farklı kodlama gerektiren birden fazla bağlamda (HTML, JSON, JavaScript, e-posta) görüntülenebilir. Bir bağlam için depolama sırasında kodlama, diğer tüketicileri bozabilir ya da başkaları için yetersiz kalabilir. İkincisi, bağlama duyarlı çıktı kodlaması, zarar noktasına en yakın olduğu için işleme anında en güvenilir savunmayı sağlar. OWASP önerisi, yalnızca girdi temizlemeye güvenmek yerine çıktı noktasında, doğru bağlamda kodlama yapmaktır.