3

在 PKCE 中,我了解 code_verifier 用于生成代码质询,稍后此 code_verifier 值由授权服务器验证以完成 PKCE 过程。

这个 code_verfier 值有多敏感?这个值是否必须保密?如果这个值被泄露,对手可以执行什么攻击?

4

2 回答 2

3

code_verifier确实是敏感的:它是客户端在调用令牌端点时证明它是首先发起授权请求的机制。

这个值应该保密,见下文。

泄漏它将允许攻击者在调用授权服务器的令牌端点时冒充(公共)客户端,从而获得打算用于真实客户端的令牌。

请注意,即使不使用任何(散列)转换,code_verifier而是像plaincode_challenge授权请求中那样发送它,对于能够拦截到重定向 URI 的回调的攻击者来说,它仍然会变得困难,因为他还必须拦截传出请求。

但一般来说,code_verifier应该用 SHA256 散列到 中,code_challenge所以即使在拦截请求时,攻击者也无法推断出code_verifier.

于 2019-04-10T17:18:27.233 回答
0

来自RFC 第 1 节

OAuth 2.0 [RFC6749] 公共客户端容易受到授权码拦截攻击。

在这种攻击中,攻击者在不受传输层安全 (TLS) 保护的通信路径中截获从授权端点返回的授权代码,例如客户端操作系统内的应用程序间通信。

一旦攻击者获得了对授权码的访问权,它就可以使用它来获取访问令牌。

...

为了减轻这种攻击,这个扩展使用了一个动态创建的加密随机密钥,称为“代码验证器”。为每个授权请求创建一个唯一的代码验证器,并将其转换后的值称为“代码挑战”,发送到授权服务器以获取授权代码。获取到的授权码然后​​与“验证码”一起发送到令牌端点,服务器将其与之前收到的请求码进行比较,以便执行客户端对“验证码”的所有权证明。这可以作为缓解措施,因为攻击者不知道这个一次性密钥,因为它是通过 TLS 发送的并且无法被拦截。

这里的关键短语是:“客户端拥有'代码验证器'的证明。这可以作为缓解措施,因为攻击者不会知道这个一次性密钥,因为它是通过 TLS 发送的并且无法被拦截。”

TL;博士:

代码质询+验证器对是证明请求身份验证令牌的客户端与首先请求授权代码的客户端相同(或受信任)的关键。如果代码验证器被泄露,那么 RFC 中提到的攻击(本质上是利用串扰来冒充合法应用的恶意应用)不会得到缓解,因此 PKCE(防止此类攻击)的目的被挫败。

于 2019-11-13T21:29:25.967 回答