[译]Pnig0s_小P
如果网站使用了OAuth 登录机制,那么有一个简单的方法能让攻击者登录进其他用户的账户,保护机制不会有任何作用,而且人们不会考虑到OAuth机制也可以用与身份验证。
OAuth2是一个身份授权框架。现在非常流行。尽管现在很多人对OAuth并没有足够的了解以至于他们无法写出适当且安全的代码。
OAuth1和OAuth2是不兼容的,一些服务使用前者,而另一些则使用后者,关于OAuth网络上充斥着大量的坑爹的不靠谱的介绍文章。我花了几个小时通读了一遍OAuth2规范文档并发现了一些有意思的地方。其中一点将在这篇文章中展开讨论。
下面是使用OAuth机制进行登录的网站的一个非常危险但是又很普通的漏洞。
下面是一些理论:
1,response_type = code是服务端的授权流程,应该在必要的时候使用,要比response_type = token更安全。授权服务器返回‘code’以及用户的User-Agent,然后客户端将这些内容与用户的证书信息一同发送来获取‘access_token’。回调信息会在用户授权后用到,像这样。site.com/oauth/callback?code=AQCOtAVov1Cu316rpqPfs-8nDb-jJEiF7aex9n05e2dq3oiXlDwubVoC8VEGNq10rSkyyFb3wKbtZh6xpgG59FsAMMSjIAr613Ly1usZ47jPqADzbDyVuotFaRiQux3g6Ut84nmAf9j-KEvsX0bEPH_aCekLNJ1QAnjpls0SL9ZSK-yw1wPQWQsBhbfMPNJ_LqI
2,我要提醒你的是,通常来讲OAuth是一个授权的机制,并不是认证的机制。你可能会问两者有什么区别呢:OAuth协议只是给了你使用提供者服务器上用户资源的权限。不过经常客户端会根据‘profile_info’认证你的权限,因此,我们也可以视它为一种认证框架。
会被恶意攻击的条件:使用OAuth机制+能够向配置中添加OAuth提供者的信息
一步一步来攻击OAuth:
1,选择符合上述条件的“客户端”-开始认证过程-点击“Add OAuth Provider Login”。你需要从提供商那里得到回调但先不要访问它。这有一定的难度-所有现代的浏览器都会自动跳转。我推荐使用bundle FireFox +NoRedirect
2,不要访问下面的URL(http://pinterest.com/connect/facebook/?code=AQCOtAVov1Cu316rpqPfs-8nDb-jJEiF7aex9n05e2dq3oiXlDwubVoC8VEGNq10rSkyyFb3wKbtZh6xpgG59FsAMMSjIAr613Ly1usZ47jPqADzbDyVuotFaRiQux3g6Ut84nmAf9j-KEvsX0bEPH_aCekLNJ1QAnjpls0SL9ZSK-yw1wPQWQsBhbfMPNJ_LqI#_=_),仅仅把它放在<img src=”URL”>或<iframe>标签下保存起来就可以了。
3,现在你需要做的是让用户(某一特定的用户或者target.com上随机的用户)发送HTTP请求到你的callback
URL。你可以强制他们访问example.com/somepage.html,其中包含<iframe src=URL>,给他的博客留言板留言,发送一个邮件或者私信,不管怎样。目标必须在发送HTTP请求时处于登录状态。
做得好,你的oauth账户已经和目标在site,com上的账户连接上了。
现在,按下“Log In with
that OAuth Provider”-你现在直接可以登录到目标在site,com的账户上了。享受吧:读取私信,发送评论,更改支付细节额,做任何你想做的事情。事实上这个目标账户已经是你的了
当你玩儿够了之后你只要和那个OAuth提供商断开并登出就可以了。没有人知道究竟发生了什么,没有留下任何痕迹!
如何发现这个OAuth的脆弱性问题呢?
1,如果网站没有发送‘state’参数,并且‘redirect_uri’参数是静态的没有包含任何随机哈希值-那么它受影响。
2,我知道的至少10+个流行的网站收到这个问题的影响:比如pinterest,digg,soundcloud,snip.it,bit.ly,stumbleupon等等。如果你知道更多的网站请一定要通
过homakov@gmail.com联系我.
3,还有Rails+Omniauth也会收到该问题的影响。玩儿的愉快噢(大概有23300个搜索结果)。
[via:Egor Homakov]
Andy 2018-02-08
FB客服 2018-01-12
FB情报组 2015-03-12
Sphinx 2016-08-31
已有 18 条评论
看了三遍,意思是:这个就是诱惑其他人先登入后,在使用相同的认证去登入他的账户啊?
其实就是clickjacking。。。
@root 我发现很多人看完了就喜欢评论,其实就是这个,其实就是那个。。其实没什么难的。那我觉得安全也其实就是那么多东西,关键是你能不能想到和实践出来,否则再“其实”也不是你的,你也进步不了。
@pnig0s 同意
@pnig0s 有些地方不是很明白。
@pnig0s 你理解错我的意思了,我指的"其实"并没有说觉得"低看"的意思也不敢,我是本着学习的心态看的。
感谢分享。
@pnig0s @pnig0s 原文的地址有吗?有些部分没有能完全理解,比如你提到的几个按钮,它们是怎么个流程?
@pnig0s http://homakov.blogspot.com/2012/07/saferweb-most-common-oauth2.html
回4楼 这是原文
@ooxx 谢了,但是第三个流程截取的内容不一样,对于那两个按钮的具体作用还是不清楚
@pnig0s 求原文链接地址!
@root 这是CSRF好吧,怎么是clickjacking呢
这个攻击需要有几种可能:假设前置条件为state考虑不周且回调代码有漏洞、会覆盖绑定状态,那么攻击必定会生效,但这样的话利用就不稳定了,因为随时会有人覆盖掉绑定状态。
接上,假设前置条件为(1)受害者在site.com有登录状态且未绑定第三方oauth帐号;(2)攻击者第三方oauth帐号没有绑定site.com任一账号;(3)site.com回调代码中绑定和登录是写在一起的,但不会覆盖绑定状态;(4)state考虑不周。那么就出现只能绑定一个site.com账户、可达到定向攻击效果但撒不了网
回调链接一直有效?用户授权之后 一直到 应用向服务商换取accessToken应该有个有效期吧,或者有IP验证之类的
一切只为token!
什麼 UI redressing 樣的垃圾,我看不到任何 X-frame-options 東西!
印象中code大多是有十分钟或者更长的有效期,不过这也依然是一个很严重的问题了。
前段时间OAuth组织原领导者提到的在安全经验不足的设计者中会造成的危险,大概包括这个。
用户凭证(code) 是个用户绑定的呀,他点了你的code,应该是他获取了你的授权啊,我理解错了吗?