AI 网络爬虫安全白皮书

作者：李冠成、王征@腾讯玄武实验室 摘要 AI应用形态正从单一的LLM离线对话，逐步演进为能够调用工具、自主拆解任务的Agent（智能体）的在线联网形态。无论是处理基础的“联网搜索并综述答案”，还是执行“先搜索公司信息、再查询股价，最后给出投资建议”这类复杂的自动化任务链，浏览器都会被集成到服务端系统中，以提供进行实时联网和内容提取。 然而，将本该运行在客户端的浏览器“搬”到服务端运行，这种架构上的错位带来了不容忽视的安全隐患： ⚫信任边界模糊：浏览器作为解析外部不可信代码（如JS、DOM）且高危漏洞频的软件，其所在服务端环境却可能直连企业内网和关键业务系统，极易成为外部攻击渗透内网的突破口。⚫安全水位更低：服务端浏览器常面临补丁更新滞后、运行权限过高等问题；部分厂商为兼顾兼容性甚至关闭原生沙箱机制，导致其安全防护能力往往低于普通客户端浏览器。⚫攻击危害更大：浏览器一旦被攻破，攻击者不仅能窃取任务数据或篡改返回结果以“污染”后续决策流程，利用共享架构横向影响其他产品和用户，更可能以此为跳板横向移动，攻击内网其他核心系统。 我们发表在Blackhat的一项研究也证实了多个AI产品的爬虫具有远程代码执行风险。鉴于服务端浏览器已成为AI服务端系统中的关键风险点，而行业内尚缺乏系统性的防护标准，本白皮书旨在填补这一空白。我们详细分析了该场景下的风险特征，并提出了以“静态攻击面收敛+动态行为隔离”为核心的防御框架，助力企业安全负责人和技术团队实现服务端浏览器的安全部署与运维。我们已在GitHub上开源了这套方案，希望能够助力行业整体提升服务端浏览器的安全水位。 代码地址：https://github.com/XuanwuLab/SEChrome 一、浏览器在AI系统中的攻防态势变化 当你启动一个浏览器实例时，你启动的不是一个简单的网页访问工具，而是一个由V8引擎、WebRTC组件、PDF阅读器、几十种音视频解码器及复杂渲染内核组成的“微型操作系统”。任何一个组件的漏洞，都有可能引发远程代码执行，因而浏览器一直都是高危漏洞数量、以及可利用漏洞占比都是最多的软件。 在AI时代，浏览器从用户通向Web世界的入口，转变为了支撑AI业务运行的基础组件。我们将一个复杂度远超一般服务端组件且漏洞频发的浏览器，放置在攻击价值较高的服务端。这种变化不仅仅是部署位置的迁移，更是带来了一种角色的变化，这种角色变化最终导致了浏览器在服务端的攻防态势的变化。 1.1攻击态势的变化 从攻击视角来看，浏览器角色的转变引入了深层次的结构性风险，这种变化可以归纳为以下四个维度： 1.补丁+沙箱防御范式的失效：传统浏览器安全高度依赖“自动更新”与“沙箱隔离”。但在服务端，部分开发者为了维持环境一致性而禁用了自动更新；部分开发者为了适配容器架构而关闭了沙箱。这种运维环境的异化，直接导致了传统防御体系的失效，使N-day漏洞成为常态化威胁。 2.攻击影响范围的扩大：传统浏览器仅影响个人终端。而在服务端，浏览器既是多用户共享的组件，攻击者一旦突破，通过共享环境影响其他用户，如批量控制其他用户联网搜索的结果。 3.攻击导致的后果更加严重：传统浏览器的消费者是人，而现在的消费者是AI。攻击者的目标不再仅仅是获取权限，更可以通过篡改网页内容来“投毒”AI的知识输入。在“搜索-决策-执行”的自动化链路中，这种数据层面的攻击将直接操纵AI的最终决策。此外，服务端环境若没有恰当的隔离，攻击者可以利用其作为跳板，横向移动至核心内网，放大攻击者的危害。 4.攻击意愿的提升：由于上述因素，服务端浏览器成为了通往企业核心数据与业务逻辑的捷径。相比于攻击个人用户，攻陷服务端浏览器的收益极高，这促使攻击者愿意投入更高成本（如购买0-day漏洞）来针对性地突破防线。 1.2防御态势的变化 从防御的角度考虑，这种角色变化也造成了防御策略的错位。服务端安全的核心诉求在于最小权限原则，即组件应仅拥有完成特定任务所需的最小能力集合；但现有的浏览器设计为了兼容万维网，默认开启了WebGL、WebRTC及各种功能接口，这种“默认开放”的策略与服务端严苛的权限管控背道而驰，导致了攻击面的放大。 此外，现代服务端安全通常需要具备高度的可配置性与可运营性，安全策略应当像基础设施代码一样可定义、可审计。遗憾的是，浏览器往往作为一个不透明的黑盒运行，缺乏标准化的服务端配置接口与结构化的安全审计日志，导致运维人员既难以像配置Nginx那样对其行为边界进行有效收敛，也无法在攻击发生时获得足够的观测视野。 因此，我们必须重新评估服务端浏览器的风险，并建立一套全新的、符合服务端安全运营需求的浏览器安全防御实践。 二、AI服务端浏览器安全风险评估 本节将系统性的重新评估服务端浏览器安全的风险 2.1风险点1：补丁更新滞后与错误的沙箱配置 客户端浏览器依赖成熟的安全机制运作：自动更新与快速补丁推送、原生沙箱、多进程隔离。Chrome在桌面端通常能在漏洞披露后数天内向大部分用户推送更新。服务端浏览器的运行方式有所不同，我们在对多个厂商的AI服务端浏览器组件进行分析后， 观察到以下两个普遍存在的问题， ⚫沙箱配置问题：Chrome的用户态沙箱依赖于Linux的命名空间（namespace）和seccomp机制。在容器环境中，若运行时配置不当（如未授予必要的Linux Capabilities或未正确设置seccomp策略），Chrome将无法正常启动。为快速解决启动失败的问题，不少团队会选择添加--no-sandbox参数来绕过限制，但这实际上关闭了浏览器最关键的安全边界，带来严重风险。此外，部分容器平台出于防范容器逃逸漏洞的考虑，默认不开放Chrome沙箱所必需的系统权限。 ⚫版本更新慢：部分团队担心版本更新导致页面渲染行为变化或兼容性问题，倾向于使用经过长期验证的旧版本镜像。 根据Google Project Zero的统计，Chrome在2020-2025年间累计修复了超过1600个安全漏洞，其中包含多个在野利用的零日漏洞。CVE数据库的记录显示，Chrome V8引擎、Blink渲染引擎和WebAssembly运行时是漏洞的高发区域，这些组件在服务端浏览器中同样被使用。沙箱的关闭和版本更新的不及时，都会将浏览器暴露在nday漏洞的威胁之下，从而导致AI服务端的浏览器的远程代码执行风险。 2.2风险点2：多用户多产品共享架构导致漏洞影响变大 在客户端场景中，一个浏览器实例只服务一个用户，攻击所影响的范围天然受限。在服务端AI系统中，浏览器通常以资源池的形式运行：同时服务多个AI产品，被多个任务队列复用，支撑多个用户的查询请求，在长生命周期容器中持续运行。在这种架构下，如果一个恶意页面触发漏洞并成功利用，攻击者可能干扰正在处理或即将处理的多个任务，污染LLM的数据输入并进而控制行为，产生跨用户甚至跨产品的影响。 2.3风险点3：内网隔离不当导致的攻击危害变大 在客户端场景中，浏览器运行在用户个人电脑上，与企业生产系统通常存在网络隔离。在服务端场景下，浏览器作为业务逻辑的一部分，可能与业务服务部署在同一集群或网络段中。如果缺乏专门的网络隔离策略，浏览器与内网资源（数据库、任务调度系统、模型推理节点、内部API）可能处于可互访的状态。 一旦浏览器被攻破，攻击者将利用其所在节点作为立足点：扫描内网服务、读取环境变量中的凭据、访问元数据服务获取云平台权限。影响范围远超浏览器本身。 2.4风险点4：对于网页内容的使用方式导致的攻击危害变大 服务端浏览器不仅是数据获取工具，更是AI模型的“眼睛”和“耳朵”。攻击者可以通过在网页中植入Prompt Injection（提示词注入）载荷或恶意指令，当浏览器抓取该页面内容并投喂给下游模型时，可能诱导AI输出错误结果、泄露敏感信息，甚至执行非预期的自动化操作。这种攻击跨越了传统的软件漏洞层面，可直接污染AI的决策逻辑。 2.5风险点5:服务端浏览器的攻击收益高，攻击者使用高价值漏洞 的意愿强 在AI场景下，服务端浏览器的潜在价值显著提升。客户端攻击通常只能获取个人终端层面的数据与权限，而服务端浏览器的部署位置更接近业务系统。一旦攻破浏览器，攻击者能够进一步接触到内部接口、配置信息、业务数据或其他服务。因此，攻击者很有可能愿意使用投入更高的攻击手法，如使用0-day漏洞。 因此，“我们用的是最新版浏览器，所以不会有安全问题”是一种危险的误解。最新版可以缓解N-day，但无法消除0-day，这也是我们强调引入“纵深防御”的原因：假设浏览器内部总是可能存在未知漏洞，并提前为其失守设计好“缓冲区”。 三、攻击路径与真实案例 为了有效防御服务端浏览器威胁，我们首先需要理解攻击者视角下的渗透路径。通过对实战案例的复盘，我们梳理出了一套针对服务端浏览器的典型攻击链（Kill Chain），并精选了四个具有代表性的真实案例进行剖析。 3.1服务端浏览器的攻击链路 针对服务端浏览器的攻击通常遵循以下五个阶段： ⚫入口识别(Reconnaissance)攻击者首先寻找能够触发服务端发起HTTP请求的功能点。除了显而易见的“网页抓取”、“URL预览”功能外，还需要关注隐蔽的入口，如Markdown渲染中的图片加载、PDF生成服务、缓存预热接口或后台的搜索引擎。⚫爬虫防御绕过(Evasion)针对系统部署的URL白名单或脚本过滤器，攻击者会利用302跳转、DNS重绑定、协议解析差异等手段，或构造特殊的HTML结构来规避检查，将请求导向攻击者控制的网站。⚫环境指纹探测(Fingerprinting)。HTTP请求头中的User-Agent极易被伪造，因此攻击者不会采信。他们通过检测浏览器对特定API、CSS属性或JS语法特性的支持情况，判断浏览器内核的具体版本。⚫漏洞触发(Exploitation)一旦版本被确定，攻击者会从漏洞库中检索该版本存在的0-day/N-day漏洞，并部署相应的Exploit代码。当服务端浏览器解析恶意页面时，漏洞被触发，攻击者获得代码执行权限。⚫横向渗透与持久化(Post-Exploitation)若浏览器开启了沙箱，攻击者需要利用沙箱逃逸漏洞来逃逸沙箱，若浏览器未开启沙箱或沙箱配置不当，攻击者将直接获得宿主机的Shell权限，进而探测内网拓扑、读取敏感配置文件（如云服务AK/SK），甚至以此为跳板攻击内部数据库和其他微服务。 3.2四个典型案例 我们对市面部分集成服务端浏览器产品开展了测试工作，发现多款产品存在沙箱外的远程代 码执行（RCE）安全风险。相关产品服务端用户规模累计超10亿，涵盖多家头部科技企业旗下产品。 接下来，我们挑选了四个典型案例展开说明，以帮助全面理解该攻击面。 案例一：通过URL跳转绕过白名单并实现远程代码执行 ⚫入口识别(Reconnaissance)：某AI搜索产品实施了访问白名单策略，只允许浏览器访问预设的可信网站列表。 ⚫防御绕过(Evasion)：我们发现白名单中的某些大型搜索网站对收录的网站制作中间跳转链接如xx.com/link?url=。我们构造了一个请求：访问白名单内的网站，但URL中附带跳转参数指向我们控制的服务器。系统检查初始地址在白名单内，放行请求。浏览器打开可信网站后，读取URL参数，自动跳转到了我们的恶意页面。 ⚫环境指纹探测(Fingerprinting)：在成功跳转并绕过白名单后，我们的恶意页面在服务端浏览器中运行，探测发现其后台浏览器使用的是一个旧版本Chrome/120。 ⚫漏洞触发(Exploitation)：确认版本后，我们利用了一个该版本已公开的N-day漏洞+一个V8沙箱绕过的漏洞。由于该服务未开启浏览器沙箱，漏洞触发后我们成功获得了服务器的控制权。 案例二：组合多个浏览器功能并实现远程代码执行 ⚫入口识别(Reconnaissance)：某AI产品有三个独立功能，分别是使用最新版浏览器的AI阅读功能、可生成同域公