OAuth 2.0流程中使用PKCE但缺失State参数时如何发生CSRF攻击

无state参数时的CSRF攻击实施步骤 #

我们以对接OAuth2授权的第三方网页应用NoteApp为例，该应用启用了PKCE机制但未传递state参数，攻击可按如下流程实施：

• 攻击者首先在自己的设备上打开NoteApp，触发OAuth2授权流程：NoteApp生成随机code_verifier和对应的code_challenge，带着code_challenge跳转到授权服务器（比如账号授权页）
• 攻击者使用自己的账号完成授权，此时授权服务器会生成绑定了攻击者账号、以及本次code_challenge的authorization_code，回调到NoteApp的回调接口，攻击者提前拦截记录下这个携带攻击者authorization_code的完整回调URL
• 攻击者构造钓鱼链接/页面，诱导已经登录了自己NoteApp账号的目标用户访问上述回调URL
• 目标用户触发请求后，NoteApp后端收到回调请求，由于没有state参数做请求合法性校验，会直接取出请求中的authorization_code，搭配自己之前存在用户会话里的code_verifier向授权服务器兑换access_token
• 由于这个authorization_code本身就是和当前客户端的code_challenge配对的，PKCE校验会完全通过，NoteApp会成功拿到攻击者账号的access_token，并将当前登录的目标用户的NoteApp会话和攻击者的第三方账号绑定
• 最终目标用户的所有操作数据都会同步到攻击者的账号下，攻击者可以直接登录查看、篡改所有用户数据

已使用PKCE仍需state参数的必要性 #

PKCE和state的设计目标完全不重叠，不存在互相替代的关系：

• PKCE的核心作用是解决公共客户端（SPA、移动端APP等无法安全存储client_secret的客户端）的授权码盗用问题：它校验的是发起授权请求的客户端和兑换授权码的客户端是否为同一主体，只能防止授权码被中间人拦截后盗用，完全不涉及回调请求的发起者身份校验
• state的核心作用是关联授权请求和回调请求的上下文，校验回调请求是否为用户主动发起的合法请求：它可以防止攻击者注入恶意的、绑定了攻击者身份的授权码，避免用户会话被绑定到攻击者账号的CSRF风险

注意：哪怕启用了PKCE，只要缺失state参数，上述CSRF攻击就可以成功实施，两者是OAuth2授权流程中并行的安全机制，不存在替代关系。

内容的提问来源于stack exchange，提问作者qazwsx123