安全研究人员在欧洲之星（Eurostar）的公开 AI 聊天机器人中发现了四个主要安全漏洞。通过绕过其薄弱的服务器端验证，攻击者可以篡改对话历史，注入恶意指令，从而泄露系统提示并执行跨站脚本攻击（XSS）。尽管存在漏洞披露计划，但研究人员的报告过程异常艰难，甚至一度被误解为勒索。此事件明确表明，在应用大型语言模型（LLM）时，绝不能忽视传统的网络和 API 安全基础，严格的输入输出验证和持续监控依然至关重要。
工作原理与设计缺陷
该聊天机器人通过一个 API 运行，每次用户发送消息时，前端会将整个对话历史（chat_history）提交给服务器。服务器端设有一个“守卫”（guardrail）机制，用于检查最新的用户消息是否合规。
- 守卫检查： 如果最新消息通过检查，其状态被标记为
PASSED并获得一个签名。如果失败，服务器则返回一条固定的拒绝信息。 - 固定的拒绝信息： 每次被拒绝时，聊天机器人都会返回完全相同的文本：“I apologise, but I can't assist with that specific request.”
这种僵硬、从不变化的回答强烈暗示着，这不是模型本身在做决定，而是一个在模型之前的程序化守卫层在拦截请求。一个真正的大语言模型在拒绝时，措辞通常会略有不同。
核心设计缺陷在于，服务器只验证对话历史中最新一条消息的签名。旧消息虽然也包含在发送的请求中，但服务器不会重新验证它们。只要最新消息是无害的并通过了守卫检查，攻击者就可以在客户端修改任何先前的消息，而这些被篡改的内容会被直接送入模型，作为可信的上下文。
发现的四个安全问题
通过修改发送到 API 的请求，研究人员发现了四个不同的安全问题。虽然在当时聊天机器人的功能有限，这些漏洞并未造成严重后果，但随着功能扩展，它们可能导致个人数据或其他敏感信息泄露。
- 守卫机制可被绕过
- 通过提示注入泄露信息
- 因缺乏输入验证导致 HTML 注入/自我 XSS
- 对话和消息 ID 未经验证
1. 守卫绕过与提示注入
攻击者可以利用上述设计缺陷轻松绕过守卫。方法是：将对话历史中的最新一条消息设置成完全无害的内容（甚至空字符串）以通过检查，同时修改历史记录中较早的一条消息，植入真正的恶意指令。
通过这种方式，研究人员成功绕过了守卫，并使用提示注入（Prompt Injection）技术，诱导模型泄露其不应披露的信息，例如底层的模型名称和完整的系统提示（System Prompt）。系统提示揭示了聊天机器人的内部工作指令，包括它如何生成包含 HTML 标签的参考链接。
2. HTML 注入与自我跨站脚本攻击 (Self-XSS)
系统提示指示模型在回答中可以包含 HTML 链接，而这些 HTML 代码会直接在用户的聊天窗口中渲染，并未经过充分的清理。
由于攻击者已经能够通过提示注入来控制模型的输出，他们可以诱导聊天机器人返回任意的 HTML 代码，而不仅仅是合规的帮助链接。在测试中，这被用来执行简单的脚本，例如在浏览器控制台中打印日志。
在真实攻击中，同样的手法可用于在看似合法的欧洲之星答复中，嵌入恶意的 JavaScript 或网络钓鱼链接。
这在当时构成了“自我 XSS”，即攻击代码只在攻击者自己的浏览器中运行。但结合其他漏洞，它有升级为更严重攻击的潜力。
3. 未经验证的对话与消息 ID
系统为每个对话和消息都生成了唯一的 ID，但服务器端并未严格验证这些 ID 的所有权或格式。攻击者可以将自己的对话 ID 修改为 “1” 或 “hello” 之类的简单值，而后端依然会接受并继续对话。
这个缺陷本身没有被用于跨用户攻击（因为这超出了漏洞披露计划的范围），但它揭示了一个清晰的风险路径：
- 一个攻击者可以在自己的对话中注入恶意脚本（XSS 载荷）。
- 然后，他们可以尝试在另一个用户的会话中重用该对话 ID。
- 如果成功，当受害者的聊天历史被加载时，恶意的脚本就可能被执行。
艰难的漏洞报告过程
尽管欧洲之星设有官方的漏洞披露计划（VDP），但报告过程却充满障碍。
- 研究人员通过官方邮箱首次提交报告后，石沉大海。
- 一周后再次跟进，仍无回应。
- 近一个月后，研究人员通过 LinkedIn 联系了欧洲之星的安全主管，却被告知应使用他们已经用过的 VDP 渠道。
- 后续沟通发现，欧洲之星在此期间外包了他们的 VDP，并更换了披露页面，导致最初的报告“丢失”了。
在来回沟通的过程中，对方甚至暗示研究人员的行为是在试图敲诈勒索。这让善意披露漏洞的研究人员感到非常惊讶和困惑。
最终，漏洞得到了修复，但整个过程缺乏透明度，研究人员不清楚修复的具体细节和范围。
建议与启示
修复这类漏洞的方法并不新奇，它们大多是任何网络或 API 应用都应遵循的基本安全准则。
- 将系统提示视为安全控件： 明确定义模型的角色和权限边界，将用户输入与系统指令严格分开。
- 验证所有输入和输出： 像对待任何其他 API 一样，对所有进入模型的数据（用户文本、ID、外部内容）进行验证和清理。绝不直接渲染模型的输出为 HTML，应默认视为纯文本处理。
- 强化服务器端验证： 守卫的决策和执行必须完全在服务器端进行。应将守卫结果、消息内容、消息 ID 和会话 ID 绑定在一起进行签名验证，并拒绝任何篡改或重放历史记录的尝试。
- 建立监控和响应机制： 记录所有与 LLM 的交互，设置异常行为（如守卫连续失败、可疑的注入尝试）的警报，并准备好紧急关闭开关。
最终的教训很简单：引入 AI 技术并不能成为忽视网络和 API 安全基础的借口。只有将这些基本原则贯彻始终，才能在利用 AI 优势的同时有效管理其风险。