OAuth 漏洞与攻击模式

OAuth 授权服务器必须严格验证 redirect_uri 参数。如果服务器允许前缀匹配或通配符匹配（例如接受任何以 "https://app.example.com" 开头的 URL），攻击者就可以构造授权请求，将重定向目标设为 "https://app.example.com.attacker.com/steal"，或设为合法域上的开放重定向，从而窃取授权码。

如果没有 CSRF 防护，攻击者可以发起 OAuth 流程，诱骗受害者的浏览器完成授权。受害者会在不知情的情况下授权攻击者的客户端。"state" 参数（RFC 6749）可以防止这种攻击：客户端生成随机 state，将其包含在请求中，并在回调中验证两者是否匹配。不匹配时，流程将被终止。

在移动平台上，恶意应用可以注册与合法 OAuth 客户端相同的自定义 URI 方案，并拦截用户完成身份验证后重定向的授权码。PKCE（RFC 7636）提供了完整的防御：没有流程开始时由合法应用生成的代码验证器，被拦截的代码就毫无用处。

当 ID 令牌或访问令牌包含在 URL 片段或查询参数中时，从该页面进行后续导航会在 Referer 标头中包含该 URL，从而可能将令牌泄露给第三方分析脚本或 CDN 提供商。始终使用通过后通道传递令牌的授权码流程，避免令牌出现在 URL 中。

当客户端支持多个 OAuth 提供商时，混淆攻击会诱骗客户端将从提供商 A 获取的授权码发送到提供商 B 的令牌端点。客户端必须验证 ID 令牌中的 "iss" 声明，并使用 state 参数或 JARM（JWT 保护的授权响应模式）将回调绑定到发起该流程的特定提供商。

服务器端请求伪造（SSRF）攻击针对那些向 redirect_uri 发起服务器端 HTTP 请求的 OAuth 实现。如果授权服务器获取 redirect_uri 进行验证，攻击者就可以提供内部 IP 地址（例如 http://169.254.169.254/latest/meta-data/），从而访问云实例元数据或内部服务。基于严格允许列表的 redirect_uri 验证可以防止这种攻击。

许多应用使用 OIDC ID 令牌中的电子邮件声明来关联不同提供商的账户。如果攻击者控制的电子邮件地址与受害者在另一个提供商处的账户相匹配，攻击者就可以使用该电子邮件地址在其他提供商处注册，并获得对受害者账户的访问权限。防御方法：仅根据 (iss, sub) 对关联账户，绝不要仅根据电子邮件地址关联。

JWT 算法混淆攻击利用了信任 "alg" 标头并据此选择验证算法的实现。攻击方法：将 "alg" 从 "RS256" 改为 "HS256"，并使用服务器的公钥作为 HMAC 密钥对令牌签名（因为公钥是公开的）。防御方法：始终在验证代码中明确指定预期算法，绝不要信任令牌标头中的 alg 声明。

攻击者注册名称和徽标看似合法的恶意 OAuth 客户端，然后向目标发送网络钓鱼链接。受害者看到的是由 Google、Microsoft 等托管的真实 OAuth 同意页面，但对应的是恶意应用，并会授予其访问权限。防御方法：验证 client_id 是否对应预期应用；Google 和 Microsoft 为合法应用提供客户端验证计划。

当客户端获得的令牌拥有比用户授权范围更广的权限时，就会发生作用域升级。如果在令牌端点跳过作用域验证、在不同请求之间缓存合并后的作用域，或者未验证已签发令牌中的作用域没有超出已授权作用域，都可能通过 OAuth 导致权限提升。

可通过以下措施防御 OAuth 实现：使用精确匹配的 redirect_uri 验证；要求所有公共客户端使用 PKCE；验证 state 参数以防止 CSRF；根据 (iss, sub) 而不是电子邮件地址绑定 ID 令牌；明确指定预期的 JWT 算法；请求最小作用域；使用短期访问令牌并进行刷新令牌轮换；审查同意页面的外观，以防范品牌冒充风险。

关键的 OAuth 攻击包括：通过宽松的 redirect_uri 验证实现开放重定向（使用精确匹配）；因缺少 state 参数导致 CSRF；移动平台上的代码拦截（通过 PKCE 缓解）；URL 中的令牌泄露；多提供商设置中的混淆攻击（验证 iss）；通过服务器获取 redirect_uri 实现 SSRF；电子邮件声明冲突（使用 iss+sub）；JWT 算法混淆（固定预期的 alg）；以及通过伪造同意页面实施网络钓鱼。