这两天安全圈讨论度最高的话题就是某头部安全厂商披露的一组零点击数据窃取攻击分析。攻击目标不是某个偏门系统而是大家几乎每天都在用的对话式AI产品。这类应用承载了大量日常沟通、代码片段、内部文档摘要甚至被不少人当成了第二大脑。一旦会话数据被无声无息地拿走损失的可不只是几条聊天记录那么简单。先说清楚一个容易误解的点零点击不代表攻击有多高深而是指整个攻击过程不需要受害者进行任何交互。不需要点链接、不需要下载文件、不需要输入密码只要你的浏览器环境被污染页面在后台运行几秒钟数据就可能已经外传了。对普通用户来说毫无感知对安全团队来说这才是最麻烦的地方因为传统那套“提醒用户别乱点”的防线完全失效。这篇文章我从攻击者视角拆一遍这类攻击的完整链路再讲清楚个人和企业分别该怎么堵口最后整理我在排查这类问题时踩过的坑。既适合安全运维和开发人员拿去做防护参考也适合普通用户当作一份自我排查清单来用。1. 事件画像攻击者真正盯上的是“对话数据”这个富矿1.1 零点击到底是怎么定义出来的很多人一听“零点击”就以为是某个远程代码执行漏洞像浏览器出了个0day攻击者直接弹个框就能控制你电脑。实际上这次披露的案例更贴近“半寄生式”攻击攻击者利用的是浏览器扩展生态的信任机制和服务进程的常驻能力而不是去挖AI产品本身的内存漏洞。所谓零点击准确说是指受害者端“零交互”。数据被窃取时你可能正开着对话AI的页面在忙别的事没有在页面上进行任何点击、没有输入任何密钥、没有授权任何弹窗。攻击动作发生在浏览器扩展的后台脚本里脚本通过浏览器开放的API拿到当前标签页的HTML、Cookie或本地存储内容然后默默握手外联。这里有个关键前提攻击者的代码需要先一步进到你的浏览器环境里。可能是你安装了一款看似正常的“翻译助手”扩展也可能是被恶意软件修改过的浏览器组件还有可能是经过签名校验的绿色软件捆绑安装。总之零点点头衔指的是“偷”这个动作不需要人工触发但前提条件依然需要社会工程或供应链污染来铺路。1.2 对话式AI里的数据为什么是高级别“富矿”传统窃密木马偷的是密码、Cookie、银行账号而对话式AI应用里存的是另一类高价值资产。你让AI帮你润色一封邮件邮件里可能带着客户的称呼、项目代号和报价基线你让AI帮你解释一段代码代码里可能藏着内网域名、数据库连接字符串你让AI帮你整理会议纪要纪要里可能包含了决策人、时间节点和未公开的业务计划。这些数据有几个特点让它们特别“值钱”半结构化不是明文密码但经过上下文串联后能还原出完整业务线索。长期留存很多AI产品会保留历史会话攻击者拿到的可能是一整年的对话档案。天然可读不需要解包、解密、逆向拿到就是一段段连贯的文字。可信度高攻击者可以拿这些内容做精准钓鱼、商业情报倒卖甚至伪造你的口吻对外联络。如果把传统浏览器 Cookie 比作一把能打开你家门的钥匙那对话记录就相当于你家客厅里摆放的相册、信件和账单攻击者要的不是钥匙本身而是照片和文字里藏着的所有信息。1.3 受影响的不只是个人还有大量企业用户个人用户害怕聊天记录泄露企业更害怕。很多公司员工为了方便会直接在对话AI里粘贴Excel表格的脱敏数据、提交工单的截图、甚至是内部Wiki的链接。一旦这些内容被攻击者批量回收轻则违反数据合规条款重则直接造成商业机密外流。在对事件的分析里攻击者并没有针对特定行业而是撒网式地覆盖。从浏览器扩展后台收到的指令看它只关心当前页面URL是否匹配目标AI产品的域名一匹配就启动采集脚本。这意味着只要你的浏览器装了那个恶意扩展任何打开过的对话页面都会被轮询一遍。事件曝光后许多企业的安全团队第一时间做的动作就是全网排查浏览器扩展安装清单也侧面印证了这类攻击在企业场景下的杀伤力。2. 攻击链路一步一步还原从恶意扩展到静默外联2.1 入口被植入的浏览器扩展与常驻后台这次攻击最核心的入口组件是一个伪装成效率工具的浏览器扩展。扩展本身功能是“实用的”比如划词翻译、网页截图、侧边栏笔记所以用户在安装时不会产生警惕。真正的问题出现在扩展的权限声明里它申请了“访问所有网站的数据”和“在后台读取浏览历史”。这里要给不熟悉浏览器扩展机制的朋友解释一下扩展权限不是抽象的它被浏览器映射成具体的API能力。一个扩展如果申请了tabs权限就能读到标签页的URL如果申请了storage权限就能读写本地存储如果申请了webRequest或declarativeNetRequest还能监听和修改网络请求。这些权限单独拿出来都可能被审核通过因为很多正规扩展确实需要它们来实现功能但合在一起就是一张完整的数据窃取通行证。攻击者把扩展上传到应用商店通过刷评价、买推荐位、投放搜索广告等方式让更多人安装。安装量一旦上去恶意版本并不急着立刻偷数据而是先安静运行一段时间等用户把它当成可信组件。部分变种甚至支持动态下发配置攻击者可以在后台切换窃取目标、调整外传频率这让终端侧的静态查杀变得更加困难。2.2 落地在页面会话上下文里翻箱倒柜扩展进入用户的浏览器后攻击脚本开始干活。它先监听标签页更新事件每当用户把标签切到目标AI产品域名脚本就尝试向页面注入内容脚本。这里用的不是漏洞而是浏览器扩展本身具备的合法能力只要扩展权限够大它就能读取页面的DOM结构、调用页面里的全局函数、访问localStorage和sessionStorage。很多对话式AI产品的前端会做状态持久化。为了让你刷新页面后还能看到历史对话它们要么把会话ID存在localStorage要么通过IndexedDB保存消息列表。攻击脚本优先搜的就是这些本地键值。只要找到了会话ID或访问令牌它就可以模拟你的登录态调用产品的前端API把所有历史对话拉一遍。如果本地存储里没有敏感数据脚本还有第二招直接读取当前页面的可见文本。比如对页面主体区域执行document.body.innerText把聊天内容抓下来。因为聊天记录是网页的一部分页面渲染出来就能读这种读取行为几乎不触发任何告警浏览器安全模型默认这是扩展在“正常工作”。2.3 出口拼接、编码、拆包上传数据拿完之后攻击脚本面临一个实际问题怎么把大量文本送出去。一次性打包发送体积太大容易触发网络监控频繁发送又可能被用户察觉浏览器卡顿。比较成熟的做法是分片加混淆。我看到的事件分析里提到攻击者会先把对话数据按条数切片每条消息用Base64或简单XOR编码再插入到正常的HTTP请求头或JSON字段里向一个看起来像数据分析平台的URL发送。这个URL可能属于攻击者控制的第三方站点本身没有恶意软件特征因此企业网关的URL信誉库不容易拦下。还有一类变种更隐蔽数据被拼接成一个图片请求的查询参数服务器端只记录参数不返回真实内容。从流量侧看这只是用户访问了一张普通图片但实际上几KB的对话文本已经跟着URL一起传到了攻击者的服务器上。等到数据积累到一定规模攻击者再通过另外的通道把它们汇集成完整的会话档案。2.4 为什么传统防护在这一链路上效果有限很多公司的终端防护策略还停留在“查杀病毒、拦截钓鱼邮件”的阶段面对这类从浏览器扩展长出来的窃密攻击基本是睁眼瞎。原因有三扩展文件是数字签名的终端杀毒默认信任恶意行为藏在合法API调用里不像传统木马那样有可识别的文件特征。外联流量是加密的HTTPS企业如果没做TLS解密只能看到目标的域名和IP看不到请求里的具体数据很难判断这个请求是否携带了敏感内容。攻击脚本跟用户正常操作共用一个浏览器进程它的“行为”就是读写页面和发请求和真正的用户操作在日志里几乎没有区别。这也解释了为什么事件曝光后很多人回头看自己的浏览器历史、扩展列表才发现异常。不是终端安全防护完全没用而是在这个场景下安全产品需要把监控视角从“文件”上升到“行为”从“单点防护”上升到“会话链路”的分析。3. 实操防护个人端怎么自查企业端怎么长效堵口3.1 个人端四步走先把攻击面收窄面对这类攻击个人能做的事情其实不少核心思路就是让恶意代码进不来、待不住、传不走。第一步做一次浏览器扩展的大扫除。打开扩展管理页逐个检查权限重点看有没有“读取所有网站数据”“访问浏览历史”“修改网络请求”这三类敏感权限。如果某个扩展你很久没用直接移除如果某个扩展功能和你日常需求严重不符比如一个计算器扩展居然申请了所有网站访问权不用怀疑卸载就对了。第二步把工作和娱乐的浏览器环境分开。我自己的做法是日常办公用标准浏览器同时登录AI对话、企业邮箱和OA系统个人娱乐、购物、看视频则用另一个浏览器实例相互不共享Cookie、不共享扩展。这样一来就算娱乐环境里中招了攻击者也够不着你的工作会话。第三步短会话、少留存。很多对话式AI产品支持设置历史记录保留时长能调到7天就别选永久。敏感话题聊完之后顺手清空该会话如果产品提供无痕模式处理机密内容时建议直接开启。这点非常反直觉因为大家习惯让AI记住上下文方便后续继续提问但这等于把所有敏感信息长期存放在一个可被脚本读取的地方。第四步关掉浏览器的自动填充尤其是密码与身份信息的自动填充。虽然这次攻击主要偷对话记录但自动填充功能会放大数据面。一旦攻击者拿到页面输入框的控制权甚至能诱导浏览器自动填出更多凭证类信息损失范围就不可控了。3.2 企业端把AI对话应用当成核心资产来管企业用户不能指望每个人都能自觉做到上面四步所以安全团队需要从机制上补位。第一下发浏览器扩展管控策略。通过组策略或MDM限制员工只能安装企业审核过的扩展。这个策略一定要落在“默认拒绝”的思路上而不是列一个黑名单。黑名单永远追不上供应链上新出现的恶意扩展白名单虽然会牺牲一点便利性但换来的是明确的可控边界。第二启用浏览器隔离或远程浏览方案。把对话式AI这类高风险应用放进云隔离环境里运行员工看到的是渲染后的画面页面真实DOM、Cookie、Session都不落地到本地终端。这样做的好处是即使本地浏览器已经被植入恶意扩展它也拿不到远程隔离环境里的页面内容。第三在出口网关做流量审计。对目标AI产品的域名启用TLS解密和DLP关键字扫描检测外发内容里是否包含“客户名单”“报价单”“源代码”等自定义敏感词。同时建立反常外联基线比如一个终端在固定时间段内突然向某海外域名高频发送大量POST请求即使看不清内容也应该触发行为告警。第四把AI应用的登录会话生命周期调短。会话有效期缩短到半天或一天同时开启异常登录检测。攻击者即使偷到了会话凭证也会因为令牌快速失效或设备指纹不匹配无法顺利完成历史记录的拉取。这个措施在不少云服务上都有原生开关配置成本极低效果却非常直接。3.3 验证防护效果动手做一次模拟攻击安全策略配得再漂亮不验证等于没配。这里给一个可以实际操作的自测方法准备一台测试电脑装上一个申请了敏感权限的测试扩展自己写的或开源项目然后在浏览器里登录对话AI故意制造几条带“秘密标记”的对话内容。打开扩展后台的开发者工具观察它是否能在不操作页面的情况下读取到这些标记文本。接下来在公司出口网关上跑一遍流量分析。看测试扩展把数据外传时DLP能不能识别关键字并阻断行为模型能不能产生偏离告警。如果模拟数据顺利到达了外部队列说明防护策略中间某个环节还是断的必须继续补。我建议每季度做一次这样的自测因为浏览器扩展的审核机制和攻击者的免杀手法都在变半年不更新策略之前稳定的防线就可能有缺口。4. 常见问题与排查实录告警来了怎么判断、日志怎么查4.1 扩展的权限列表看起来“正常”为什么依然危险这是我在交流群里最常看到的问题。有人拿出一款大厂出品的PDF阅读扩展权限写着“读取浏览历史”功能是方便你从历史记录直接打开PDF。看起来有道理但安全隐患没有消失权限一旦授权扩展开发者随时可以更新后台脚本把历史记录里的URL、标题全部采集走。判断一个扩展是否危险不要看它的功能说明有多合理要看权限实际能触达哪些数据面。合理判断标准很简单权限范围是否小于等于实现功能所需的最小集。一个PDF阅读器需要“读取浏览历史”吗不需要。一个翻译扩展需要“读取所有网站数据”吗如果需要划词翻译那确实要但应该把权限限定在用户点击划词时才生效的后台注入模式而不是持续性的全局读取。如果一款扩展的权限明显超标同时又关闭了开发者选项、不支持离线安装包检查那建议直接拉进黑名单。别贪图功能而留下后门。4.2 告警风暴里怎么快速分辨哪条才是真的攻击行为企业里每天有大量外联告警多数是误报。真正需要重点跟进的是三类特征目标域名注册时间很短且访问频率和用户操作节奏不匹配。请求携带的参数异常比如长度超常的text参数、Base64编码串、时间戳同段内重复出现相同结构。发起请求的主体不是页面本身而是扩展后台脚本。这个特征可以从浏览器的chrome://extensions里开开发者模式查看或者从EDR的进程网络连接详情里比对发起进程的所属组件。实际排查时我一般先把告警按“是否来自浏览器扩展进程”过滤一遍再对剩余样本做外联浓度排序。这个顺序能快速滤掉八成噪音把有限的人力集中在真正可疑的路径上。4.3 日志应该查哪里时间线怎么还原当终端或网关报出可疑事件别急着封IP。先按以下顺序固定证据浏览器扩展列表导出所有扩展ID、版本号、安装时间、生效的权限。Windows下可在HKEY_LOCAL_MACHINE\SOFTWARE\Google\Chrome\Extensions及用户目录的Preferences文件里找到扩展元数据。浏览器事件日志Chrome的chrome://system和各类ISO文件里的扩展崩溃转储可以帮判断恶意脚本的加载时间。企业网关和EDR把可疑扩展外联的时间段与目标AI产品的页面打开时间做重合度比对。如果外联频率和用户操作完全无关而是保持固定间隔基本可以认定是后台定时任务。静态分析把扩展的CRX文件解包提取后台脚本搜索关键字如fetch、sendBeacon、WebSocket、XMLHttpRequest就能看到数据外传的代码路径。时间线还原的核心是找出三个结点恶意代码首次出现的时间、首次窃取数据的时间、数据开始外传的时间。通常这三个时间点不可能完全重合首现和首窃之间有一段潜伏期首窃和首传之间也可能有延时。把这三个结点连起来就能判断攻击批次和影响范围汇报时也能给管理层一个明确的止损依据。5. 给AI应用开发团队和所有使用者的一点个人经验5.1 服务端能做哪些补偿性控制AI产品开放了很多前端能力但服务端其实是能防的。开发团队可以在三个层面做补偿性控制会话绑定给访问令牌绑定设备指纹和IP段当同一账号在短时间内从陌生设备或异常地区登录时强制要求重新认证而不是直接放行历史会话接口。接口频率治理对历史会话拉取接口做速率限制单账号单小时最多允许调用N次超过即触发验证码或临时封禁。这个策略对正常用户无感但能有效卡住批量脚本的翻本速度。敏感内容加密对包含高敏感关键词的会话在前端以密文形式存储或干脆不留存。这一点很多产品因为担心影响检索功能而不敢做但对企业版用户来说安全价值远大于便利性。开发团队在自查时可以模拟攻击者写一个浏览器小脚本尝试用偷到的令牌循环调用历史会话接口看服务端能否识别出这种非交互式的数据拉取模式。这比在客户端做再多拦截都更接近风险源头。5.2 我在实际测试中踩过的坑最后分享几个我在复现这类攻击和配置防护时实际遇到的问题。第一次做扩展权限审查时我被“最小权限”这四个字带偏了把所有扩展的敏感权限一刀切禁掉结果业务部门大量反馈“页面翻译功能没了”“截图工具不能用了”最后不得不紧急放行。后来学乖了权限审查不是一刀切而是先按用户角色分类给普通员工和研发人员各配一套扩展白名单再逐步收紧。有些扩展确实需要高权限只要来源可追溯、版本受控是可以保留的。还有一次网关侧上了DLP告警但关键字规则写得过于粗糙把“合同”和“报价”都设成敏感词结果员工正常和AI讨论一份合同模板也触发了高频警报。安全团队和业务部门为此开了两次沟通会。后来把规则改成“包含客户编号合同金额范围特定抬头”的组合条件告警准确率才升上来。这给我的体会是针对AI对话场景的安全防护不能只看单点工具还是要回到数据和身份两条主线上来。数据要能识别、能标记、能管控流向身份要能绑定设备、能感知异常、能及时失效。零点击攻击只是提醒我们浏览器这个入口远比想象中开放。大家手里的对话AI用得很顺手但顺手的前提是数据的安全边界还没有被悄悄突破。