Interview Bank

MCP in 7 Days: Wire Tools Into Any Agent

D6 Security and Governance: Prompt Injection in Tool Descriptions, the Confused Deputy, Least Privilege, Audit Logs, and a Tool Allowlist

• How does the confused deputy attack play out in an MCP setting, and what does the spec require to prevent it?混淆代理攻击在 MCP 场景里具体是怎么发生的？规范要求怎么防？

  Common in ChinaCommon overseasDeep dive#oauth#confused-deputy

  How to reason about it · think before answering

  1. This screens for hands-on OAuth. Reciting 'a deputy tricked into using its own authority' is entry level; the interviewer wants the concrete chain as it appears in MCP.
  2. Fix the roles first: the vulnerable party is a proxy server, which is a server to the MCP client and an OAuth client to the third-party API. It is not compromised, it is used.
  3. List the four conditions that must all hold: the proxy uses a static client id with the third party; the proxy lets MCP clients register dynamically, each with its own client id; the third-party authorization server sets a consent cookie after the first approval; and the proxy performs no per-client consent before forwarding.
  4. Then the chain: the attacker dynamically registers a client with their own redirect_uri, sends the user a crafted authorization link, the browser carries the old consent cookie to the third party, which recognizes the static client id plus cookie and skips the consent screen, the code returns to the proxy, the proxy mints an MCP authorization code and redirects to the attacker's registered URI, and the attacker exchanges it for tokens. The user consented to nothing in this flow; the cookie came from a legitimate earlier one.
  5. Answer the mitigation in the spec's own terms: proxy servers MUST implement per-client consent, and that consent must happen before forwarding to the third party. Four supporting requirements: store consent keyed by user plus client_id rather than 'this user consented'; match redirect_uri by exact string with no wildcards and require re-registration on change; make state cryptographically random, single use, short lived, and set its cookie or session only after consent is approved, since setting it earlier renders the consent screen ineffective; and protect the consent page with CSRF defenses and frame-ancestors or X-Frame-Options.
  6. Likely follow-ups: how does this relate to token passthrough? Passthrough is the downstream consequence of failed audience validation, while the confused deputy is code hijacking from missing consent; both stem from a server deciding on someone's behalf without confirming who that someone is. And how do I know whether this applies? One test: has my server ever obtained third-party authorization on a user's behalf.

  分析过程 · 先想清楚再作答

  1. 这题在筛 OAuth 的实战经验。能背出「混淆代理就是代理被骗着用自己的权限做事」只算入门，面试官要的是这条链在 MCP 里的具体形状。
  2. 先把角色摆清：出事的是**代理型服务端**——它对 MCP 客户端是服务端，对第三方 API 是一个 OAuth 客户端。它自己不是被攻破的那个，它是被利用的那个。
  3. 然后列四个必须同时成立的条件，少一个就打不成：代理对第三方用**静态 client id**（所有用户共用一个）；代理允许 MCP 客户端**动态注册**，各自拿到自己的 client id；第三方授权服务器在用户首次同意后**设了同意 cookie**；代理在转给第三方之前**没有做按客户端的同意确认**。
  4. 再串攻击链：攻击者先向代理动态注册一个客户端，redirect_uri 填自己的地址；把构造好的授权链接发给用户；用户浏览器带着上次留下的同意 cookie 去第三方，第三方认出静态 client id 加 cookie，**跳过同意页**直接发授权码；授权码回到代理，代理换成 MCP 授权码，按注册时那个恶意 redirect_uri 回跳，码落到攻击者手里；攻击者拿它换令牌，冒充用户访问。**整条链上用户什么都没同意过**——那个 cookie 是他上次正常授权时留下的。
  5. 防法要按规范的措辞答：代理型服务端**必须**实现按客户端的同意，而且这次同意必须发生在**转给第三方之前**。配套四条：同意记录按「用户加 client id」存，不是只记「这个用户同意过」；redirect_uri 精确字符串匹配、不做通配、改了就要重新注册；state 用安全随机数、单次使用、短过期，并且**同意通过之后才落 cookie 或会话**（提前落等于同意页形同虚设）；同意页要有 CSRF 防护并禁止被 iframe 内嵌。
  6. 可预期的追问一：这和令牌转发什么关系？令牌转发是受众校验失败的下游后果，混淆代理是同意确认缺失造成的授权码劫持，根子都是「服务端替别人做了决定却没确认这个别人是谁」。追问二：我怎么知道自己要不要管这一节？判据一句话——我的服务端有没有替用户去第三方要过授权。没有就整节不适用，有就是必须做。

  Key points

  • The victim is a proxy server: a server to the MCP client, an OAuth client to the third party
  • Four conditions must coincide: static client id, dynamic registration, a third-party consent cookie, and no per-client consent
  • The pivot is the third party skipping consent on the cookie, sending the code to the attacker's redirect_uri
  • Per-client consent must precede forwarding; redirect_uri matched exactly; state single use, short lived, and stored only after approval

  答题要点

  • 受害者是代理型服务端：对客户端是服务端，对第三方是一个 OAuth 客户端
  • 四个条件同时成立才打得成：静态 client id、允许动态注册、第三方有同意 cookie、缺少按客户端的同意
  • 攻击链的关键一步是第三方认出 cookie 跳过同意页，授权码按恶意 redirect_uri 落到攻击者手里
  • 必须在转给第三方之前做按客户端的同意；redirect_uri 精确匹配；state 单次短过期且同意后才落