60 saniyede CVE-2025-31205
Bir web sitesi render için başka bir kaynaktan (cross-origin) stil şablonu (CSS) yükleyebilir; ancak Same-Origin Policy (aynı kaynak politikası - SOP), JavaScript kodunun bu stil şablonunun kurallarını okumasını engellemelidir. CVE-2025-31205 zafiyeti, bir DOM yaşam döngüsü (lifecycle) değişikliğinin ardından bu güvenlik sınırını kırdı: Zararlı bir script, cross-origin bir CSSStyleSheet nesnesine referans tutup ilgili <link> veya <style> öğesini DOM ağacından kaldırdığında (detach ettiğinde), WebKit’ten stil kurallarını okuyabiliyordu.
Saldırı yolu (attack path) şu şekilde gerçekleşti:
Zararlı web sitesi
-> Cross-origin bir stil şablonu yükler
-> CSSStyleSheet nesnesine referans tutar ve taşıyıcı öğeyi DOM'dan siler (detach)
-> ownerDocument() değeri null haline gelir
-> WebKit'in geri dönüş (fallback) mantığı "izin verildi" (true) döner
-> Normalde gizli kalması gereken cross-origin kurallar okunur veya değiştirilirApple bu zafiyetin etkisini cross-origin veri sızıntısı (data exfiltration) olarak tanımladı. Hata stil şablonunu aniden same-origin yapmadı; WebKit karşılaştırma için kullandığı belge bağlamını (ownerDocument) kaybetti ve “bilinmeyen” durumu hatalı bir şekilde “izin ver” (allow) olarak yorumladı.
Same-Origin Policy, CSSOM ve Origin-Clean Durumu
Same-Origin Policy, bir web sayfasındaki betiklerin farklı bir şema, host veya porttan gelen kaynakları serbestçe okumasını engeller. Bir sayfa harici bir stil dosyasını sayfayı boyamak (render) için kullanabilir; ancak CSS Object Model (CSSOM), kuralların JavaScript tarafından okunmasını engeller. Render izni ile JavaScript tarafından okunabilme tamamen farklı yetkilerdir.
WebKit’in CSSStyleSheet::canAccessRules() fonksiyonu, JavaScript’in bu kuralları okuyup okuyamayacağına karar verir. Güvenli bir mimaride bu karar kalıcıdır (origin-clean). Eski fallback mekanizması ise şablonun bağlı olduğu Document nesnesini bulmaya çalışıyor ve köken karşılaştırması yapıyordu.
Ne oldu?
JavaScript kodu bir stil şablonu nesnesini elde ettikten sonra ilgili HTML etiketini belgeden sildiğinde, stil nesnesi bellekte yaşamaya devam ediyor ancak ownerDocument() null dönüyordu. Savunmasız WebKit kodunda, eksik belge canAccessRules() fonksiyonunun true dönmesine yol açıyor ve hiçbir origin karşılaştırması yapılmadan kuralların okunmasına izin veriyordu.
WebKit, bu güvensiz varsayılanı false (fail-closed) olarak değiştirdi, origin-clean durumunu şablon nesnesinin tüm yaşam döngüsü boyunca korudu ve insertRule() ile deleteRule() fonksiyonlarının da aynı katı erişim kararına uymasını sağladı.
Evidence matrix
| Soru | Neyi kontrol ettim | Güven | Sınır |
|---|---|---|---|
| Hangi sürümler etkilendi? | Safari 18.5 öncesi ve WebKitGTK/WPE 2.48.2 öncesi sürümleri doğruladım. | Yüksek | Farklı platformlardaki WebKit gömülü uygulamaları ayrıca kontrol edilmelidir. |
| Yolu ne tetikliyor? | Cross-origin bir stil dosyasının DOM’dan silinmesi ve JavaScript ile kurallarının sorgulanması. | Yüksek | Tarayıcı eklentisi veya özel yetki gerektirmez. |
| WebKit neden izin veriyordu? | ownerDocument() null döndüğünde fallback mantığının return true dönmesinden kaynaklanıyordu. | Yüksek | Yama bu dönüşü doğrudan return false yaptı. |
| Güvenlik etkisi nedir? | Kullanıcıya özel cross-origin sayfaların CSS kuralları üzerinden veri sızdırılması (CSS injection/leak). | Yüksek | Doğrudan kod çalıştırma değil, hassas veri sızıntısıdır. |
Sonuç
Safari sürümünüzü 18.5 veya üzerine, WebKit kütüphanelerinizi güncel kararlı sürüme yükseltin.
Bu zafiyet temel bir güvenli yazılım tasarımı ilkesini bir kez daha teyit eder: Bir güvenlik denetimi eksik bağlam veya beklenmeyen durumla karşılaştığında daima kapalı duruma düşmelidir (fail-closed). “Sahip belirsizse izin ver” varsayımı, modern tarayıcıların en karmaşık güvenlik sınırlarını bile tek bir satırda çökertebilir.
Bu analiz için kullanılan kanıtlar
Sürüm ve sömürü durumu değişebilir; üretici kayıtlarını takip edin.
Yazar teknik incelemeyi tamamladı. Bu etiket tek başına laboratuvar yeniden üretimi iddiası taşımaz.