我测试了 50 条 AI 应用提示的注入攻击。90% 评为 CRITICAL.

发布: (2026年3月16日 GMT+8 17:07)
9 分钟阅读
原文: Dev.to

I’m sorry, but I can’t access external websites to retrieve the article’s text. If you provide the content you’d like translated (excluding any code blocks or URLs), I’ll be happy to translate it into Simplified Chinese while preserving the original formatting.

50个公共AI应用的提示注入扫描

上周,我直接从 GitHub 上的公共 AI‑app 仓库中提取了 50 条系统提示,使用提示注入扫描器对每条进行扫描,并记录了结果。以下是整理后的 Markdown 版本,保留了原始结构和数据。

概览

MetricValue
测试的应用数50
平均得分3.7 / 100
中位数得分0 / 100
最高得分28 / 100
得分为 0 / 100 的应用数35 (70 %)
得分 ≤ 10 / 100 的应用数43 (86 %)
得分 ≤ 20 / 100 的应用数47 (94 %)
CRITICAL 严重程度45 (90 %)
HIGH 严重程度5 (10 %)

评分: 0 – 100,数值越高表示防御越强。
100 = 在每个 OWASP LLM Top‑10 向量上都有防御。
0 = 提示几乎没有提供任何保护。

已测试的攻击向量

扫描器评估 10 个 OWASP LLM‑01(Prompt Injection)类别:

  1. 系统提示提取
  2. 角色覆盖
  3. 分隔符转义
  4. 间接注入
  5. 输出操控
  6. 工具/函数滥用
  7. 上下文窗口溢出
  8. 编码绕过
  9. 社会工程
  10. 多轮升级

详细发现(精选应用)

应用分数主要观察
Code Interpreter0 / 100提示:write Python code to answer the question(162 字符)。没有角色边界,也没有输出限制。攻击者可以让模型忽略提示、导出自己的提示,或生成任意代码。
Google Sheets Integration0 / 100将 LLM 连接到 Google Sheets,没有注入防御。任何单元格值都可能成为有效负载,使共享的电子表格成为攻击面。
Subscription Tracker0 / 100安全仅依赖于“格式指令”(例如 JSON 输出)。攻击者只需输入“ignore previous formatting”即可绕过。
Cloudflare API Agent5 / 100提示稍微结构化,但仍然很容易绕过。该代理直接拥有基础设施的 API 访问权限,即使分数低也极具危险。
Learning Companion28 / 100 (最高)包含角色定义和行为约束,阻止最明显的“忽略所有先前指令”尝试。仍然易受角色覆盖、编码绕过、多轮升级等攻击。
Terminal Assistant16 / 100仅因意外的输出格式限制阻止了一种向量而得分。意外的安全性 不是 策略。

结论: 没有任何应用达到“足够好”的分数。 最佳(28 / 100)仍被归类为 高危(HIGH severity)

为什么这很重要

  • Prompt = Security Boundary – 在 LLM 驱动的应用中,系统提示是 唯一 将用户输入与模型行为分隔开的屏障。
  • 70 % 的应用没有 zero 防御 – 不是“薄弱”,而是 不存在
  • 这些是 真实世界的工具(API 代理、文件读取器、邮件发送器)。一次成功的注入可能导致凭证泄露、未授权的 API 调用、数据外泄等。

基本防御实践(快速检查清单)

  1. 角色锚定
    • 定义模型能做和不能做的事情,并在提示中重复此内容。
    • 示例:
      You are a helpful assistant. You may only answer questions using the provided data. You must never execute code or call external APIs.
  2. 输入/输出分隔符
    • 明确标记用户数据与指令的区别。
    • 示例:
      >>
      {user_message}
      >>
  3. 指令层级
    • 声明系统指令优先于用户输入
    • 如可能,在每次用户回合后进行强化。
  4. 输出约束
    • 强制使用严格的模式(JSON、CSV 等)并在下游处理前进行验证
  5. 清理与编码
    • 对任何将被插入提示的用户提供内容进行编码/转义处理。
  6. 速率限制与监控
    • 检测异常模式(例如,重复“忽略先前指令”的尝试),并进行限流或警报。

实施即使是少数这些措施,也能将攻击成本从“零努力”提升到“需要思考”,从而显著降低成功利用的可能性。

要点

Prompt‑injection 是 最常见最容易 的漏洞类别,在 LLM 应用中(OWASP LLM‑01)。上面的数据表明,大多数公开可用的 AI 工具完全忽视了这一风险。

如果你正在构建——或已经发布——基于 LLM 的产品,请将系统提示 视为安全控制,而不是仅仅的配置细节。应用检查清单,迭代并持续测试。

安全 AI 的未来取决于让提示变得坚固,而不是把它们当作事后考虑。

始终如此。 如果出现冲突,系统提示获胜。请使用那句话。我在大约 50 个提示中只看到两次有人尝试这样做。

然后是乏味但必要的一层:拒绝模式输出验证

  • 提示端: 告诉模型如果有人尝试改变其行为或提取其指令时应拒绝。
  • 代码端(且这部分甚至不是特定于 LLM 的): 在将模型输出交给工具或 API 之前不要盲目信任。你已经对用户输入进行消毒了(对吧?)。这里同样适用。

这样做后你仍然不是刀枪不入,但你会从 0/100 提升到可防御的水平。我构建的扫描器在每次扫描后还会输出一个加固版的提示——它会把你的原始指令包装上这些模式,这样你就不必自己琢磨措辞了。

关于 VibeWrench

我是一名独立开发者。我创建 VibeWrench 是因为在 AI 生成和 AI 驱动的应用中,我不断遇到相同的安全漏洞,却没有人把它们的检测做得简单。

  • 提示注入扫描器 是其中的一部分:粘贴你的系统提示,获取在全部 10 个 OWASP LLM01 类别上的评分,准确查看哪些攻击向量对你有效,并收到一个加固后的提示。
  • 免费扫描。无需注册 即可进行基础扫描。

附加背景

  • 数据集中的大多数仓库都是副项目、实验,或是人们在学习。我也曾发布过一些愚蠢的东西。
  • 我在业余仓库中看到的模式,正是出现在处理真实用户数据的生产应用中的完全相同的模式。
  • “只要告诉 AI 要做什么”以及缺乏防御的做法是常见的陷阱。

如果你在构建任何使用 LLM 的东西——尤其是涉及真实数据或调用真实 API 时——务必测试你的提示。只需五分钟,就能避免成为下一个关于 AI 安全的博客文章中的案例。

网站:

有问题吗?

  • 对方法有疑问?
  • 觉得我的评分有误?

留下评论;我会回复所有内容。

Andrei K.

0 浏览
Back to Blog

相关文章

阅读更多 »