# 插件系统是怎么防止你被恶意扩展攻击的？

当一个 AI 工具允许安装第三方插件时，安全问题就变得至关重要——插件可能注入恶意命令、窃取数据、或绕过权限系统。这一章深入分析 Claude Code 的六层安全防线（工作区信任 → Marketplace 名称保护 → 插件黑名单 → 企业管控 → hooks 源标记 → 优先级降级）是如何保护用户的。

> **源码位置**：`src/utils/plugins/` (44 文件)，`src/services/plugins/` (3 文件)，`src/commands/plugin/` (17 文件)

> 💡 **通俗理解**：插件安全机制就像古代城市的**六道城墙**，层层递进：**外围三道**是"身份核验"——工作区信任（进工作区得先确认是你）、Marketplace 名称保护（防冒牌店铺）、插件黑名单（已知恶人黑册）；**内层三道**是"行为约束"——企业管控（公司安保队）、hooks 源标记（记下是谁放进来的）、优先级降级（就算进来了也只能待在低级区）。六道城墙不是冗余，而是假设任何一道都可能被绕过，用多重验证把破坏范围严格限制住。

---

### 🌍 行业背景

插件/扩展安全是所有可扩展工具的核心挑战，各家方案差异巨大。**VS Code**（及基于它的 Cursor、Windsurf）的扩展运行在独立的 Extension Host 进程中，通过 IPC 与主进程通信，但扩展仍然拥有完整的 Node.js API 访问权——恶意扩展可以执行任意文件操作和网络请求，安全主要依赖 Marketplace 的审核流程和用户信任。**LangChain** 的工具系统更加开放——任何 Python 函数都可以注册为 Tool，框架本身不提供沙箱隔离，安全完全由开发者自行保障。**Codex（OpenAI）** 采取了相反的极端策略：实现了操作系统级别的网络出口限制（OS-level egress rules），取代了早期脆弱的环境变量控制，从操作系统层面限制代码执行的能力。**MCP（Model Context Protocol）** 规范定义了工具调用的标准接口，但安全模型仍由各实现方自行决定——GitHub Copilot 已构建企业级的 MCP 注册表机制，深度融合企业内网安全防火墙策略。

Claude Code 的插件安全策略介于"完全开放"和"硬件沙箱"之间——不像 Codex 那样用操作系统级网络隔离。需要明确：Claude Code 的插件 hooks 本身**可以执行任意 shell 命令**（这是 hooks 设计意图），因此"沙箱/权限隔离"并非插件层的主要防线；防线更多落在软件层——白名单、仿冒检测、信任确认、优先级降级、企业 policySettings 禁用管控。换句话说：前面提到的"六道城墙"**不是沙箱**，而是"准入 + 溯源 + 权重降级"三类策略的组合；一旦恶意 hook 被用户在"工作区信任"步骤放进来，它拥有的系统权限与用户本人一致。

---

## 问题

Claude Code 有插件系统，可以安装第三方扩展。但用 Markdown 文件定义命令、用 JSON 定义 hook——这不就是给攻击者开了一扇门吗？系统是怎么防御的？

---

## 插件能做什么

首先明确攻击面的范围。一个插件可以添加：

```
my-plugin/
├── commands/    # 新的斜杠命令（.md 文件）
├── agents/      # 新的 AI 代理（.md 文件）
└── hooks/
    └── hooks.json  # 在任意 hook 事件上执行命令
```

如果一个插件被安装，它的 `hooks.json` 可以注册 `PreToolUse`、`PostToolUse`、`UserPromptSubmit` 等事件上的回调——理论上可以拦截每个工具调用、修改用户输入、在对话结束时执行任意命令。

这是一个真实的风险。

---

## 防御层 1：工作区信任

和所有 hooks 一样，插件的 hooks 也受到工作区信任检查：

```typescript
// hooks.ts
if (shouldSkipHookDueToTrust()) return
```

在用户显式接受信任对话框之前，插件的 hooks 不会执行。这是第一道防线——一次性的信任授权。

---

## 防御层 2：Marketplace 名称的三重保护

当你安装 `plugin@claude-code-marketplace` 时，系统需要防止非官方 Marketplace 使用"官方感"名称冒充身份（注意：这里只做名称白名单/仿冒名检测/ASCII 限制，不做服务器身份校验）。

**防护 1：名称白名单**

```typescript
// src/utils/plugins/schemas.ts:19-28 全量
export const ALLOWED_OFFICIAL_MARKETPLACE_NAMES = new Set([
  'claude-code-marketplace',
  'claude-code-plugins',
  'claude-plugins-official',
  'anthropic-marketplace',
  'anthropic-plugins',
  'agent-skills',
  'life-sciences',
  'knowledge-work-plugins',
])
```

只有这 8 个名称可以被当作"官方"Marketplace，白名单穷举完毕，没有省略。

**防护 2：仿冒名称检测**

```typescript
// src/utils/plugins/schemas.ts:71-72 完整原文
export const BLOCKED_OFFICIAL_NAME_PATTERN =
  /(?:official[^a-z0-9]*(anthropic|claude)|(?:anthropic|claude)[^a-z0-9]*official|^(?:anthropic|claude)[^a-z0-9]*(marketplace|plugins|official))/i
```

这个正则由三段 OR 组成（从左到右依次是）：
1. `official<分隔符>anthropic|claude` — 阻断 `official-claude-plugins` 之类
2. `anthropic|claude<分隔符>official` — 阻断 `claude-official` 之类
3. `^anthropic|claude<分隔符>(marketplace|plugins|official)` — 阻断以 `anthropic-marketplace-xxx` / `claude-plugins-v2` 开头的冒名
三段都用 `[^a-z0-9]*` 允许任意非字母数字的分隔（含空串），并加 `i` 标志大小写不敏感。

**防护 3：同形字攻击防护**

```typescript
const NON_ASCII_PATTERN = /[^\u0020-\u007E]/
```

市场名称只允许 ASCII 字符。这防止了用视觉相似的 Unicode 字符（如西里尔字母 `а` 代替拉丁字母 `a`）来伪造官方名称的攻击。

> 📚 **课程关联**：同形字攻击（homograph attack）是计算机安全领域的经典话题之一，最常见的触达场景是浏览器地址栏的 IDN（国际化域名）伪装，各大浏览器为此引入了 Punycode 显示策略。Claude Code 在插件命名层面面临类似威胁模型，采用了最简单但最有效的防御：直接拒绝非 ASCII 字符。

---

## 防御层 3：插件黑名单

`src/utils/plugins/pluginBlocklist.ts` — 系统维护一个已知恶意插件的黑名单。本章未翻到直接展示"远程推送更新"的源码路径，保守表述为：黑名单以本地文件形式存在，具体更新来源（是否随二进制分发、是否有远程拉取）需进一步核实代码；不声称有独立的远程策略下发通道。

---

## 防御层 4：企业管控

通过 `policySettings` 可以：
- `allowManagedHooksOnly: true` — 只允许企业管控的 hooks，完全禁止用户/插件 hooks（`src/utils/hooks/hooksSettings.ts:97-100`）
- 强制安装特定的企业插件（见 `src/utils/plugins/managedPlugins.ts` 的 `getManagedPluginNames()`——"managedPlugins"能力的入口）
- 通过 `getBlockedMarketplaces()`（`src/utils/plugins/marketplaceHelpers.ts:171`）阻断特定 Marketplace

> 📚 **课程关联**：这种企业级集中管控模式与**操作系统**课程中的强制访问控制（MAC, Mandatory Access Control）思想一致——管理员定义策略，用户无法覆盖。对比 Linux 的 SELinux/AppArmor 策略机制，`allowManagedHooksOnly` 相当于"只允许系统管理员签名的内核模块加载"。

---

## 防御层 5：插件 hooks 源标记

```typescript
hooks.push({
  event: hookEvent,
  config: hook,
  matcher: matcher.matcher,
  source: 'pluginHook',  // 标记来源
  pluginName: matcher.pluginId,
})
```

每个插件注册的 hook 都会被标记为 `pluginHook` 来源，在 UI 中可见（显示为"Plugin Hooks (~/.claude/plugins/*/hooks/hooks.json)"），让用户知道哪些 hooks 来自插件。

---

## 防御层 6：优先级降级

插件 hooks 的排序优先级是 999（`source === 'pluginHook'`），比所有用户设置（优先级 0-2）都低。这意味着如果用户的设置和插件的设置冲突，用户的设置始终获胜。

---

## 命令的安全边界

插件命令（`.md` 文件）本质上是提示词，不是代码。它们被解析后成为 AI 的 system prompt 的一部分：

```markdown
---
allowed-tools: Bash, Read
---

Build the project: $ARGUMENTS
```

关键约束：
- 命令的 `allowed-tools` 字段限制了命令可以使用的工具集
- 命令内容是静态文本（加上 `$ARGUMENTS` 参数替换），不能执行动态代码
- 命令没有比用户更高的权限，它仍然受到权限系统的所有约束

---

## 剩余的攻击面

这些防御不能完全消除风险。以下场景仍然值得警惕：

**项目级 `.claude/settings.json`**：如果你 `git clone` 了一个恶意仓库，它的 `.claude/settings.json` 里可能有 hooks。工作区信任机制是主要防线，但用户可能习惯性地点"接受"——Claude Code 侧的应对是：在第一次进入该工作区时显式弹"信任对话框"，并对所有 hook 类执行加 `shouldSkipHookDueToTrust()` 统一拦截，不会"未信任就先跑"。

**恶意插件通过合法 Marketplace 分发**：如果攻击者能把恶意插件上传到合法的 Marketplace，名称防护就失效。Claude Code 侧的兜底是 `pluginBlocklist` + 企业 `policySettings` 强制黑名单 + hook 来源标记；社区举报后可以通过"把插件名加入 pluginBlocklist / 将 Marketplace 加入 `getBlockedMarketplaces`"在下次拉取时阻断，但对"已经安装并执行过的恶意插件"不能回滚历史后果。

**`$ARGUMENTS` 的二次解析风险**：命令 `.md` 里的 `$ARGUMENTS` 只是在命令模板里做文本替换，它的内容不会被再次当作新的命令或指令路由回 Claude Code 的 slash-command dispatcher，本质是一段 prompt 文本交给 AI。不过它**作为 prompt 一部分**确实有"提示注入"攻击面——恶意参数可以尝试劫持 AI 行为，这属于 prompt injection 层的问题，由模型侧的提示遵从 + 工具权限系统共同防御，而不是靠 `$ARGUMENTS` 本身的解析阻断。

**插件的 hooks 可以执行任意 shell 命令**：这是设计意图（hooks 的核心功能），但也意味着一个被安装的恶意插件拥有与用户相同的系统权限——与本章开头列出的"六道城墙不是沙箱"口径一致。

---

## 设计的代价与权衡

然而，这些防御层并非没有局限。白名单模型限制了生态的开放性——独立开发者发布插件的门槛较高。仿冒名称检测依赖正则表达式，攻击者可能找到绕过的边界情况。最大的风险在于用户习惯性地点击"信任"——工作区信任弹窗是第一道防线，但如果用户不仔细审查就接受，后续的防御层都建立在一个错误的信任基础上。此外，插件的 hooks 可以执行任意 shell 命令这一设计决策，意味着权衡了功能性和安全性——如果未来发现这个权衡需要调整，改动的代价会很大。

---

## 代码落点

- `src/utils/plugins/schemas.ts`，第 19-28 行：官方 Marketplace 名称白名单
- `src/utils/plugins/schemas.ts`，第 71-72 行：仿冒名称检测正则
- `src/utils/plugins/schemas.ts`，第 79 行：同形字攻击防护
- `src/utils/plugins/pluginBlocklist.ts`：插件黑名单
- `src/utils/hooks/hooksSettings.ts`，第 97-100 行：`allowManagedHooksOnly` 检查
- `src/utils/hooks/hooksConfigManager.ts`，第 256-259 行：插件优先级 999