在带有 PKCE 的 OAuth 2.0 授权代码流中，什么阻止在第一次调用身份验证服务器时拦截代码质询? [英] In the OAuth 2.0 Authorization Code Flow with PKCE what prevents intercepting the code challenge on the first call to the auth server?
问题描述
想象一下这次攻击
- 攻击者拦截了对授权服务器的第一次调用，然后他们遇到了代码挑战.(图中的第 1 步)
- 攻击者现在使用授权代码拦截来自授权服务器的响应.(图中的第 2 步)
- 然后攻击者可以发布授权代码和代码验证器来获取访问令牌.(第 3 步)
参考这张图:流程:
问题
是什么阻止了攻击者拦截对授权服务器的第一次调用?这就是为了让授权码 + PKCE 比隐式流更安全.
What prevents the attacker intercepting the first call to the authorization server? This is what is meant to make authorization code + PKCE more secure than implicit flow.
也许调用是否被拦截并不重要，因为代码挑战是散列的，因此攻击者没有第二次调用所需的代码验证器.但是如果代码挑战没有被散列呢?
Perhaps it does not matter if the call is intercepted because the code-challenge is hashed and therefore the attacker does not have the code-verifier required for the 2nd call. But what if the code-challenge is not hashed?
推荐答案
PKCE 旨在解决从 URL 泄漏访问令牌/授权代码的威胁，与拦截 SSL 流量的攻击者相比，这种威胁相对容易:
PKCE is meant to address the threat of the access token / authorization code being leaked from URL, which is relatively likely compared to an attacker intercepting SSL traffic:
>
- 网址在地址栏中可见
- 网址保存在浏览器历史记录中
- 在本机平台上，可以注册多个应用程序以使用相同的自定义 URI 方案
也就是说，它建议代码质询是代码验证器的 SHA256 哈希值，因此即使攻击者拦截了代码质询，他们也无法在无法反转 SHA256 的情况下完成令牌交换.
That said, its recommended that the code challenge be a SHA256 hash of the code verifier, therefore even if the attacker were to intercept the code challenge, they would be unable to complete the token exchange without being able to reverse SHA256.
这篇关于在带有 PKCE 的 OAuth 2.0 授权代码流中，什么阻止在第一次调用身份验证服务器时拦截代码质询?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
