跳至內容

站點隔離

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書
圖示展現了站點隔離如何將不同網站分為不同進程
系列條目
資訊安全
相關安全分類
威脅
防禦

站點隔離（英語：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.100ke.info/w/index.php?title=站点隔离&oldid=83162633」