Apple為WebKit框架添加了新的保護措施,以防止可能濫用HTTP嚴格傳輸安全(HSTS)安全標準來跟蹤用戶。HSTS提供了一種機制,通過這種機制,網站只能通過安全連接和直接瀏覽器訪問安全版本所在的位置來聲明自己。 基本上,當用戶嘗試連接到網站的不安全版本時,HSTS強制瀏覽器轉到網站的HTTPS版本。
由于HSTS告訴網絡瀏覽器在被重定向到安全位置時記住并且將來自動去那里,可以創建一個“超級cookie”,并且它可以被跨站點跟蹤器讀取。攻擊者可以利用用戶的HSTS緩存在設備上存儲一位信息。 通過注冊大量域并強制從受控子域中加載資源,攻擊者“可以創建足夠大的比特向量來唯一地表示每個站點訪問者。”
在HSTS規范中描述了這個問題:“對于那些控制一個或多個HSTS主機的人來說,將信息編碼成他們控制的域名是可能的,并且使得這些UA緩存這些信息當然是在注意HSTS的過程中 主辦。 這些信息可以由其他主機通過巧妙構建和加載的網絡資源來檢索,導致UA發送查詢到(變體)編碼的域名。“
緩解這種跟蹤攻擊并不容易,因為它需要平衡安全和隱私目標。 但是,由于HSTS的隱私風險僅作為理論追蹤向量呈現,但尚未提供實際惡意濫用協議的證據,因此瀏覽器將遵守網站提供的所有HSTS指令。
蘋果最近意識到這種理論攻擊已經開始針對Safari用戶進行部署。 這促使這家科技巨頭開創了一個既保護安全網絡流量又減少跟蹤的解決方案。由于HSTS漏洞需要創建一個初始跟蹤標識符并讀取它,Apple建議對攻擊雙方進行緩解。
一方面,蘋果公司修改了網絡堆棧,只允許為加載的主機名或頂級域+ 1設置HSTS狀態。因此,跟蹤器不能再有效地在大量不同的位上設置HSTS,但需要單獨 訪問跟蹤標識符中具有活動位的每個域。 WebKit還限制了可以鏈接在一起的重定向數量,從而限制了可以設置的位數。另一方面,當動態HSTS導致一個不安全的第三方子資源從被阻塞的cookie升級到認證連接的域中加載時,Apple還修改了WebKit以忽略HSTS升級請求(并使用原始URL)。
在內部回歸測試,公共種子和最終的公共軟件發布期間收集的遙測數據表明,上述兩種緩解成功地阻止了HSTS超級cookie的創建和閱讀,同時又不會使第一方內容的安全目標退步。 我們相信他們符合最佳實踐,并保持HSTS提供的重要安全保護,
原文:https://www.securityweek.com/apple-addresses-hsts-user-tracking-webkit