搞企业安全的同行们最近被一份报告整破防了。大家普遍觉得，像Writer这种给大企业内部用的生成式AI平台，里面的租户隔离、会话管理这些事，应该都是水桶级别的严密。但Sand Security Research团队刚放出的细节表明，攻击者要拿下任意一家用Writer的企业，门槛低得离谱——只需要发一个带预览链接的消息就够了。这一键式漏洞的代号叫作WriteOut，整个利用过程甚至不需要攻击者在目标组织里事先有任何立足点。
用安全团队的原话讲就是：“一位外部人员，仅凭一个链接，就能从零权限变成任意Writer AI组织内部的实际用户，进而接管那些行业头部企业里的整个工作区。”这句话绝非耸人听闻。背后是一个在会话隔离机制上彻底漏风的架构，把跨租户安全这堵墙直接推倒了。
具体能拿到什么级别的权限，很大程度上要看受害者在Writer里面的角色。如果只是个普通业务人员，那攻击者能看到的是他所有私人聊天记录、文档、私有模型、连接器配置，以及对接大语言模型要用到的凭据。如果恰好点开链接的是管理者，那攻击者就相当于拿到了整个组织的行政管理控制权。最要命的一点是，攻击者和受害者完全可以不在同一家公司、同一个租户下面。这条规则一旦被打破，就意味着一个用户在不知情的情况下，就会把自己的会话令牌明明白白地送给另一个完全不相干的组织里的攻击者所设下的陷阱里去。
这个漏洞的逻辑链条非常好懂，甚至可以说简单到显得粗糙。我们可以把它拆成几步来看：
第一步，攻击者在自己的Writer账号里创建一个带有实时预览功能的智能体。所谓实时预览，原本是Writer给开发者提供的一种便捷调试方式，让用户能在写下代码的同时立刻看到界面效果。攻击者把这个预览界面以公开链接的形式分享出去。
第二步，受害者收到了这个链接，并且在已经登录Writer的状态下点开了它。此时，浏览器按照标准的同源请求机制，会自动把与该域名关联的会话Cookie附加到这次HTTP请求里。受害者很可能只是好奇这是什么，或者误以为这是某个合作方发来的Demo，根本意识不到自己的一次点击会把身份标识送进别人的沙箱。
第三步，Writer的预览代理在接收到请求后，并没有检查这个Cookie的来源是否与预览所在租户匹配，而是原封不动地把Cookie转发到了攻击者的沙箱环境里。到这里，租户隔离已经形同虚设。
第四步，攻击者在自己的沙箱里预先放置了一段脚本。这段脚本会从沙箱进程的内存里读取刚刚被转发过来的会话令牌，然后把令牌提取出来，发送到攻击者自己控制的外部服务器上。因为是攻击者自己构建的智能体，他完全有能力指示这个智能体在受控的托管沙箱中运行任意代码，从而读取内存中的敏感数据。
第五步，拿到会话令牌之后，攻击者只需在自己的机器上重放这个令牌，浏览器就会认为攻击者就是那个受害者，直接以该用户的身份登录到Writer。于是，那些原本只能由受害者本人才能查看和操作的一切资源，就全部暴露在了攻击者面前。包括但不限于：私密聊天记录、内部文档库、定制过的私有模型、连接外部系统的数据管道配置，以及访问大语言模型所必需的后台凭据。如果攻击者意图更恶劣，还能利用受害者账户去触发工作流、修改配置，甚至在组织内部进一步横向移动。
这个攻击路径里，攻击者唯一需要付出的动作就是在自己的账户下创建一个智能体，然后复制一条预览链接。没有社工话术的精心设计，没有木马要投递，不需要任何内网渗透的技巧，更不需要蹲守在受害者公司的任何网络节点上。只要受害者点击，就会中招。这种简洁程度，让人很难把责任完全归咎于用户的安全意识薄弱。
有趣的是，Writer在事前并不是完全没有做出努力。Sand Security在报告里也特意提了一嘴：“Writer不是粗心大意，他们确实设了一些护栏。输入侧有过滤机制，作用是阻止用户读取环境变量或者提交那些明显一看就有问题的恶意代码。”可问题恰恰就出在这里——这些检查在看什么东西。它们看的是代码的文本内容，也就是指令长什么样，而不是看这段代码在运行时会做什么。
攻击者要绕过这种基于文本的检查简直太容易了。稍微做一下混淆，或者把恶意行为拆分成几步，拆到不同的函数和回调里，静态的规则就很难再抓到。运行时行为完全没有被监控，沙箱进程可以读取自身内存这件事也没有被限制。换句话说，只要恶意指令在运行之前看起来足够干净，Writer的防护机制就会放行。等到真正执行的时候，那段“干净”的代码就能大大方方地把转发进来的会话令牌打包盗走。
这也暴露了当前很多AI平台在做沙箱隔离时的一个通病：它们习惯性地把安全防线设在输入阶段，以为靠关键词匹配或者静态分析就能挡住恶意利用，却忽视了运行时的动态行为控制才是更关键的底线。专供大企业使用的AI平台，必然会面临多租户之间的高度敏感信息隔离问题，如果租户间会话能被如此轻易打穿，那么所谓的“企业级安全”就只剩下一个漂亮的营销标签。
好在Writer在接到负责任披露之后，针对这个漏洞的修补方案做得比较彻底。他们没有只是在前端加一层校验，而是从架构上直接切断了泄露路径。目前的修复包括两项核心措施：一是完全阻止用户的会话Cookie被转发到沙箱预览环境中，二是把这些预览页面迁移到独立的隔离源上。这样做的结果就是，即便攻击者仍然能够在自己的沙箱里执行任意代码，它也再也拿不到受害者的会话令牌，因为那个令牌从一开始就不会被送进沙箱。
WriteOut这个漏洞的特别之处在于，它狠狠扇了“共享责任模型”一巴掌。在多数云服务的安全宣传里，厂商通常只会说“底层基础设施由我们来保护，客户需要管好自己的身份和访问策略”。而这一次，问题恰恰出在厂商自己负责的那一层——租户隔离是由Writer的实时预览特性主动打破的。攻击者甚至根本不需要去针对受害者的组织做什么，只要守株待兔就好了。
换个角度来看，如果一家企业使用的AI平台允许不同的组织之间存在这样一条不经意的通道，那么所有在这个平台上搭建的AI应用、存储的业务数据、集成的内部系统，实际上都站在一个随时可能被别人跨越的界面上。这比传统的单点漏洞更危险，因为它威胁的是整个生态里的每一家公司，而且攻击成本极低，发现难度却很高——毕竟被入侵的状态看起来就像是受害者在正常使用自己的账号。
对安全运营人员来说，这次事件至少提供了三点值得思考的教训。第一，任何带有“分享预览链接”功能的协作型AI工具，都应该视为潜在的高风险攻击面，需要重点关注跨租户请求转发时的身份隔离问题，而不是想当然地相信框架自带的同源策略会自动生效。第二，对于沙箱这类执行环境，输入过滤绝不能作为唯一防线，运行时内存访问行为、网络外传控制，以及进程的能力边界，这些都需要有明确的硬性限制。第三，对于已经大范围部署生成式AI平台的企业，应该立即检查平台是否已将预览服务迁移到独立源，并对所有历史分享出去的智能体预览链接进行重新审核，避免有未授权的会话转发路径残留。
说到底，这次漏洞能让攻击者“零门槛”接管账户，并不是因为用了什么高深的零日技术，而是因为在特性设计的时候，预览功能为了追求即时可用的开发体验，把安全这道门拆得太松了。当用户体验和安全相互冲突时，优先保证前者的习惯往往会埋下这种看起来不可能、但又确实会发生的大坑。而一旦出事，所有使用这个平台的企业，不管自己把密码策略定得多严、把网络分区做得多细，都没有用，因为那扇门从一开始就开在了自己家墙壁的另一面。
热门跟贴