有人在评估ShareMyPage时问了我们收到的最尖锐的问题。你托管用户上传的任何HTML，包括JavaScript，那么是什么阻止这些代码注入一些内容，或者通过脚本劫持会话呢？这是个非常合适的问题。托管任意HTML是整个产品的核心，而很多HTML是由AI生成并在没有人逐行阅读的情况下粘贴进去的。因此，诚实的回答不是“我们清理它”。而是我们假设每个页面都是敌对的，并让这个假设无关紧要。我们为什么不清理HTML？显而易见的本能是从上传内容中剥离任何危险的东西。我们故意不这样做，有两个原因。第一个是这会破坏产品。人们在这里分享的页面是实际的页面：获取和绘制数据的仪表盘、可以点击浏览的原型、小型交互工具。JavaScript是关键。剥离它后，你只剩下一个截图。第二个原因是清理不受信任的HTML是一场永久的军备竞赛，防御者在错过一次情况的那一刻就输了。当你的安全依赖于捕捉每一个危险的构造时，任何单点漏洞都是一次突破。因此，我们采取了相反的方法：按原样运行页面，但在某个不会对你、对我们或对任何打开它的人造成伤害的地方。这就是整个技巧。与其试图使HTML安全，我们倒不如让它运行的地方安全。文件的任何内容都不必可信。每个页面都在一个没有源的沙盒中运行。共享页面从未直接在网站上呈现。它是在一个沙盒化的iframe内加载的，而沙盒恰好允许它成为一个真实页面，但没有让它接触到任何人的权限。<iframe src="{生成的短期签名URL}" sandbox="allow-scripts allow-popups allow-forms allow-downloads allow-popups-to-escape-sandbox allow-top-navigation-by-user-activation" referrerpolicy="no-referrer"></iframe>。沙盒列表中缺少的内容比其中包含的内容更加重要：没有allow-same-origin。这个单一的遗漏赋予框架文档一个不透明、空的来源。它的脚本仍然运行，因此图表动画和表单提交，但document.cookie返回为空，localStorage不可用，无法读取或访问框架它的页面。它是一个属于完全无源的实时页面。最后两项条目allow-popups-to-escape-sandbox和allow-top-navigation-by-user-activation则是一种不同类型的权限。它们允许个人的点击访问外部世界，因此“预约通话”的链接或mailto打开，而不是静默失败。它们受限于真正的用户手势，仅仅管控导航，而不是数据。关于cookie、存储和来源的所有内容都不受影响。这是我们从不破坏的唯一规则。allow-scripts和allow-same-origin绝不能一起出现。它们结合会将框架脚本交还一个真实的来源，并悄然撤销整个保护。将这两者分开是一道承重线。页面存在于一个独立的、不含cookie的来源。沙盒是第一层。第二层是内容的提供来源。HTML并不是来自你登录的应用程序。它是从一个不同的来源通过短期签名URL提供的，而该来源从不设置或读取cookie。你的登录会话存在于应用程序的来源上。在内容来源上根本不存在。所以即使在假设的情况下，某个脚本以某种方式突破沙盒，也没有任何东西可以获取：没有会话cookie，没有令牌，没有登录的任何东西。我们自己代码中的注释清楚地表述：即使是沙盒逃逸也找不到可以盗取的东西。我们还锁定了谁允许将该内容框架到我们应用程序，因此页面无法被提取并重新用于在其他地方伪装成引人注目的框架。因此，注入和会话劫持，直接来说这就是原始问题中的两个词，直接面对它们。注入是指通常由跨站脚本攻击意味着的不受信HTML在您受信任的、带cookie的来源内执行，在那里它可以读取属于你的DOM和cookie。在ShareMyPage上，不受信的HTML绝不会触碰那个来源。没有值得信任的上下文供其注入。它是基于结构的隔离，而不是检查。会话劫持通过JavaScript工作，读取会话cookie或令牌并重放。在我们的沙盒中，脚本有一个空的来源，因此在开始之前cookie和存储访问已经消失。而它运行的来源本身没有会话。两个独立的原因使攻击找不到可抓取的目标。担忧的原因 为什么没有成功 脚本注入（XSS） 上传的页面从未在应用程序来源上运行，因此没有值得信任的DOM或cookie来注入。通过JS进行会话劫持 空源沙盒阻止了cookie和存储访问，而内容来源根本没有可盗取的会话。层次结构，所以没有单个锁是承重的。良好的安全性不依赖于一个巧妙的控制。它叠加了多个层次。