1. 题干与适用场景
一个服务接收读取或写入资源的请求。服务本身拥有较宽权限，但调用方只能获得有限能力。如果服务接收调用方控制的路径或资源 ID，再用自身权限执行操作，攻击者可能诱使它完成调用方本不能直接完成的动作。AWS 将这类问题称为 confused deputy。
能力式安全把权限放进明确的引用或令牌：它同时指向资源并携带使用权限。这个 capability 应不可伪造、范围受限，并只传给确实需要的代码。题目考察安全模型，不限定云厂商或编程语言。
2. 面试官考察点
- 权限推理： 能否区分认证、授权与持有被委托权限。
- 威胁建模： 能否指出代理、混淆输入、高权限动作和攻击者控制边界。
- 最小权限： 是否把 capability 收缩到单个操作、对象、租户或时间窗口。
- 生命周期判断： 能否解释撤销、过期、审计和泄露，而不声称 capability 能解决一切。
- 取舍表达： 能否在真实运维约束下比较 capability 与环境身份和策略检查。
弱回答只会说“使用 token”。强回答会说明 token 授权什么、如何约束，以及泄露或必须撤销时会发生什么。
3. 回答前需要澄清的问题
代理是本地代码、服务还是云角色？
模式相同，但边界不同。库可能无意继承文件句柄；服务可能使用工作负载身份；云角色可能被诱骗去访问跨账户资源。先说清楚谁拥有宽权限。
委托的是哪个资源和操作？
明确是读、写、追加、删除、调用还是组合操作。针对单个对象和方法的 capability 比通配资源名称更容易审计和撤销。
撤销和泄露要求是什么？
询问是否需要立即撤销、离线使用、多租户隔离或不可抵赖审计。这些约束决定使用内存引用、签名令牌、租约、代理或中心策略检查。
4. 30 秒回答框架
“混淆代理发生在低权限调用方提供资源名称，而高权限服务使用自身权限执行操作，却没有把请求绑定到调用方明确获授的范围。能力式安全让权限显式化：传递不可伪造的引用或令牌，限定一个资源和操作，并要求代理只能使用该引用。我会在委托时收缩 capability，把它绑定到租户和受众，按风险设置过期或撤销，并记录签发和使用。Capability 能减少环境权限和混淆代理风险，但泄露、重放、恢复和审计仍需单独设计。”
5. 分步骤深入解答
步骤一：区分身份与权限
认证回答谁在调用，授权回答该身份按策略能做什么。Capability 是具体的带权限引用：持有它并通过不可伪造性校验，就获得特定动作。它可以和身份并存，但不依赖每次内部调用都重新读取全局环境身份。
步骤二：画出混淆代理流程
假设报表服务能以工作负载身份读取任意文件。用户发送 file=/reports/other-tenant.csv。如果服务只验证请求已认证，它就成了代理：用户提供名称，服务花费更大的权限。缺少的绑定是“该调用方确实被授予这个对象的权限”。
步骤三：用有范围的权限替代名称
改为由有权所有者创建某个报表和操作的 capability，例如租户 A 的只读权限，直到指定时间。调用方把 capability 交给服务。服务解引用它或交给代理，不把任意路径转换成权限。object-capability 研究将这种模式描述为把访问权编码到对象中，限制对象之间的交互。
步骤四：委托时收缩权限
组件继续委托时，应产生更弱的 capability：减少方法、限制子对象、缩短寿命、绑定租户或增加速率限制。不能因为下游方便就扩大 capability。只暴露 readMetadata() 的包装器比传递可写可删的文件句柄更安全。
步骤五：处理令牌和重放
跨进程传递时，使用签名、绑定受众的保护引用，或由代理签发句柄。包含资源、动作、租户、签发者、受众、过期时间和需要防重放时的唯一 ID。使用前校验完整性和上下文。加密只能隐藏内容，不能单独保证范围或阻止重放。
步骤六：规划撤销和恢复
纯内存 capability 易传递，却难以全局撤销。租约、短过期、通过撤销存储间接引用或轮换密钥，分别在即时控制、可用性和延迟之间取舍。令牌泄露后，应撤销句柄或绑定，必要时轮换相关密钥并检查日志；删除用户记录不一定会让已签发 capability 失效。
步骤七：保留审计和策略边界
记录谁签发 capability、范围是什么、哪个代理使用以及结果。即使 capability 是授权原语，也要保留身份上下文以便追责。高风险动作可叠加租户状态、法律保留或 step-up authentication 等策略检查。
6. 高质量示范回答
“混淆代理是权限错配：调用方提供资源名称，但服务拥有更大权限并执行了操作。服务把名称当成授权，因此被混淆。AWS 在跨账户和跨服务场景中记录了这个模式。
我会传递明确的 capability：不可伪造的引用或受保护令牌，限定租户、对象、操作、受众和过期时间。代理只能使用这个 capability；继续委托时创建更弱的子 capability。远程令牌要检查完整性、上下文和重放约束，并记录签发和使用。
撤销是关键取舍。敏感动作可以用短租约或可撤销句柄，但要接受查询成本。Capability 能减少环境权限并让权限流更可见，却不能消除泄露、恢复、审计和策略要求。我会测试跨租户访问、令牌重放、混淆名称和撤销竞态。”
7. 常见错误
- “认证通过就够了” → 让宽权限服务自行决定范围 → 把操作绑定到明确且受限的权限。
- “签名 token 自动就是 capability” → 忽略受众、操作、过期与重放 → 把完整性和范围分开校验。
- “登录检查后继续使用调用方路径” → 重现混淆代理流程 → 传递 capability 或代理句柄，而不是任意名称。
- “Capability 消除了授权策略” → 漏掉租户状态和上下文规则 → 对高风险动作叠加策略检查。
- “撤销没有成本” → 忽略分布式副本和离线使用 → 按需求选择租约、间接引用或过期。
- “隐藏所有身份上下文” → 让事故调查无法进行 → 审计签发者、主体、范围和使用事件。
8. 追问及应对
Capability 和 ACL 查询有什么区别？
ACL 查询从身份和资源名称出发，在使用时查策略。Capability 则沿数据流携带被委托权限。ACL 集中策略和撤销；capability 让权限显式并减少环境权限，但仍需处理生命周期和泄露。
Capability 可以被复制吗？
进程内引用通常能被持有它的代码复制，边界在于谁能收到以及是否收缩。远程令牌若不绑定通道、随机数、受众或短租约，也可能被重放。可复制性是要建模的风险，不代表令牌无害。
如何保护 capability URL？
把它当作 bearer 凭据：使用 HTTPS、窄范围、短过期、不可猜熵、受众绑定、速率限制，并从日志和 referrer 中脱敏。敏感或可重复动作应先一次性兑换可撤销句柄。
云系统哪里仍会出现混淆代理？
服务角色、构建运行器或存储代理接收用户控制的资源 ID，再使用宽角色就是典型场景。把请求绑定到资源策略、租户和目标动作；AWS 的跨账户指导就是具体边界例子。