[译]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]