TECHNIQUE / 攻击手法

MCP 安全

模型上下文协议引入的工具发现、授权与信任边界问题。

2 篇相关2 个来源首见 2026-11-15最近 2026-11-15正文已写
2
相关条目
2
来源数
11-15 → 11-15
时间跨度
手法
类型

MCP 安全

一句话

MCP 让 Agent 在运行时发现并调用工具,等于把信任边界从"编译时"挪到了"运行时"。 每一次 tools/list 都是一次远程代码的语义注入。

这不是缺陷,是设计目标:MCP 要解决的正是"让模型动态接上新能力"。而"动态"和"可信"天生对立。

为什么这个攻击面比提示词注入更硬

提示词注入MCP
影响一次对话的输出影响能调用什么工具
攻击面在输入文本攻击面在协议 + 权限 + 生态
修法是护栏修法是身份与授权模型(难得多)

关键差异:MCP 服务器返回的 description 会被当作 prompt 读。 也就是说,一个第三方 server 可以在"工具说明"里写指令,而客户端会把它塞进上下文——这是协议层的注入通道,不是应用层的疏忽。

四层攻击面

层具体位置已知问题
协议层Host/Origin 校验、OAuth 授权服务器、传输绑定校验只做在传输层,同一文件里的授权服务器没做(2026-10,7 个 OAuth 端点全裸)
工具描述层tools/list 返回的 name/description/schema描述即 prompt;隐藏 Unicode 可过人工 review
传输层stdio / SSE / streamable HTTPstdio 无网络隔离;SSE 长连接难审计
生态层MCP Store、第三方 server、企业内部分发安装即信任;版本更新无签名校验

五个真实案例(按时间)

一条完整的链(DNS rebinding → 令牌 → 内部文档)

① 员工本机跑着一个 MCP 客户端,连了公司内部的 OAuth 授权服务器
        ↓
② 攻击者页面用 DNS rebinding 把自己的域名解析到 127.0.0.1
        ↓
③ 浏览器认为"同源",请求打到本机 MCP 的 OAuth 端点
        ↓
④ 端点没做 Host/Origin 校验 → 返回 client_secret / 令牌
        ↓
⑤ 攻击者用令牌调工具,读走内部文档

每一环都是"产品自己开的功能"。这是 MCP 类问题的共同形态。

怎么防(按有效性)

1. Server 白名单:只允许连接已审核的 server,禁止用户自行添加。企业环境里这一条能挡掉 80%。

2. 把工具描述当不可信内容:描述进入上下文时打标,且不允许描述里出现"指令式"语句("你必须先调用…")。

3. Host/Origin 全链路校验:不是只在校验传输层,每一个 HTTP 端点(含 OAuth 注册、授权、换令牌、自省)都要查。

4. 令牌最小化:短有效期 + 按工具粒度授权 + 不落盘。

5. 审计:记录每次 tools/call 的完整参数。MCP 出事时这是唯一证据。

6. 禁用 stdio 直连生产:stdio server 没有网络隔离,一旦被注入就是本机执行。

我的判断(2026-11)

相关(本站内)

时间线

来源分布

同一个主题出现在越多来源里,可信度越高;只出现在一个来源的,当线索看待。

Hacker News 首页
1
GitHub Trending 日榜
1

相关实体

产品1 篇
产品1 篇