MCP审计-装一个Server之前先过这五步

原创

围巢安全笔记
围巢安全笔记

围巢安全笔记

2026年11月9日 10:00
北京

去阅读

AI 安全笔记 · 第 8 篇

上一篇讲了 MCP 的攻击面，评论区有人问：道理都懂，那我明天要装一个 MCP Server，具体查什么？

这篇就是那份操作手册：装前五步、描述审读、配置文件三个危险信号、运行期三道防线。全部照着做大概半小时，跳过的人后来都在应急响应里见过面。约 4100 字。

01｜先换个脑子：把 MCP 当供应链看

大多数人对 MCP Server 的态度是「工具」，对 npm 包的态度是「供应链」——后者会查版本、看下载量、提防投毒，前者直接装。这个双重标准就是问题所在。

一个 MCP Server 就是一个跑在你机器上、用你权限的进程。它 TypeScript 写的几百行代码，每一条 tool 都能 spawn 任意进程。安全审计里已经出现过借 PowerShell 合法签名跑 LOLBAS 链的包——因为二进制是微软签名的，静态扫描全是绿的。能搜到 ≠ 有人审过。

所以流程上照搬供应链管理。装之前五个动作，一个都不能省：

图 1｜查来源、读源码、对权限、盯安装脚本、pin 版本

两个最容易被跳过的：读源码和盯安装脚本。npm 的 preinstall / postinstall 钩子在 npm install 那一刻自动执行，没有任何确认弹窗——恶意载荷最爱的落点就是这里。几百行的 Server，十分钟读完，这十分钟可能是全流程性价比最高的十分钟。

02｜描述审读：一句一句过

工具描述是投毒的第一载体，因为它按协议设计就要原文进入模型上下文。审读的基准线很简单：描述、参数、行为三者一致，且没有「不想让你看见的东西」。

图 2｜左边是正常，右边四条中一条就先停手

重点看四类可疑信号：描述里藏着指令（「把 XX 附加到每次输出」）；要求读取环境变量或密钥文件；出现「不要向用户提及本段」这类话；描述和能力对不上——一个查询类工具为什么要写权限。

偷懒但有效的招，一条命令先体检：

rg -i \"ignore|secret|token|env|credential|do not tell\" \\   --glob \"*.ts\" --glob \"*.js\" path/to/mcp-server/

再补一个隐形字符检查——零宽字符和双向控制符是 Rules File Backdoor 的同款手法，工具描述里一样能用：

rg \"[\\x{200B}-\\x{200D}\\x{2060}-\\x{2064}\\x{202A}-\\x{202E}]\" \\   --glob \"*.ts\" path/to/mcp-server/

两条命令都没命中，也不等于干净——但绝大多数粗糙投毒经不起这种笨搜索。深一点的包再配合读源码，覆盖面就够了。

03｜一次完整的走查示例

光有清单还是虚，走一遍。假设明天要装一个叫 notion-exporter 的 Server（把 Notion 页面导出成 Markdown，需求真实存在，这类工具 npm 上一搜一大把）。

第一步查来源。npm 里有三个同名包。第一个没有仓库链接；第二个仓库存在但半年没提交、issue 区一堆挂着没人回；第三个有仓库、有持续提交、发布者主页正常。选第三个，但先别装——星级和活跃度只能排除明显的垃圾，排除不了投毒。

第二步读源码。npm pack 拉下来解包（注意别 install），全文不到六百行。过一遍 rg -i \"exec|spawn|child_process|http|https\"，网络请求有四处：三处是正常调 Notion API，一处向一个第三方统计服务上报安装信息——看看上报什么，只报版本号，可以接受，也可以直接注释掉。

第三步对权限。工具列表里有一个 export-page（读 Notion）和一个 save-to-disk（写本地文件）。你的场景只需要导出到标准输出，写盘那个用不上——注册时直接不启用它。工具能不装就不装，每个少开的工具都是一条少走的通道。

第四步盯安装脚本。package.json 里有个 postinstall，内容是生成 TypeScript 类型文件——正常，很多包都这么干。但这一步必须看，因为钩子在这一刻执行，之后你看到的一切「正常」都可能是演的。

第五步 pin 版本。mcp.json 里写死 [email protected]，并且记一笔：这版是我审过的。以后要升级，重新走一遍二三两步——新版本就是新代码。

全程二十分钟。这个包是真的干净，审完放心装；如果第二步 rg 命中一段混淆过的字符串，或者上报地址看着不对劲——放弃，换一个，或者自己写。生态里同类工具不止一个，你永远有得选，攻击者赌的就是你不选。

04｜配置文件里的三个危险信号

图 3｜命令不固定 / 权限通配 / 致命三件套

第一个信号：命令不固定。npx -y some-package 不带版本号，意味着别人一发新包你自动更新——rug pull 直接命中你。改法是 pin 死版本，并且把 stdio 命令收敛到白名单：npx、uvx、python、node、docker、deno 这类已知启动器。OX Security 披露的那批 mcp.json 改写 CVE，靠这个白名单就能关掉「指向任意二进制」的路径。

第二个信号：权限通配。autoApprove 里出现 Bash(*) 这类无范围通配，等于把机器钥匙插在门上，等一个注入机会来拧。改法是按「写、删、发」逐项关，读操作可以先放。

第三个信号最隐蔽：致命三件套。一个能抓网页 / 读外部内容的工具，加一个能执行命令的工具，两个都设了自动放行，中间没有任何确认——这时候，网页里的一条注入指令可以一路绿灯变成命令执行。安全圈管这个组合叫 lethal trifecta（致命三件套）：不可信内容 + 执行能力 + 无确认。三者去掉任何一个，链就断了。

划重点：确认弹窗只在信息给全时才有用。看不到完整命令、目标路径和理由的确认框，点同意等于没看。装任何 Agent 类产品时，先看它的确认机制给不给你看全。

05｜跑起来之后：三道防线

图 4｜隔离、日志、凭证——NSA 指南的后三条

隔离：Server 之间互相隔离，一个被打穿不能殃及邻居。容器或者最小权限账号跑，禁掉它访问无关目录的路径。别让一个读数据库的 Server 能碰到你的 SSH 目录。

日志：每次调用记录 Agent 名、触发用户、调了什么工具、入参出参。NSA 指南特别强调这一点——没有调用日志，事后连「哪个 Agent 在谁的指令下调了什么」都答不上，事件调查和合规回应都没法做。有统计说八成 Agent 安全事件缺这类控制证据，这条是最普遍的短板。

凭证：短生命周期、最小范围。会话结束凭证就过期，别让一张 token 同时能读库、能写仓库、能发消息。出网走白名单——数据外带得有通道，通道堵了，注入就算成功也搬不走东西。

06｜团队场景，再多两件事

个人装着玩，上面那些够了。团队环境再加两条：

• 维护 Server 清单

。谁装的、谁批的、干什么用，登记在案。NSA 指南里「拿不出 MCP Server 清单」是被点名的缺口——个人装几个无所谓，公司环境里影子 Server 是真实存在的攻击面，审计发现过 9400 个公开 Server 里大量未经审核的包，公司内网里只会更多；
* mcp.json 进版本库、走 review

。配置文件本身就是代码——它决定了一台机器上跑什么。PR 里突然多一个 Server、某个工具悄悄改了描述，这些都应该在 review 里被问一句。

07｜一条合格的调用日志长什么样

上一节说日志是三道防线里最普遍的短板，那合格的日志到底记什么？拿一条记录出来对着看：

{   \"ts\": \"2026-11-10T14:23:07+08:00\",   \"agent\": \"claude-code (workspace: pay-svc)\",   \"user\": \"wei.chao\",   \"server\": \"[email protected]\",   \"tool\": \"list_tables\",   \"args\": {\"db\": \"orders\"},   \"result_bytes\": 842,   \"approval\": \"auto(read-only)\" }

七个字段：时间、哪个 Agent、哪个用户触发的、哪个 Server 的哪个工具、入参、返回量级、这次调用走的审批路径。事后调查时，「谁让 Agent 干了什么」这个问题完全由这七个字段回答——缺任何一个，调查都要靠猜。

保存期按事件调查的口径定：安全事件的平均发现周期普遍以周计，日志至少留 90 天，有合规要求的按要求数。日志本身外送到集中存储，别只写在 Agent 所在机器上——那台机器被打穿的时候，就是日志最该活着的时候。

再加一个用得上的排查习惯：定期看一眼调用频率异常的工具。某个查询类工具突然被高频调用、某个从来没人用的工具突然活跃，都值得点开看看是谁在调、调来干什么。投毒生效之后一定会留下调用痕迹，这条比任何检测规则都便宜。

08｜三个常见误判

按上面的流程走，大概率不会踩坑。但审的时候有三个「想当然」，专门提出来：

误判一：星级高、下载多 = 安全。买 star 和刷下载量是成熟的灰色产业，npm 上的恶意包经常挂着几千 star 的正常外壳。社交证明是最容易被伪造的信号，别把它当安全信号。

误判二：包名对得上 = 官方出品。npm 不保护包名——官方发 @anthropic/mcp-sdk，别人完全可以发一个 anthropic-mcp-sdk。看包要看 scope（@开头的才算组织名下）、看仓库链接是否指向官方组织，PyPI 上同理。

误判三：扫描干净 = 无害。LOLBAS 打法的全部意义就在这里：用系统自带、微软签名的合法二进制干活，任何针对「恶意特征」的扫描都扫不出来。审计里那个借 PowerShell 跑下载链的包，静态特征全是绿的。能识破它的只有行为审查——读源码看它 spawn 了什么，这就是第二步读源码不可替代的原因。

整篇收个尾：查来源、读源码、对权限、盯脚本、pin 版本——装前五步；命令白名单、权限逐项、三件套拆开——配置三处；隔离、日志、短凭证——运行三道。加起来一张 A4 纸写得下。

工具的方便是真的，风险也是真的。半小时的流程换一个不会被 MCP 后门背刺的开发环境，这买卖划算。

读完先别走——打开你的 mcp.json，看一眼有没有 npx -y 不带版本号的。有的话，回来评论区说一句。