最近要开始校招了，中午的时候室友说某在线测评网站做得真是坑，不小心调了个音量结果就balabala说”请不要离开当前页面”~~~我就去注册了一个账号测试了一下，然后溜达溜达着，发现网站提供第三方账号登录，于是乎，就有了这篇文章，如果想对Oauth 2.0更一步的了解，请移步理解OAuth 2.0

网站在实现用户给予网站授权的时候，采用的最复杂的授权码模式，授权码授权模型如下:

• （A）用户访问客户端，后者将前者导向认证服务器。
• （B）用户选择是否给予客户端授权。
• （C）假设用户给予授权，认证服务器将用户导向客户端事先指定的”重定向URI”（redirection URI），同时附上一个授权码。
• （D）客户端收到授权码，附上早先的”重定向URI”，向认证服务器申请令牌。这一步
• 在客户端的后台的服务器上完成的，对用户不可见。
• （E）认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。

A步骤中，客户端申请认证的URI，包含以下参数：

• response_type：表示授权类型，必选项，此处的值固定为”code”
• client_id：表示客户端的ID，必选项
• redirect_uri：表示重定向URI，可选项
• scope：表示申请的权限范围，可选项
• state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。

接下来，我抓包拦截看了看网站使用微博账号授权登录的请求包和返回包：

你会看到，网站没有使用state参数防止CSRF，在测试的过程中，也没有其它的方法防止CSRF，受害者如果访问了返回包中的重定向地址，攻击者的微博就和受害者的账号绑定起来，就可以使用微博直接登录受害者账号了。

另外一点，查看了一下redirect_uri,发现这里也是有问题的

当我直接修改前面的参数的时候，新浪提示redirect_uri不匹配，然后我把domain后面的值修改了，直接跳转到了我的网站

网站应该是提供了一个跳转的功能，新浪微博应该只是匹配了url前面的部分，没有对后面的参数进行限制，因此这里也存在漏洞。

总结：网站使用第三方登录的时候，应该是存在两个地方的漏洞，第一个是CSRF导致的绑定劫持，另外一个是redirect_uri导致的授权码劫持

原文链接:http://ecma.io/764.html