• 微信公众号:美女很有趣。 工作之余,放松一下,关注即送10G+美女照片!

如果攻击者操控了 redirect_uri,会怎样?

开发技术 开发技术 1周前 (06-11) 9次浏览

  读者在看这篇文章之前,请先了解 Oauth2.0 的 Authorization Code 授权流程,可以看 Authorization Code 授权原理和实现方法

 

  在 Token Enpoint 中,按照 Oauth2.0 的标准,需要传递一个 redirect_uri 参数。然而,代码却只对这个参数做检查,没有其他处理逻辑,这背后的原因是什么呢?这里,涉及到一种针对 redirect_uri 的攻击方法。

 

  我们还是用 A 来代表合作方,用 B 来代表鉴权方。我们知道,在合作开始之前,A 需要向 B 注册 redirect_uri 。假如 A 注册的是 a.com/*,也就是说,a.com 域名下的所有 path 都可以作为合法的 redirect_uri。而实际使用的时候,A 传递的是 a.com/recieve_code 这个 path。

  但是,攻击者通过某种方式,控制了 a.com 域名下的一个 path,比如 a.com/attacker,此时会发生什么呢?

 

  攻击者可以做以下事情:

  1,攻击者访问 a.com,登录,然后通过点击,触发授权流程

  2,此时 A 会打开授权页面,攻击者通过浏览器的地址栏,获取到了整个 url

  3,攻击者将 url 中的 redirect_uri 替换成 a.com/attacker,构建出一个新的 url

  4,攻击者通过某种方式,诱骗真正的用户点击新的 url

  5,用户打开授权页面,看到的都是正常的信息(B 即将授权给 A,以便 A 访问你在 B 的资源),因此点击授权

  6,code 被发送到 a.com/attacker,攻击者拿到 code

  7,攻击者手动通过浏览器访问 a.com/recieve_code?code=xxxx ,此时 A 会去兑换 access token,然后将这个 access token 跟攻击者的账号绑定在一起(A 可能把 access token 存在 session 里,也可能放在 db 里,不管怎么样,肯定是和当前登录的账号关联起来的)

  8,到这里,攻击者就可以访问真正的用户在 B 的资源

 

  下面用图来解释。

 

  首先,在授权之前,用户在 a.com 和 b.com 都是有账号的:

如果攻击者操控了 redirect_uri,会怎样?

 

  正常的授权流程完成后,应该是这个样子:

如果攻击者操控了 redirect_uri,会怎样?

 

  但是,经过攻击者这一波操作后,变成了这个样子:

如果攻击者操控了 redirect_uri,会怎样?

 

  那么,怎么防御这种攻击呢?

  方法就是,B 在生成 code 的时候,记录下来,这个 code 是发送给 a.com/attacker 的:

    code -> a.com/attacker

  然后,当 A 用 code 来兑换 access token 的时候,告诉 B,我这个 code,是从 a.com/recieve_code 收到的:

    code <- a.com/recieve_code

  B 一比较,就发现这个 code 被人为搬动过,于是拒绝兑换,就可以了。

  

  以上,就是 redirect_uri 这个参数背后的考量。有问题可以直接评论。


程序员灯塔
转载请注明原文链接:如果攻击者操控了 redirect_uri,会怎样?
喜欢 (0)