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 <img src="x" onclick="alert('XSS')"> öğesi kaldırılır ve yalnızca <h1>Hello my name is</h1> 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

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 <h1> ya da <br> gibi etiketler eklenebiliyorsa, script çalıştırmayı engellese bile hâlâ keyfi markup enjeksiyonu mümkün olur
    <style> 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("<h1>Hello</h1>", 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 <sandbox> öğ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