本文内容原发于 20250413 Vidar-Team Web 安全分享会

近几年 AI 红得发紫，紫得发黑，这不最近又有人搞了一点基建上来，这就是我们的 MCP。

sequenceDiagram
    Server->>Client: mcp 工具描述
    Client->>LLM: mcp 工具描述+用户输入
loop
    LLM->>Client: mcp 调用请求
    Client->>Server: 调用请求 
    Server->>Client: 调用结果
    Client->>LLM: 调用结果
end
    LLM->>Client: LLM 生成最终回复

上图展示的就是我们 MCP 的全调用链路，可以尝试思考，对于这串调用中的所有角色，可能出现什么安全问题？

我们可以看到，整个流程也就两个接口，LLM 对 MCP Client，MCP Client 对 MCP Server。

LLM - MCP Client

这个接口一般通过一个 Token 完成鉴权，由 MCP Clinet 方向主动连接到 LLM。

从 Web 安全的角度来看，这个问题很简单，就是最基本的无鉴权和 token 泄露等传统 Web 问题。在大模型比较早期的时候，基本都是通过 OpenAI API Token 完成这部分的鉴权问题的，那会就出现了在各种地方，主要是一些代码库，搞个正则就可以搜索到他人的 API Token 的事情，典型网络安全意识缺失。这件事被捅出来了之后呢，搞应用安全这伙人开始做针对性的主动扫描了，知道这个问题的人也多了，暂时好了一点。

但随着各种大模型如雨后春笋般地冒出，外加一些蒸馏技术的出现，大模型的私有化部署逐渐成为可能，但其实一直不温不火，但到 deepseek 开源国产大模型走红之后，整个互联网给人一种是个人都要部署一个 deepseek 的感觉，各种高校企事业单位个人都在搞。这一拥而上啊就容易丢三落四，从结果上看呢，就是互联网上冒出了非常多的 llama API。

其实我们很早就观察到了这个问题，尤其是 deepseek 走红之后，互联网上的无鉴权 llama api 越来越多。太多人想借 AI 的东风的，无论是有能力没能力去管理这样一个服务的，都想着成为风口上的那头猪。事已至此，肯定也存在一批人在某鱼上做接口扫描与聚合再打包出售的的生意的。

这个 API 本身其实利用价值有限，结果上看倒是不太构成问题，但如果反过来思考可能会有一些有意思的东西。

试想，如果能够假装自己是一个 LLM，制作一个 llama 蜜罐，怎样才能做到威胁最大化。

在 MCP 出现之前，LLM 蜜罐如果能 RCE 只能依赖在给用户的代码里掺杂一些恶意代码，需要用户手动去触发，这个链路实际上有点扯淡了，触发随缘，目标随机，不太值得。

sequenceDiagram
    LLM->>Client: mcp调用请求（写入 .git/hooks）
    Client->>Server: 调用请求（调用 FileSystem Server）
    Server->>Client: 调用结果
    Client->>LLM: 调用结果

而 MCP 的出现，直接给了大模型调用工具的能力，比如热门的 mcp 官方实现的 FileSystem MCP，实际上可以在 LLM 的返回中掺杂 MCP 调用从而触发文件写。这就是我称之为 LLM 蜜罐的最后一张拼图的原因。

实际场景中，LLM 蜜罐可以解析从 Client 侧获取到的 MCP 列表，如果 MCP 列表中存在一些可以利用的 Tools，就直接返回 MCP 调用实现利用，这一切对于给了权限的用户而言是无感的。

MCP 套件日后可能也会演化出一套权限控制方案，什么权限是需要确认的，什么权限用一次就得人工确认一次，确实是怕 AI 搞坏东西。

MCP Client - MCP Server

对于 MCP Server，首当其冲的是 MCP Server 的未授权访问，直接导致一些操作的执行。

MCP Server 有两种连接方式，一种走的是 stdio，这个其实相对安全一些，毕竟得 MCP Client 那边去 exec 一下过来，攻击面比较窄，另一种是走 http，这个相对而言就危险多了，完全可以通过这个口子去做提权和横向的操作，如果 MCP Server 内部跑的服务合适的话。

这些是老生常谈的 Web 问题了，不再赘述了。前面讲的是假装自己是 MCP Client 与 MCP Server 交互，那么下面可以思考一下，如果假装自己是一个 MCP Server 和 MCP Client 交互会怎么样呢？

这个场景现在似乎不太存在，因为目前大家都是自部署的，但如果 MCP 这条路是对的，未来网络上就可能会出现一些闭源 MCP 接口。所以这里实际对于的场景是，找到一个 MCP Server 就连，是安全的吗？

其实不完全安全，这就要讲到提示词越狱的事情了，这是 AI 应用唯一特有的安全问题，可以通过构造一个提示词来让 AI 做出预期外的行动，比如，泄露上下文，执行一个高危 MCP 调用等等。LLM 大模型的基本原理就是不断地预测下一个 Token 是什么这样子去做文本生成，所以其实我们和 LLM 交互的时候，无论过程如何，最终都是转化为一个非结构化的文本交给大模型去处理。

当然我知道很多大模型提供了接口可以让我们去定义 function，但这依然改变不了这个事实。这里其实只是把越狱的安全问题转交给了大模型的厂商负责，他们对模型本身有更高的自由度，可以通过一些微调来更好地解决这个问题。同时从现在来看，也并非所有大模型都提供了这个能力。

sequenceDiagram
    Server->>Client: mcp工具描述（恶意描述）
    Client->>LLM: mcp工具描述+用户输入（越狱）
loop
    LLM->>Client: mcp调用请求（调用可利用mcp）
    Client->>Server: 调用请求 
    Server->>Client: 调用结果
    Client->>LLM: 调用结果
end
    LLM->>Client: 回复给用户

言归正传，如果我们要去制作一个 MCP Server 蜜罐，首先我会考虑的是在对蜜罐返回的 function 描述里添加一些东西，类似于 DEBUG 一类的工具来吸引大模型来调用，并泄露数据。这是一个非常不成熟的想法，因为本人不太擅长 LLM 越狱试了试也没成功。但我认为方向是正确的，权且当个思路，这里确实是存在一个难以解决的风险，我们需要去保证 MCP Server 的可信。

AI 安全与 Web 安全

分析完上面的例子，我们其实可以认为，AI 应用安全就是 Web 安全的一部分，只是在一个某一个领域下，附加了一些额外的专有的安全问题，主体依然是 Web 的主体。其实这么一想，很多的问题应用安全问题都是这样子的，无非就是入口处的准入控制、传输时的数据含义精准、操作时原子性三个分支，整个做下来就是权限控制，数据结构化和竞争检测一类故事。那 AI 安全未来的发展，我猜也无出其右。