Webmail CSS 攻击暴露 AI 邮件防御的盲区

Google News 强调，自 2026 年 4 月以来，已有超过一百万封网络钓鱼邮件采用 Webmail CSS 攻击。这场活动暴露了 AI 邮件安全中的一个根本冲突：人和机器可能收到同一封邮件，却读取到截然不同的内容。

据报道，这种被称为“文本加盐”（text salting）的技术利用层叠样式表（Cascading Style Sheets），在 HTML 邮件中隐藏填充文本。这些隐藏内容会改变自动化系统对邮件的解读，但不会改变收件人所看到的内容。

Barracuda 的研究人员在以零售为主题的网络钓鱼活动中发现了这种技术，这些邮件承诺提供奖励、礼品卡、忠诚度积分或紧急兑换。攻击者利用隐藏文本稀释可疑措辞，使恶意邮件在自动过滤器看来更安全。

这并不只是另一种规避垃圾邮件过滤器的技巧。同样的可见性差异也可以反向利用。隐藏指令可针对能够总结邮件、起草回复、搜索邮箱或调用已连接工具的 AI 助手。

这带来了核心安全权衡：AI 邮件工具在读取更多上下文、获得更大访问权限时会更有用；但当不可信邮件内容影响模型时，这些能力也会放大后果。

传统防御假定，人们看到的邮件与软件检查的邮件内容大致等同。CSS 通过在一封邮件中创建面向人类可见和供机器读取的两个版本，打破了这一假设。

眼下的压力落在 Google、Microsoft、邮件安全厂商，以及构建基于邮箱数据的助手的开发者身上。他们必须在保留无障碍功能和合法格式的同时，协调原始邮件分析与渲染后的内容。

Google News 报道揭示的文本加盐问题

关键变化不在于攻击者发现了隐藏文本，而在于旧式规避方法如今可以欺骗基于 AI 的判断。

文本加盐会在恶意邮件中加入无害或与上下文无关的词语。安全软件会分析这些词语，但 CSS 会阻止收件人看到它们。

Barracuda 报告称，自 2026 年 4 月以来，已检测到采用这些技术的一百万次攻击。这些邮件属于一场围绕奖励与兑换优惠展开的零售主题活动。

攻击者使用了几种常见的 CSS 属性。clip-path: inset(100%) 将文本块的可见区域缩小至零。零高度和零行高规则则消除了可疑的空白区域。

其他规则会将文本推到屏幕边界之外。巨大的负值 text-indent 会将其向左移动数千像素，而 overflow: hidden 会隐藏可能暴露问题的滚动条。

攻击者还会将字体缩小到零。这些属性本身都不具有恶意性。由于合法邮件模板也可能使用相关的样式技术，因此简单的拦截名单并不可靠。

据报道，该活动依赖被入侵的网站或仿冒域名。一些域名支持标准邮件认证机制，包括域名密钥识别邮件（DomainKeys Identified Mail，DKIM），用于验证邮件是否由获授权域名签署。

DKIM 不会判断内容是否真实可信。它验证域名层面的邮件处理与完整性。控制着已认证域名的恶意运营者仍然可以分发网络钓鱼邮件。

这一差异很重要，因为 AI 系统通常会综合多种信号。认证、自然语言、发件人信誉、可见链接和邮件结构，都可能影响分类结果。

文本加盐操纵的是语言信号。它为分类器提供更多看似无害的文本，同时让网络钓鱼诱饵对人类收件人保持清晰可见。

检查原始 HTML 的过滤器可能会遇到有关无关业务活动、客户服务或普通零售交易的段落。收件人看到的则可能只有一则紧急奖励通知和一个按钮。

这形成了一种语义层面的对抗性输入。攻击者不一定是在利用软件内存漏洞，而是在塑造统计决策系统所依据的证据。

生成式 AI 还降低了生成多样化填充文本的成本。攻击者可以为每封邮件创建不同的无害段落，从而降低精确文本匹配的价值。

因此，Google News 的标题指向了更广泛的转变：邮件内容如今可以针对两类受众进行设计，为用户呈现一种叙事，为机器提供另一种叙事。

AI 邮件过滤器为何面临渲染难题

当 AI 模型的输入与收件人看到的邮件不一致时，它无法可靠地判断邮件。

许多邮件安全系统会检查原始邮件内容，因为其中包含有价值的证据：URL、HTML 属性、元数据、编码部分，以及可能在渲染中被隐藏的文本。

当隐藏文本主要针对基于关键词的垃圾邮件评分时，这种方法是合理的。防御者可以搜索可疑格式，并将可见词语与底层源内容进行比较。

大语言模型让这一过程变得更复杂。它们能够跨越长文本推断含义，但这种能力也让隐藏填充文本对分类结果产生更大影响。

模型可能看到一封由普通零售语言主导的邮件，而其中可见的网络钓鱼请求只占全部机器可读输入的一小部分。

该攻击并不要求模型遵循直接命令。只要足以改变表面主题、语气或意图，从而得出无害分类，它就可能成功。

渲染分析本身也有问题。不同邮件客户端对 HTML 和 CSS 的支持各不相同。一封邮件在 Gmail、Outlook、移动应用和专用 Webmail 软件中的显示可能不同。

无障碍功能也可能暴露默认视觉渲染所隐藏的文本。屏幕阅读器、高对比度模式和简化视图，使“唯一确定的呈现形式”这一说法变得复杂。

因此，安全工具需要的不只是截图。它们还需要对原始内容、计算后的布局、无障碍输出，以及典型用户能够感知的元素进行结构化比较。

最有价值的问题并非某项属性单独出现时是否可疑，而是该样式是否在人类感知与机器解读之间造成了实质性差异。

一个包含数百个无关词语的零尺寸段落，比单个隐藏格式标签更具可疑性。大块屏幕外文本也应受到类似审查。

防御者还可以比较可见区域和隐藏区域的语言含义。一封有关忠诚度奖励的邮件，不应包含与发票、旅行或客户支持无关的隐藏段落。

不过，攻击者可以适应。他们可以生成与可见主题仍然接近的填充文本，在稀释恶意短语的同时缩小语义差异。

这导致内容生成与可见性感知检测之间的军备竞赛。过滤器不仅必须理解邮件说了什么，还必须判断哪些部分对收件人重要。

机器学习在这里并非无用。它仍然适合发现结构异常、发件人模式、活动基础设施，以及样式规则的异常组合。

问题在于架构上的过度自信。语言模型无法弥补这样的输入管线：它将可信指令、不可信内容和不可见材料混合在一起，却没有清晰边界。

Google 曾描述过一套用于应对间接提示词注入的分层防御。其方法包括内容分类器、对抗训练、红队测试，以及在执行敏感操作前进行确认。

这些控制措施说明了邮件防御必须采取的方向。任何单一模型结论都不应决定一封邮件是否安全，尤其是在 CSS 会改变不同观察者接收内容的情况下。

隐藏内容既可针对过滤器，也可针对助手

同一可见性差异支持两种相反的攻击：向人隐藏无害文本，以及向人隐藏恶意指令。

文本加盐试图让恶意邮件在安全系统看来无害。间接提示词注入则试图让 AI 助手执行用户从未明知提供过的指令。

OWASP 将间接提示词注入定义为：嵌入外部内容中的恶意指令，之后由 AI 系统处理。电子邮件是天然的投递渠道，因为任何人都可以向许多邮箱发送输入。

攻击者可以通过白色文本、零尺寸字体、屏幕外定位、编码字符，或被视觉渲染器省略的 HTML 结构来隐藏指令。

受害者可能要求助手总结未读邮件。自动化工作流也可能在没有直接请求的情况下处理收件箱。无论哪种情况，模型都可能遇到攻击者编写的指令。

简单的攻击可能操纵摘要。AI 可能虚构安全警告、隐藏网络钓鱼迹象，或将恶意邮件描述为已获批准。

当助手能够搜索其他邮件、读取已连接文档、起草外发邮件或调用外部工具时，更严重的攻击就成为可能。

此时，恶意邮件充当控制输入。它可能试图将助手从用户任务转向数据检索、信息披露或未经授权的操作。

Microsoft 于 2026 年 7 月在 Defender for Office 365 中宣布了收件箱注入防护。该功能已面向符合条件的客户推出公开预览版。

Microsoft 表示，该系统会在邮件流检查期间检测恶意 AI 指令。检测到的邮件将获得高置信度网络钓鱼判定，并可在到达用户或已连接助手之前被隔离。

这一部署位置很重要。在投递前阻止攻击，可防止其进入邮箱搜索索引、检索系统、摘要和下游代理上下文。

不过，网关层检测无法解决所有情况。攻击者可以将恶意指令放入被入侵的内部账户、允许的邮件列表、转发邮件线程或附件中。

对语言模型来说，指令与数据之间的区别仍然很难处理。两者都以自然语言形式到达，也都可能包含请求、引用命令或程序性文本。

来自经理的邮件可能会合法地写道：“审阅附件并发送你的回复。”恶意注入也可以使用几乎相同的语言，但它是在对 AI 而非员工发出指令。

助手必须推断权限、来源和意图。仅凭自然语言流畅性无法提供这些安全属性。

这正是过滤器攻击和助手攻击应被放在同一讨论中的原因。两者都利用了显示内容、处理内容和获授权内容之间的模糊性。

Google News 提出的是一则关于 AI 驱动邮件防御的报道，但其影响超出了垃圾邮件分类。每个连接邮箱的代理都继承了这一尚未解决的输入边界问题。

EchoLeak 展示了当邮件接触工具时会发生什么

当 AI 助手能够检索私密上下文并在邮箱之外进行通信时，一封隐藏邮件会变得危险得多。

2025 年披露的 EchoLeak 事件发出了明确警告。研究人员描述了一种多阶段攻击，涉及 Microsoft 365 Copilot 和一封经过精心构造的电子邮件。

Microsoft 将 EchoLeak 标识为 CVE-2025-32711，并表示该问题已修复。该公司将其描述为一种跨提示注入技术，可能暴露受害者本已可访问的有限数据。

根据 Microsoft 的 AI 安全指南，一封看似无害的邮件可能污染 Copilot 处理的上下文。在特定条件下，该技术随后可能导致意外信息泄露。

该事件之所以重要，是因为它并不依赖于先窃取用户密码。它通过助手本应读取的数据来攻击助手。

EchoLeak 比 Google News 重点报道的文本加盐活动更复杂。它涉及多个阶段和条件，而文本加盐主要旨在规避分类。

不过，这两类事件都挑战了同一假设：电子邮件被视为内容，但其中某些内容可能对 AI 系统充当对抗性指令。

随着检索增强生成（RAG）的使用，风险也在增加。这种设计会检索相关的私有信息，并在生成答案前将其加入模型上下文。

RAG 能帮助邮件助手回答有关项目、日程、客户和过往讨论的问题。但它也让有价值的信息更接近攻击者可控的邮件内容。

工具访问权限又增加了一层风险。一个仅负责摘要的助手可能误导用户，但具备消息或文件工具的智能体则可能带来直接的业务后果。

开发者通常依赖系统提示词，要求模型忽略恶意指令。这一措施有帮助，但无法形成坚实的安全边界。

一项名为 LLMail-Inject 的大规模研究挑战赛收集了来自 839 名参与者的 208,095 份攻击提交。研究人员在逼真的邮件智能体环境中测试了多种防御措施、模型和检索配置。

提交量之所以重要，是因为自适应攻击者不会重复使用一句显而易见的短语。他们会探测转换方式、表达框架、编码、社会语境以及特定模型的行为。

防御方应假定任何分类器或提示词防护机制都可能产生漏报。敏感操作需要独立的授权控制，不能依赖模型的理解。

邮件摘要器不应仅因能够读取邮件就获得发送消息的权限。搜索权限也不应意味着可以访问每个邮箱文件夹或已连接文档。

工具调用应遵循最小权限原则，即每个组件只获得完成当前任务所需的权限。高影响操作应要求用户明确确认。

安全团队还需要日志，以显示是哪一封邮件影响了输出或操作。缺少来源追溯时，事件响应人员难以快速识别被污染的输入。

为 AI 系统管理源材料的用户也面临相关挑战。清晰的 信息采集 和来源隔离有助于保留上下文，但应用层权限仍然不可或缺。

EchoLeak 的教训并非所有邮件助手都不安全，而是它们的安全设计必须与其权限相匹配，而非与其对话式外观相匹配。

防御中的权衡：可见性与实用性

移除所有隐藏元素可减少部分攻击，但也会破坏合法邮件，并且无法解决更深层的授权缺陷。

严格的清理器可以在 AI 系统读取邮件前移除 CSS、隐藏元素、远程资源和复杂 HTML。这将显著缩小攻击面。

但它也会移除帮助用户和模型理解合法邮件的结构。表格、响应式布局、引用、签名、无障碍标签和事务性格式都可能承载有用含义。

部分隐藏内容具有业务用途。预览文本可以提供简短的收件箱预览，而响应式设计会在桌面端和移动端显示不同元素。

安全产品必须将这些情况与旨在操纵分类的大段隐藏内容区分开来。这个判断不能依赖某一项 CSS 属性。

在受控浏览器中渲染每封邮件可以改善可见性分析，但也会增加计算成本，并将浏览器引擎引入安全处理链路。

渲染视图仍可能无法匹配所有客户端。移动端宽度、深色模式、被阻止的图片、语言设置和无障碍偏好都可能改变结果。

更安全的策略是采用多种表示形式。系统可以保留原始内容用于取证分析，计算规范化视图，并单独识别隐藏或低可见度区域。

AI 分类器应获得这些区域的明确标签。隐藏材料不应悄然进入与可见内容相同、未加区分的文本流。

助手可以将隐藏文本视为不受信任的元数据。只有当用户请求安全分析时，它才应摘要这些隐藏内容。

提示注入检测器提供了另一层防护。Microsoft 的实现会在助手处理邮件前检查主题、正文、HTML、样式、转发内容和编码材料。

不过，提示注入检测具有概率性。合法邮件也可能包含关于提示词、安全测试、自动化命令或被引用恶意邮件的讨论。

研究团队可能通过电子邮件接收真实攻击样本。即使收件人预期收到这些内容，安全过滤器也可能将其隔离。

误报会带来削弱执行力度的压力。如果重要邮件过于频繁地消失，管理员就会添加例外规则，而攻击者可以研究并利用这些规则。

人工确认同样并不完美。特别是在重复性工作中，当界面将请求呈现为正常步骤时，用户往往会例行批准。

因此，确认机制必须说明拟议操作、其目标以及涉及的数据。一个含糊地询问是否“继续”的提示几乎无法提供保护。

最强的设计会将模型推理与策略执行分离。模型可以建议操作，而确定性软件则检查权限、目标位置、数据分类和审批要求。

这种方法可限制隐藏提示词和普通模型错误造成的损害。被操纵的助手无法超出其语言上下文之外所执行的边界。

代价是便利性降低。面对高风险任务时，用户可能会看到更多提示、更受限的集成，以及更慢的自动化流程。

当助手能够发送外部消息、检索机密文档、修改记录或发起财务流程时，这种摩擦是合理的。低风险摘要则可以保留较轻的控制措施。

因此，AI 邮件工具应采用分级授权。读取选定邮件、搜索文件夹、起草回复以及发送该回复应保持为独立的权限级别。

安全团队接下来应关注什么

下一阶段将取决于检测质量、权限设计和真实世界滥用的证据，而不是又一项模型基准测试。

第一个信号是具备可见性感知能力的邮件检查会更广泛地可用。Microsoft 的公开预览表明，提示注入正成为独立的邮件安全类别。

安全团队应关注供应商如何呈现这些检测结果。实用的产品会标识隐藏区域、解释其作用，并保留调查所需的证据。

通用的网络钓鱼判定并不足够。分析人员需要知道邮件中是否包含 CSS 隐藏填充内容、编码指令、可疑工具指令，或可见内容与原始内容之间的异常不一致。

第二个信号是 Google、Microsoft 和第三方开发者如何限制连接邮箱的智能体。与其说模型升级更重要，不如说围绕检索和工具使用建立可执行边界更重要。

采购方应询问助手是否能区分外部消息和内部指令。他们还应询问检索内容是否保留发件人身份、位置和信任级别。

管理员需要针对特定操作的控制措施。策略应允许摘要，而不自动允许发送外部邮件、访问文件、修改日历或调用第三方 API。

第三个信号是经过验证的攻击利用证据。Barracuda 的文本加盐数据表明，这类手法已被大规模部署来对抗过滤器，但并不能证明每封邮件都绕过了基于 LLM 的产品。

供应商应在可能的情况下公布方法论和分母数据。仅有检测数量并不能揭示投递率、成功分类率、受害者交互情况或后续入侵。

同样的谨慎也适用于提示注入演示。实验室攻击证明存在一条安全路径，但生产环境中的控制措施可能改变其实际可靠性。

反过来，缺乏公开事件也不能证明安全。AI 智能体操纵可能看起来像普通用户活动，如果没有详细日志，事件很难被识别。

组织无需等待完美的衡量指标。他们可以先梳理每一项允许 AI 处理入站邮件或检索邮箱上下文的工作流。

团队应记录每个助手能读取什么、能调用哪些工具，以及哪些操作需要审批。他们还应测试包含隐藏和屏幕外内容的邮件。

安全演练应涵盖两个攻击方向。一项测试应隐藏无害填充内容以规避分类；另一项则应隐藏旨在操纵助手的恶意指令。

开发者应评估系统是否能解释不确定性。检测到相互冲突或隐藏指令的助手应停止操作，并标识可疑来源。

用户应对邮件摘要中 AI 生成的警告保持警惕。即使界面属于可信提供商，一个精心包装的警告也可能源自攻击者可控的内容。

对于信息性工作流，应保留原始来源，并在采取行动前核查重要主张。AI 摘要应加快审查，而不是取代来源追溯。

Google News 让人们重新关注基于 CSS 的网页邮箱攻击，但长期问题远不止于一项活动。电子邮件如今承载着供人类、分类器、检索系统和自主工具处理的内容。

这些受众感知到的并不是同一封邮件。在安全系统直接建模这种差异之前，攻击者仍会持续利用人类所见与机器所读之间的鸿沟。