企业官网建设流程全解析

MCP 协议的安全盲区：我让一个公开 MCP Server 跑了三天，结果令人后怕

上周我干了件蠢事。

写了个 MCP Server 挂到公网，想测一下 Streamable HTTP 传输的稳定性。部署完确认能跑就没管了。三天后打开日志——好家伙，十几条来自陌生 IP 的请求记录。有人在扫文件系统，有人在试内网地址段，还有人直接往参数里塞了 pipe 管道符。

我不是搞安全的，但这点常识还有：我的 MCP Server 没有任何访问控制，谁连进来都能调所有 tool。等于把一串万能钥匙挂在了大门外，谁路过都能拿起来试试。

MCP 的安全模型：「你信我，我就信你」

先看协议本身。MCP（Model Context Protocol）定义了一套客户端-服务器的交互规范：Client 发请求，Server 响应。协议里定义了 list_tools、call_tool、read_resource 这些核心操作，但你可以翻一遍规范文档——没有一页讲鉴权、授权、速率限制或者输入校验。

这不是协议的缺陷，是它的设计取舍：MCP 面向的是本地场景，标准 stdio 传输默认只在你的终端进程内通信，不需要鉴权。但问题来了——太多人跟我一样，把 Server 从 stdio 升到 Streamable HTTP 之后，忘了补上安全层。

Streamable HTTP 是 MCP 今年加的传输方式，让 Server 可以跑在远程服务器上，客户端通过网络连接。设计上给了一步 DIY 的空间：你可以在传输层之上自定义认证逻辑。但协议没告诉你「必须做」，默认不做也能跑——你猜大多数人会选哪个？

我日志里实际看到的三类攻击

第一类：SSRF + 文件盗读

我的 Server 有个 read_file 工具，接收 path 参数返回文件内容。设计初衷是让 Agent 读取配置文件。攻击者连上