企业官网建设流程全解析

这两天安全圈讨论度最高的话题，就是某头部安全厂商披露的一组零点击数据窃取攻击分析。攻击目标不是某个偏门系统，而是大家几乎每天都在用的对话式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。先按以下顺序固定证据：

1. 浏览器扩展列表：导出所有扩展ID、版本号、安装时间、生效的权限。Windows下可在HKEY_LOCAL_MACHINE\SOFTWARE\Google\Chrome\Extensions及用户目录的Preferences文件里找到扩展元数据。
2. 浏览器事件日志：Chrome的chrome://system和各类ISO文件里的扩展崩溃转储，可以帮判断恶意脚本的加载时间。
3. 企业网关和EDR：把可疑扩展外联的时间段与目标AI产品的页面打开时间做重合度比对。如果外联频率和用户操作完全无关，而是保持固定间隔，基本可以认定是后台定时任务。
4. 静态分析：把扩展的CRX文件解包，提取后台脚本，搜索关键字如fetch、sendBeacon、WebSocket、XMLHttpRequest，就能看到数据外传的代码路径。

时间线还原的核心是找出三个结点：恶意代码首次出现的时间、首次窃取数据的时间、数据开始外传的时间。通常这三个时间点不可能完全重合，首现和首窃之间有一段潜伏期，首窃和首传之间也可能有延时。把这三个结点连起来，就能判断攻击批次和影响范围，汇报时也能给管理层一个明确的止损依据。

5. 给AI应用开发团队和所有使用者的一点个人经验

5.1 服务端能做哪些补偿性控制

AI产品开放了很多前端能力，但服务端其实是能防的。开发团队可以在三个层面做补偿性控制：

• 会话绑定：给访问令牌绑定设备指纹和IP段，当同一账号在短时间内从陌生设备或异常地区登录时，强制要求重新认证，而不是直接放行历史会话接口。
• 接口频率治理：对历史会话拉取接口做速率限制，单账号单小时最多允许调用N次，超过即触发验证码或临时封禁。这个策略对正常用户无感，但能有效卡住批量脚本的翻本速度。
• 敏感内容加密：对包含高敏感关键词的会话，在前端以密文形式存储或干脆不留存。这一点很多产品因为担心影响检索功能而不敢做，但对企业版用户来说，安全价值远大于便利性。

开发团队在自查时，可以模拟攻击者写一个浏览器小脚本，尝试用偷到的令牌循环调用历史会话接口，看服务端能否识别出这种非交互式的数据拉取模式。这比在客户端做再多拦截都更接近风险源头。

5.2 我在实际测试中踩过的坑

最后分享几个我在复现这类攻击和配置防护时实际遇到的问题。

第一次做扩展权限审查时，我被“最小权限”这四个字带偏了，把所有扩展的敏感权限一刀切禁掉，结果业务部门大量反馈“页面翻译功能没了”“截图工具不能用了”，最后不得不紧急放行。后来学乖了：权限审查不是一刀切，而是先按用户角色分类，给普通员工和研发人员各配一套扩展白名单，再逐步收紧。有些扩展确实需要高权限，只要来源可追溯、版本受控，是可以保留的。

还有一次，网关侧上了DLP告警，但关键字规则写得过于粗糙，把“合同”和“报价”都设成敏感词，结果员工正常和AI讨论一份合同模板也触发了高频警报。安全团队和业务部门为此开了两次沟通会。后来把规则改成“包含客户编号+合同金额范围+特定抬头”的组合条件，告警准确率才升上来。

这给我的体会是：针对AI对话场景的安全防护，不能只看单点工具，还是要回到数据和身份两条主线上来。数据要能识别、能标记、能管控流向；身份要能绑定设备、能感知异常、能及时失效。零点击攻击只是提醒我们，浏览器这个入口远比想象中开放。大家手里的对话AI用得很顺手，但顺手的前提，是数据的安全边界还没有被悄悄突破。