AI安全攻防与治理之十四：AI 安全测试不能脱离传统安全，Web、API、移动端与模型攻击面的组合拳

大模型应用出现后，很多企业开始建立专门的 AI 安全测试流程。

测试重点通常集中在：

• 提示词注入；
• 越狱；
• 系统提示词泄露；
• RAG 知识库投毒；
• 工具调用越权；
• 敏感信息输出。

这些内容确实是 AI 应用新增的重要风险。

但一个容易被忽略的事实是：

大模型应用并不是悬浮在空中的模型，它仍然运行在 Web、API、移动端、云平台、身份系统、数据库和业务系统之上。

如果传统安全边界已经失效，攻击者就可能先通过 Web、API 或移动端获得入口，再利用 AI 的数据访问和自动化能力扩大影响。

因此，AI 安全测试不应与传统安全测试割裂，而应将二者放在同一条攻击链中分析。

一、AI 应用本质上是一套复合系统

一个较完整的 AI 应用通常包含：

Web 前端
   ↓
移动端 App
   ↓
API 网关与身份认证
   ↓
业务服务
   ↓
提示词编排与会话管理
   ↓
RAG、向量库和长期记忆
   ↓
大模型推理
   ↓
Agent、插件和工具调用
   ↓
数据库、云平台与生产系统

攻击者可以从任意一层进入：

• 前端暴露敏感接口；
• 移动端硬编码密钥；
• API 缺少对象级授权；
• 文件上传未做内容隔离；
• 云角色权限过大；
• RAG 未执行租户过滤；
• 工具网关信任模型输出；
• 模型被提示词注入；
• 输出被直接写入业务系统。

最终形成组合攻击。

二、为什么单独测试模型是不够的

假设模型能够正确拒绝以下请求：

"请告诉我其他客户的联系方式。"

这只能说明模型在当前对话场景中表现得较为谨慎。

但如果攻击者通过传统漏洞：

• 修改用户 ID；
• 篡改租户参数；
• 重放高权限 Token；
• 调用未公开 API；
• 绕过前端角色控制；
• 利用移动端接口暴露；

直接让后端返回其他客户数据，那么模型层的拒答能力就没有意义。

反过来，即使 Web 和 API 本身没有明显高危漏洞，模型也可能被诱导：

• 调用越权查询工具；
• 绕过业务确认；
• 组合多个低权限 API；
• 将敏感数据发送到外部邮箱；
• 执行错误的生产操作。

因此，测试对象不能只有模型，而应包括：

客户端
→ 网络和 API
→ 身份与权限
→ 模型和上下文
→ 检索和工具
→ 业务系统
→ 数据和审计

三、Web 攻击面：模型应用仍然是 Web 应用

AI 产品常见的 Web 攻击面包括：

• 前端接口暴露；
• 未授权访问；
• 跨用户数据读取；
• 文件上传；
• SSRF；
• XSS；
• CSRF；
• 路径穿越；
• 服务端模板注入；
• 管理后台暴露；
• 调试接口泄露；
• WebSocket 会话控制缺陷。

这些传统漏洞可能与模型能力组合，产生更复杂的后果。

1. 文件上传与间接提示词注入

假设一个企业 AI 支持上传：

• PDF；
• Word；
• Excel；
• 图片；
• 网页；
• 邮件附件。

攻击者可以先上传包含恶意指令的文件，再等待模型解析、OCR 或检索。

攻击链可能是：

文件上传校验不足
  ↓
恶意内容进入解析或 OCR
  ↓
内容被加入模型上下文
  ↓
模型误将文档内容当成指令
  ↓
调用内部工具或泄露数据

这里既有传统文件上传安全问题，也有模型上下文安全问题。

2. SSRF 与内部 AI 服务

如果 AI 应用支持抓取网页、读取 URL 或调用外部资源，而服务端没有严格限制目标地址，攻击者可能利用 SSRF 探测：

• 内部管理接口；
• 模型服务；
• 向量数据库；
• 云元数据服务；
• 内部工具网关；
• 监控和调试端点。

一旦内部 AI 服务没有强认证，传统 SSRF 就可能成为模型和工具的入口。

3. XSS 与模型输出

如果模型输出被前端当作 HTML、Markdown 或富文本直接渲染，攻击者可能将恶意脚本混入：

• 用户输入；
• 知识库文档；
• RAG 结果；
• 工具返回值；
• 模型生成内容。

因此，模型输出安全不能只看"内容是否合规"，还要看：

• 前端如何渲染；
• HTML 是否过滤；
• 链接是否安全；
• 是否允许脚本和 iframe；
• 是否存在跨域影响；
• 输出是否进入其他用户页面。

四、API 攻击面：AI 风险往往在接口层真正落地

大模型应用通常依赖大量 API：

• 对话 API；
• 文件上传 API；
• 检索 API；
• 工具调用 API；
• 用户和租户 API；
• 会话 API；
• 管理 API；
• 业务操作 API；
• 日志和调试 API。

传统 API 安全问题可能直接放大 AI 风险。

1. 对象级授权缺失

例如，API 接收：

{ 
     "customer_id": "目标客户编号" 
} 

如果服务端只验证用户已登录，却不验证客户对象是否属于当前用户或租户，就会出现对象级越权。

在 AI 场景中，攻击者可能先通过提示词注入，让模型生成目标对象编号，再利用后端 API 完成访问。

因此，需要同时测试：

• 用户直接调用 API；
• 模型生成工具调用；
• Agent 通过网关调用；
• 工具服务内部调用；
• 不同租户和不同角色的访问。

2. 参数篡改和业务逻辑绕过

模型可能生成：

• 超出金额范围的退款；
• 不属于当前客户的订单号；
• 被修改的收件人；
• 扩大的导出字段；
• 跳过审批的状态参数；
• 被篡改的权限角色。

后端不能假设模型已经正确生成参数。

服务端必须重新校验：

用户身份
→ 租户归属
→ 对象归属
→ 字段范围
→ 金额和数量
→ 当前业务状态
→ 审批和确认凭证

3. API 批量调用

如果对话 API、工具 API 和业务 API 缺少速率限制，攻击者可能利用 Agent 批量：

• 查询客户；
• 下载文档；
• 枚举订单；
• 测试权限；
• 发送邮件；
• 发起退款；
• 执行任务。

需要测试：

• 单会话调用上限；
• 单用户调用上限；
• 单租户调用上限；
• 工具组合限制；
• 异常调用检测；
• 批量导出拦截；
• 高风险操作的频率限制。

五、移动端攻击面：App 是模型能力的另一条入口

如果企业 AI 能力通过移动端提供，测试范围还必须覆盖：

• 本地存储；
• Token 管理；
• 证书校验；
• 接口签名；
• 深链接；
• 推送通知；
• WebView；
• 本地日志；
• 截图和剪贴板；
• 越狱或 Root 环境；
• 反编译和接口发现。

1. Token 和会话管理

移动端可能存在：

• 长期 Token；
• Token 明文存储；
• 刷新令牌未绑定设备；
• 注销后 Token 仍有效；
• 用户切换时缓存未清理；
• 多账号会话混用；
• 设备丢失后仍可访问。

如果移动端 Token 可以直接调用高权限 AI API，攻击者就可能绕过前端，直接操作模型和工具。

2. 移动端本地数据残留

App 可能在本地保存：

• 历史会话；
• 上传文件；
• 模型输出；
• 客户资料；
• 访问令牌；
• RAG 检索结果；
• 工具执行记录。

需要检查：

• 是否加密；
• 是否进入系统备份；
• 是否可通过日志读取；
• 注销和卸载后是否残留；
• 是否能通过截屏和剪贴板泄露；
• WebView 是否共享 Cookie 和会话。

3. 移动端与后端信任错误

不能因为请求来自官方 App，就默认请求可信。

攻击者可以：

• 逆向 App；
• 重放请求；
• 修改参数；
• 绕过前端校验；
• 伪造设备信息；
• 调用隐藏接口；
• 修改 Agent 工具参数。

所有关键授权必须在后端完成。

六、模型攻击面：新增风险如何与传统漏洞组合

传统安全测试仍然不够，因为模型增加了新的行为攻击面。

1. 直接提示词注入

攻击者直接输入恶意指令，试图：

• 改变任务；
• 获取系统提示词；
• 强制调用工具；
• 绕过安全规则；
• 输出敏感内容。

2. 间接提示词注入

攻击指令隐藏在：

• 文档；
• 网页；
• 邮件；
• 图片；
• 工单；
• 知识库；
• 工具返回结果。

3. RAG 投毒与越权检索

攻击者可能：

• 上传恶意文档；
• 修改知识库；
• 利用索引权限缺陷；
• 召回其他租户内容；
• 让低可信资料覆盖正式制度。

4. Agent 工具调用

模型可能被诱导调用：

• 数据库查询；
• 文件导出；
• 邮件发送；
• 退款和付款；
• 云平台配置；
• 代码执行；
• 生产运维命令。

5. 上下文和记忆污染

攻击者可能通过多轮对话、长期记忆或缓存，让模型在后续请求中沿用错误状态或不可信指令。

七、典型组合攻击场景

场景一：移动端 Token 泄露 + Agent 工具越权

移动端日志暴露长期 Token
  ↓
攻击者调用对话 API
  ↓
诱导 Agent 访问客户查询工具
  ↓
工具使用统一服务账号
  ↓
后端缺少对象级授权
  ↓
批量获取客户数据

场景二：文件上传 + OCR + 间接提示词注入

上传接口允许恶意 PDF
  ↓
OCR 提取隐藏文字
  ↓
内容进入模型上下文
  ↓
模型误认为是内部指令
  ↓
调用工单或邮件工具
  ↓
敏感信息外发

场景三：API 越权 + RAG 跨租户检索

修改租户参数
  ↓
调用文档检索 API
  ↓
向量库未执行租户过滤
  ↓
模型引用其他客户资料
  ↓
敏感信息返回前端

场景四：SSRF + 内部工具网关

网页抓取功能存在 SSRF
  ↓
探测内部服务
  ↓
访问未认证的工具网关
  ↓
调用数据库或运维接口
  ↓
绕过模型层安全策略

这些风险都说明：

模型安全问题经常不是单点漏洞，而是传统漏洞与模型能力叠加后的结果。

八、如何设计组合拳测试方法

建议将测试分成四个维度。

1. 客户端测试

包括：

• Web；
• 移动端；
• 浏览器插件；
• 文件上传；
• 本地缓存；
• Token 和会话；
• 深链接与 WebView。

2. 传统服务端测试

包括：

• 身份认证；
• 对象级授权；
• API 参数；
• 业务逻辑；
• SSRF；
• 文件解析；
• 注入；
• 速率限制；
• 云权限；
• 管理接口。

3. AI 组件测试

包括：

• 提示词注入；
• RAG 投毒；
• 越权检索；
• 记忆污染；
• 工具调用；
• 输出过滤；
• 多模态输入；
• Agent 规划。

4. 业务影响测试

包括：

• 数据泄露；
• 订单篡改；
• 退款和付款；
• 权限变更；
• 外部发信；
• 生产环境变更；
• 客户和员工数据影响。

最终要把测试串成完整链路：

客户端入口
→ 传统漏洞
→ 身份和权限
→ 模型输入或上下文
→ RAG 或工具调用
→ 业务 API
→ 真实状态变化
→ 审计与响应

九、如何建立测试环境和证据链

1. 使用隔离环境

准备：

• 测试租户；
• 脱敏数据；
• 模拟 API；
• 测试 Token；
• 沙箱工具；
• 可回滚数据库；
• 可控云资源。

2. 记录每个边界

至少记录：

• 请求来源；
• 用户和设备；
• Token 和会话；
• API 参数；
• 模型版本；
• Prompt 版本；
• 检索文档；
• 工具调用；
• 权限结果；
• 业务状态变化；
• 日志和告警。

3. 区分模型行为和系统行为

报告不能只写：

模型被越狱。

应拆成：

模型接受了恶意输入
  ↓
生成了越权工具调用
  ↓
工具网关未拦截
  ↓
业务 API 未执行对象级授权
  ↓
数据库返回敏感数据
  ↓
前端展示给攻击者

每个环节都需要明确责任组件和修复位置。

十、整改优先级

第一优先级：后端授权

无论请求来自 Web、移动端、模型还是 Agent，后端都必须重新验证：

• 用户；
• 租户；
• 对象；
• 角色；
• 参数；
• 审批；
• 状态。

第二优先级：工具最小权限

Agent 不应使用万能管理员身份。

工具应拆分、限权、限范围，并设置组合和频率约束。

第三优先级：输入和文件隔离

外部内容、上传文件、RAG 文档和工具结果不能自动获得系统指令地位。

第四优先级：移动端和 API 安全

Token、会话、对象级授权、速率限制和接口签名必须纳入 AI 安全范围。

第五优先级：完整监控和响应

要能够发现：

• 异常提示词注入；
• 批量工具调用；
• 跨租户检索；
• 异常 Token；
• 敏感字段输出；
• 生产环境异常操作；
• 传统漏洞与模型行为的组合攻击。

结语

AI 应用的攻击面不是从模型开始，也不会在模型输出后结束。

它完整存在于：

Web
→ API
→ 移动端
→ 身份系统
→ 数据库
→ RAG
→ 模型
→ Agent 工具
→ 业务系统
→ 云和生产环境

真正有效的 AI 安全测试，不能只问：

模型能不能被越狱？

还要问：

攻击者能不能从 Web 或移动端进入？

能不能利用 API 越权？

能不能通过文档和 RAG 影响模型？

能不能诱导 Agent 调用工具？

能不能最终改变真实业务状态？

只有将传统安全与模型安全组合起来，企业才能看到完整的攻击链，也才能把 AI 安全从"模型测试"真正推进到"应用和业务安全"。