跳至內容

網站隔離

這是一篇優良條目，請按此取得更多資訊。
本頁使用了標題或全文手工轉換
維基百科，自由的百科全書
圖示展現了網站隔離如何將不同網站分為不同行程
系列條目
資訊保安
相關安全分類
威脅
防禦

網站隔離（英語：site isolation）是存在於某些網絡瀏覽器中的安全功能，能夠讓跨源網站彼此隔離。這一功能最初由查理斯·賴斯（Charles Reis）等人提出，隨後微軟在其Gazelle研究性瀏覽器（英語：Gazelle (web browser)）中實現了該功能的迭代版本。然而，由於實現過程中的問題以及效能方面的擔憂，該功能最初未被廣泛採用。

2017年，幽靈漏洞和熔毁漏洞被公開披露，次年谷歌開始在Chrome中開發網站隔離功能，並於2019年發佈。2021年，Firefox也推出了網站隔離功能，開發過程中使用了代號「Project Fission」。

該功能具有顯著的安全優勢，但研究人員發現了與之相關的一些安全問題，包括對瞬態執行攻擊（英語：Transient execution CPU vulnerability）的保護效果不佳，以及由該功能引發的新型計時攻擊（英語：Timing attack）和資源耗盡攻擊。

背景

2017年前，主流網頁瀏覽器的主要安全架構採用每瀏覽實例一行程（process-per-browsing-instance）模型。瀏覽器有多個沙箱行程，包括瀏覽器行程、GPU行程、網絡行程、彩現行程。在瀏覽網頁時，若需要特權提升，彩現行程會與其他特權服務互動。[1][2]

這種舊模型能夠防止惡意JavaScript訪問作業系統，但在有效隔離各個網站方面仍顯不足。[3]然而新模型在效能和主記憶體方面存在明顯問題，因此未被廣泛使用。[4][5]

2017年披露的幽靈漏洞和熔毁漏洞揭示了舊模型的嚴重缺陷。在漏洞披露前，任意訪問主記憶體難度很大，需要攻陷彩現器；而通過幽靈漏洞，僅需利用JavaScript特性即可讀取彩現行程中幾乎所有的主記憶體，從而取得先前彩現的跨源頁面中的敏感資訊。[6][7]為了防止類似的問題，需要開發新的安全架構，將不同網頁的彩現完全隔離到相互獨立的行程中。[7][8]

歷史

2009年，查理斯·賴斯（Charles Reis）等人首次提出了每網站一行程（process-per-site）模型，根據頁面的來源隔離網頁。[9]同年，Gazelle研究性瀏覽器（英語：Gazelle (web browser)）對此做出了改進，不僅在網站之間進行隔離，還在同一頁面中為每個來自不同域的內容元素建立獨立的行程。[10][11]與此同時，OP（OP2瀏覽器的前身）、IBOS、Tahoma、SubOS瀏覽器也在進行相關工作，提出了不同方式以解決網站之間的行程分離問題。[12][13]

應用

2019年，Google Chrome專案的賴斯等人在USENIX Security[14]上發表了一篇論文，詳細介紹了他們對瀏覽器安全模型所做的更改，以應對先前出現的幽靈漏洞。[15][16]該論文稱，這些更改參考了他和其他人在2009年提出的模型。[17]Chrome的網站隔離根據來源在行程層面區分「網站」。[18][19]此外，Chrome團隊還實現了在行程外執行網站框架，這是Gazelle網絡瀏覽器以及OP和OP2網絡瀏覽器的作者建議的功能。[12]這些改動需要重構Chrome的行程處理代碼。為此，320名貢獻者在5年內共提交了4000多次代碼。[20]

Chrome使用的網站隔離功能能夠防止多種通用跨網站指令碼（uXSS）攻擊。[21]這種攻擊允許攻擊者破壞同源政策，從而獲得在其他網站上注入和載入攻擊者控制的JavaScript的無限制訪問權。[22]Chrome團隊發現，2014年至2018年間報告的94起uXSS攻擊全部因網站隔離而失效。[23]除此之外，Chrome團隊還聲稱，網站隔離也能有效防止幽靈和熔毁漏洞的計時攻擊（英語：Timing attack）變體，這些攻擊依賴於攻擊者代碼與受害者數據在同一行程的地址空間內共存。[16]

2021年3月，Firefox開發團隊宣佈他們也將推出實現網站功能。這一功能花費數月開發，代號為「Project Fission」，[24]且重寫了行程處理代碼。[25]Firefox的實現方法與Chrome相比，能夠避免在某些特定網頁上受到uXSS攻擊。[26][27]

缺陷

2019年之前，網站隔離僅在研究性質的瀏覽器中實現。網站隔離啟用後，行程佔用的主記憶體空間增加，因此被認為是資源密集型的[5]。[28]這種效能開銷在實際使用中也有所體現。[29]Chrome使用網站隔離後，平均會多佔用一到兩個處理器核心。[5]此外，參與網站隔離專案的工程師觀察到，使用網站隔離時主記憶體使用量增加了10%到13%。[30][31]

Chrome是首個採用網站隔離作為防禦uXSS攻擊和瞬態執行攻擊（英語：Transient execution CPU vulnerability）的主流網頁瀏覽器。[32]為此，開發團隊克服了多個效能瓶頸和相容性問題，並在整個行業範圍內推動了瀏覽器安全性（英語：Browser security）的提升。然而，網站隔離針對幽靈漏洞的某些防禦措施仍顯不足，[6]尤其是在防禦計時攻擊方面。[33]2021年，阿尤什·阿加瓦爾（Ayush Agarwal）等人開發了名為Spook.js的攻擊，能夠突破Chrome的幽靈漏洞防禦，竊取其他來源的網頁上的數據。[34]同年，微軟的研究人員通過精細操控網站隔離所採用的行程間通訊協定，實施了各類計時攻擊，最終取得跨源資訊。[35]

2023年，波鴻魯爾大學的研究人員發現，他們能夠利用網站隔離所需的行程架構來耗盡系統資源，並執行DNS欺騙等進階攻擊。[36]

參考資料

參照

  1. ^ Reis & Gribble 2009，第225-226頁.
  2. ^ Dong et al. 2013，第78-79頁.
  3. ^ Jia et al. 2016，第791-792頁.
  4. ^ Dong et al. 2013，第89頁.
  5. ^ 5.0 5.1 5.2 Zhu, Wei & Tiwari 2022，第114頁.
  6. ^ 6.0 6.1 Jin et al. 2022，第1525頁.
  7. ^ 7.0 7.1 Röttger & Janc.
  8. ^ Rogowski et al. 2017，第336-367頁.
  9. ^ Reis & Gribble 2009，第224-225頁.
  10. ^ Paul 2009.
  11. ^ Wang et al. 2009，第1-2頁.
  12. ^ 12.0 12.1 Reis, Moshchuk & Oskov 2019，第1674頁.
  13. ^ Dong et al. 2013，第80頁.
  14. ^ Gierlings, Brinkmann & Schwenk 2023，第7049頁.
  15. ^ Kocher et al. 2020，第96-97頁.
  16. ^ 16.0 16.1 Reis, Moshchuk & Oskov 2019，第1661頁.
  17. ^ Reis, Moshchuk & Oskov 2019，第1663-1664頁.
  18. ^ Bishop 2021，第25-26頁.
  19. ^ Rokicki, Maurice & Laperdrix 2021，第476頁.
  20. ^ Reis, Moshchuk & Oskov 2019，第1667頁.
  21. ^ Kim & Lee 2023，第757頁.
  22. ^ Kim et al. 2022，第1007頁.
  23. ^ Reis, Moshchuk & Oskov 2019，第1668頁.
  24. ^ Cimpanu 2019.
  25. ^ Layzell 2019.
  26. ^ Narayan et al. 2020，第714頁.
  27. ^ Kokatsu 2020.
  28. ^ Reis & Gribble 2009，第229-230頁.
  29. ^ Wang et al. 2009，第12-13頁.
  30. ^ Warren 2018.
  31. ^ Reis, Moshchuk & Oskov 2019，第1671頁.
  32. ^ Jin et al. 2022，第1526頁.
  33. ^ Jin et al. 2022，第1527頁.
  34. ^ Agarwal et al. 2022，第1529-1530頁.
  35. ^ Jin et al. 2022，第1525-1530頁.
  36. ^ Gierlings, Brinkmann & Schwenk 2023，第7037-7038頁.

來源

取自 "https://zh.wikipedia.org/w/index.php?title=站点隔离&oldid=84825654"