Firefox 148, setHTML ile XSS korumasını güçlendiriyor

 (hacks.mozilla.org)
5 puan yazan GN⁺ 2026-02-26 | 2 yorum | WhatsApp'ta paylaş
  • Web’in başlıca açıklarından XSS saldırılarını önlemek için Firefox, standartlaştırılmış Sanitizer API desteğini ilk kez sunuyor
  • Mevcut innerHTML yerine setHTML() yöntemi kullanıldığında, güvenilmeyen HTML DOM’a eklenmeden önce otomatik olarak sanitize edilerek kötü amaçlı betikler kaldırılıyor
  • Geliştiriciler, varsayılan ayarlar fazla katı ya da yetersiz olduğunda özelleştirilmiş ayarlar ile izin verilecek öğeleri ve öznitelikleri kontrol edebiliyor
  • Firefox’taki bu özellik, Trusted Types ile birleşerek web genelinde güvenlik seviyesini yükseltiyor ve geliştiricilerin ayrı bir güvenlik ekibi olmadan da XSS’i önleyebilmesini sağlıyor

XSS açığı ve Firefox’un yanıtı

  • Cross-site scripting (XSS), kullanıcı girdili içerik üzerinden saldırganın keyfi HTML veya JavaScript ekleyebilmesi durumunda ortaya çıkar
    • Saldırganlar bunu kullanıcı etkileşimlerini izlemek veya verileri çalmak için kullanabilir
    • XSS, yaklaşık 10 yıldır en büyük 3 web açığından biri (CWE-79) olarak sınıflandırılıyor
  • Firefox, 2009’dan beri Content-Security-Policy (CSP) standardına öncülük ederek XSS savunmasını güçlendiriyor
    • CSP, bir web sitesinin yükleyip çalıştırabileceği kaynakları sınırlar
    • Ancak mevcut site yapısında değişiklik ve sürekli güvenlik incelemesi gerektirdiğinden geniş çaplı benimsenmesinde sınırlamalar vardı

Sanitizer API ve setHTML()’in rolü

  • Sanitizer API, kötü amaçlı HTML’yi zararsız bir biçime dönüştürmek için standartlaştırılmış bir yöntem sunar
    • Örnek kodda `` öğesi kaldırılır ve yalnızca `Hello my name is
    Reklam

` kalır

  • setHTML() yöntemi, HTML ekleme sırasında temizleme sürecini otomatik olarak gerçekleştirerek varsayılan olarak güvenli davranışı garanti eder
    • Mevcut innerHTML atamasını yalnızca setHTML() ile değiştirmek bile güçlü bir XSS savunması sağlayabilir
  • Geliştiriciler, varsayılan ayarlar çok katı ya da çok gevşekse, özel ayarlar aracılığıyla izin verilecek HTML öğelerini ve özniteliklerini tanımlayabilir
    • Denemeler için Sanitizer API playground aracı kullanılabilir
    Reklam

Trusted Types ile birleşim

  • Trusted Types API, HTML ayrıştırma ve eklemeyi merkezi olarak denetleyerek ek bir güvenlik katmanı sağlar
    • setHTML() kullanılırken Trusted Types politikaları kolayca uygulanabilir
    • Sıkı politikalar yalnızca setHTML() kullanımına izin verip diğer riskli ekleme yöntemlerini engelleyerek gelecekteki XSS regresyonlarını önlemeye katkı sağlar

Firefox 148’in güvenlik iyileştirmesi etkisi

  • Firefox 148, hem Sanitizer API hem de Trusted Types desteği sunarak temel güvenlik seviyesini önemli ölçüde yükseltiyor
  • Geliştiriciler, karmaşık güvenlik politikaları veya ayrı bir güvenlik ekibi olmadan da yalnızca basit kod değişiklikleriyle XSS’i önleyebilir
  • Bu standardın benimsenmesinin, tüm tarayıcılarda daha güvenli bir web ortamının yayılmasına katkı sağlaması bekleniyor

Özet

  • Firefox 148, setHTML() yöntemi ve Sanitizer API ile web geliştiricilerinin XSS saldırılarını kolayca engellemesini destekliyor
  • Bu özellik, CSP’nin sınırlamalarını tamamlıyor ve varsayılan olarak güvenli HTML ekleme yöntemini web standardı hâline getirmek için bir dönüm noktası oluşturuyor
  • Trusted Types ile birleştiğinde uzun vadeli güvenliğin korunması ve XSS regresyonlarının önlenmesi mümkün oluyor
  • Sonuç olarak Firefox, güvenliğin varsayılan olduğu bir web ortamına geçişe öncülük ediyor

İlgili okumalar

2 yorum

 
huiya 2026-02-26

Ah evet, buna gerçekten ihtiyaç var. Tüm tarayıcılarda desteklenirse bence müthiş olur.
 
GN⁺ 2026-02-26
Hacker News görüşleri

  • Bu tür özellikler her zaman biraz rahatsız edici geliyor Çünkü kullanıcı girdisini rastgele verince güvenli işleyen metotlarla güvenli olmayan metotlar karışık durumda ve sadece isimlerine bakarak aradaki farkı anlamak zor İdeal olarak, tehlikeli fonksiyonlar en baştan isimlerinden açıkça belli olmalı Ayrıca HTML’i “sanitize” etme fikri başlı başına muğlak ve bunun gerçekten güvenli olup olmadığını değerlendirmek zor

    • “Güvenli” tanımının muğlak olduğu doğru, ama buradaki hedef XSS-safe olmak Script çalıştırabilen öğe ve öznitelikleri kaldırıyor ve bu mantık tarayıcı motorunun içinde çalıştığı için string tabanlı sanitizer’lardan daha doğru işliyor Ayrıntılar için MDN setHTML belgesine bakılabilir
    • Aslında zaten net bir ayrım var elementNode.textContent güvenilmeyen girdiler için güvenliyken elementNode.innerHTML değil İlki tüm karakterleri escape eder, ikincisi ise hiçbir şeyi escape etmez “HTML sanitization”ın temelde çözülemez bir problem olduğunu düşünenler de var İlgili tartışma için bu yoruma bakılabilir Bu API’lerin öneri aşamasını geçmemesi gerekirdi
    • Tasarım, innerHTML ile setHTMLi birlikte kullanmak yerine innerHTMLi tamamen kaldırıp eski davranış gerekirse setHTMLUnsafe kullanmak şeklinde olmalıydı
    • Web geliştiricileri innerHTML gibi eski API’leri genel bir ayarla devre dışı bırakabilse güzel olurdu Ama o durumda site eski tarayıcılarda çalışmayabilir
    • Sayfa Content-Security-Policy: require-trusted-types-for 'script' başlığıyla sunulursa, sanitizer olmayan metotlara normal string geçirilmesi engellenebilir

  • Örnekteki gibi kullanıcı adına ya da ` ` gibi etiketler eklenebiliyorsa, script çalıştırmayı engellese bile hâlâ **keyfi markup enjeksiyonu** mümkün olur etiketiyle CSS de değiştirilebilir; mesela bir PayPal profil sayfasının tasarımı değiştirilebilir İnsan neden böyle bir şeyi istesin diye düşündürüyor

    • Yine de forum gibi yerlerde kullanıcıların Markdown kullanmasına izin vermek istendiğinde faydalı olabilir Markdown’dan üretilen HTML’i sanitizer ile bir kez daha sınırlandırıp sadece belirli etiketlere izin vererek ek bir savunma katmanı oluşturulabilir
    • Böyle bir durumda innerHTML yerine innerText ya da textContent kullanılmalıydı setHTML, innerHTMLin yerine geçmesi için var
    • setHTML()in varsayılan ayarları fazla katı ya da fazla gevşekse, geliştirici izin verilecek HTML öğeleri ve özniteliklerini tanımlayan özel bir yapılandırma sağlayabilir
    • Yalnızca CSS ile bile güvenlik riski oluşabileceği için yine de dikkatli olmak gerekir İlgili tartışma için bu başlığa bakılabilir
    • Örneğin 
      .setHTML("Hello

", new Sanitizer({})) ``` Böyle yapıldığında tüm öğeler kaldırılır Sonuç olarak backend tarafında da kullanıcı adı hâlâ standart şekilde sanitize edilmeli ve çıktı verilirken HTML escape uygulanmalı RFC 2119’a göre bu bir “SHOULD” seviyesinde gerekliliktir

  • Bu özelliğin gelmesi sevindirici, ama tarayıcı desteğinin yeterince yayılması zaman alacak gibi görünüyor Destek durumuna Can I use üzerinden bakılabilir

    • Diğer tarayıcı API’lerinde olduğu gibi birkaç yıl sürebilir ya da sadece en güncel sürümler hedefleniyorsa birkaç ay içinde mümkün olabilir O zamana kadar polyfill kullanılabilir

  • Başlık biraz sansasyoneldi Aslında innerHTMLe vermeden önce girdiyi kontrol eden bir fonksiyonla sanitization uygulanamaz mı diye düşündüm Ama bu tür girişimler sonuçta tekerleği yeniden icat etmek gibi hissettiriyor Ayrıca eski Firefox sürümlerinde hacks.mozilla.org hiç açılmıyor ve Pale Moon ya da SeaMonkey’de MDN bozuk görünüyor Sanki bir “tarayıcı karteli” web’i bozmak istiyor gibi

    • “Girdi kontrol fonksiyonuyla çözülebilir” demek, “C dilinde de bug olmazsa bellek güvenliği vardır” demekle aynı şey Parser differential meselesini de hiç hesaba katmıyor

  • Sanitizer API yanlış kullanılırsa bir footgun olabilir Özellikle “remove” modu kullanılırken dikkat etmek gerekir Bence en iyisi sadece setText kullanmak ve kullanıcıların hiç HTML eklemesine izin vermemek

    • Allowlist tabanlı bir Sanitizer kullanılırsa risk azalır, ama setHTML kullanıldığı sürece XSS ortaya çıkmaz
    • Ama sayfa yazarı büyük HTML parçaları eklemek zorundaysa ne olacak innerHTMLin sık kullanıldığı gerçeğine bakınca bunu tamamen dışlamak zor
    • Hatta böyle bir API, “%100 güvenli” olduğu yanılgısını doğurup daha da tehlikeli olabilir

  • Ağ erişiminin tüm yönlerinin düzgün biçimde kontrol edilmesi ve artık güvenlik zincirinin kod güveninden host yapılandırmasına güvene kaymış olması etkileyici Varsayılanlar da güvenli seçilmiş

  • Benim gerçekten istediğim şey, tehlikeli kodu güvenli şekilde çalıştırabilecek bir `` öğesi Amaç tehlikeli kodu düzeltmek değil, onu yalıtılmış bir ortamda çalıştırabilmek iframe DOM ile birlikte akamıyor gibi kısıtlara sahip ve yapay zeka ile dinamik içeriğin arttığı bir dönemde birleştirilebilir kapsülleme gerekiyor

  • setHTMLUnsafe ismini gerçekten beğendim Güvenlik özellikleri geliştiricinin opt-in yapmasına bağlı olduğunda başarısız oluyor Bunun yerine “tehlikeli yolun tehlikeli hissettirmesi” daha etkili

  • set_html() adı inner_htmlden çok daha sezgisel JavaScript API’leri gerçekten darmadağın; bir gün toparlanmaları gerekiyor Bu tartışma güvenliğe odaklanıyor ama yeni API yayımlanırken tasarımın kendisi de temiz olmalı

    • Teknik olarak bu bir DOM API DOM API’leri eskiden de şimdi de “sanki daha önce hiç API tasarlamamış insanlar yapmış” hissi veriyor

  • 90’lardaki geliştiriciler:

    SQL("select * from user where name = " + name);

    2020’lerdeki geliştiriciler:

    div.innerHTML = "Hello " + user.name;
    • 2030’lardaki geliştiriciler: 
      "Summarize this email: " + email.contents
      Prompt injection, sadece yeni teknoloji üstünde ortaya çıkan aynı problemin başka bir hali 90’lardan hiçbir şey öğrenmemişiz