网页聊天机器人插件：不安全的小部件如何放大提示注入

这是什么？

提示注入研究大多瞄准前沿助手——副驾驶、编码代理、RAG 流水线。但网络上最常见的 LLM 应用要简单得多：电商或 SaaS 网站角落里的客服聊天气泡。一篇题为 《When AI Meets the Web: Prompt Injection Risks in Third-Party AI Chatbot Plugins》 的论文于 2025 年 11 月 8 日提交至 arXiv，并被 IEEE S&P 2026 录用，它是对这一攻击面的首次大规模研究。论文由加州大学圣巴巴拉分校（UC Santa Barbara）的 Yigitcan Kaya、Anton Landerer、Stijn Pletinckx、Michelle Zimmermann、Christopher Kruegel 和 Giovanni Vigna 撰写，研究了部署在 1 万多个公开网站上的 17 款第三方聊天机器人插件，并表明出问题的是 LLM 周围的管道，而非模型本身。

工作原理

这些插件充当非专业建站者与商用 LLM API 之间的中介。研究记录了两处结构性弱点。

第一是对话历史完整性。在正常对话中，每次向 LLM 发出的请求都会重新发送先前的回合以提供上下文。研究者发现，8 款插件（用于约 8000 个被研究的网站）信任浏览器发送的对话历史，却未在服务器端进行校验。控制自己会话的攻击者可以在该负载离开浏览器前进行编辑——伪造助手早先的回复，甚至伪造模型视为权威的虚假系统消息。借助一段声称助手已同意放弃规则的伪造历史，直接注入会变得有效得多：论文测得诱导非预期行为（如代码生成）的成功率提升了 3 至 8 倍。

第二是不可信内容混入。17 款插件中有 15 款提供工具——尤其是网页抓取——用网站内容丰富聊天机器人的上下文。但它们并不区分站长可控的可信内容（商品描述、政策）与不可信的第三方内容（客户评价、问答、评论）。所有被抓取的内容都以同等权威进入提示，这正是间接提示注入的典型场景：一条恶意评价可携带聊天机器人随后执行的指令。作者发现，被研究的电商网站中约有 13% 已将其聊天机器人接入第三方内容，在攻击者出现之前就暴露了这一攻击面。

为何重要

核心结论是：LLM 的安全护栏经不起糟糕的集成。底层商用模型自带对齐与拒答训练，但不安全的插件却把杠杆——伪造的历史、未分隔的上下文——交到攻击者手中，绕过这些防御。由于同样的少数几款插件在数千个网站上被复用，单一的不安全模式就会扩散成一长串脆弱部署，而经手的站长一行集成代码都没写过。这是不起眼的市场中段：不是旗舰代理，却是普通用户真正接触的聊天机器人。

防御措施

在服务器端强制对话历史完整性。 绝不信任从客户端回传的消息历史（尤其是系统或助手角色）。在服务器端重建或验证会话，签名或存储规范的对话记录，并直接拒绝客户端提供的系统消息。仅此一项控制即可消除论文测得的 3 至 8 倍放大效应。

在提示中分离可信与不可信内容。 将抓取的评价、评论及任何第三方文本视为数据，而非指令。用清晰的分隔符将其围栏化，标注其来源，并在插件允许时，在其抵达模型前应用聚光（spotlighting）或输入过滤。站长可控内容与访客可控内容不得共享同一权威级别。这与 OWASP LLM01：提示注入 的建议直接对应。

收窄影响范围。 只赋予聊天机器人完成支持所需的最小能力：不需要的工具调用、代码执行或敏感数据访问一律不给。对高风险输出（代码、链接、命令）增加输出过滤，并监控异常的工具调用，而非依赖模型自行拒绝。

若你运营装有此类小部件的网站， 请核查聊天机器人是否抓取用户生成内容，并询问插件供应商如何校验对话历史。修复点在集成层——恰恰是大多数站长想当然以为供应商已搞定的地方。

状态

项目	详情
来源	arXiv:2511.05797，《When AI Meets the Web》，提交于 2025-11-08；收录于 IEEE S&P 2026
范围	17 款第三方聊天机器人插件，覆盖 1 万多个公开网站
发现 1	8 款插件（约 8000 个网站）缺乏历史完整性 → 直接注入效果增强 3 至 8 倍
发现 2	15 款插件通过工具混入可信/不可信内容 → 间接注入；约 13% 电商网站已暴露
根因	不安全的集成实践，而非底层 LLM
行动	服务器端历史完整性；可信/不可信内容分离；最小能力聊天机器人