绑定第三方oauth账号登陆的安全风险

昨天在乌云刷了几个oauth使用不当的漏洞，见上图。当我在修复方案中写下“做好csrf防护”的时候，也就意味着这个漏洞修复后，当csrf防护被突破了，你的账号还是会被盗。这显然有点问题，csrf防护君承受的责任有点重了，社会不能这样下去

oauth认证大多用于无需用户名密码就可从服务方获取数据或数据的操作权限。所以，第三方网站，你获取授权后用它来发微博我理解，你用它做用户注册的数据导入我可以理解，甚至你用它做SSO的单点登录我也可以理解。但是，网上很多网站常用的一种架构，我不理解，那就是

“一个网站，已经有了自己的账号，却还要绑定一个第三方账号来用于登录。或者是，用户在使用第三方账号登录后，引导用户设置完本站账号和密码后，仍然保留着第三方账号用于登录或支持换绑第三方账号用于登录”

上面的这种架构问题在哪呢

1、整体安全性的降低

你的系统不出漏洞的概率是70%，你绑定的第三方站不出漏洞的概率也是70%，那么你俩同时不出漏洞的概率就是49%了，就是说这个系统账号体系出现漏洞的概率超过一半了。当你绑定了三四个第三方账号后，你的账号想不被盗都难了

2、授权方式很容易被攻击

认证用户身份的方式，主流的有三种。用户的密码，认证cookie，单点登录。主流的浏览器端漏洞有xss、csrf等等。让xss获取不到我们的用户身份，应该是账号防护的底线

当我们防御合理的时候，可以让xss等主流的前端漏洞无法进入我们的账号。比如，xss无法获取我们的密码，除了极端的钓鱼。xss无法获取我们的httponly的cookie。单点登录的设计可能问题多点，但只要我们方案合理，xss也无法获取我们单点登录的凭证。具体漏洞案例和推荐方案可以参考

文章《get来的漏洞》//drops.wooyun.org/web/7112

PPT《我的通行你的证》 //pan.baidu.com/s/1bnsjoM7

但当我们授权第三方账号登录的时候，这个绑定授权操作是容易被XSS和CSRF攻击的。本来xss是无法获取httponly cookie，无法进入我们账号的，但却可以模拟这个绑定授权操作，去关联攻击者的账号，而进入我们的账号。甚至csrf防护没有或防护不合理的话，连xss都不需要就可以进入我们的账号。那么这里就成了我们账号防护体系的短板，httponly的cookie也失去了它的意义

我觉得合理的oauth使用方式

1、仅用于用户注册时的数据导入，引导完用户注册设置完密码后。尽量废除第三方账号的登录。如果非要保留，起码不能有换绑等操作，易被攻击

2、本站已有的账号，可以绑定微博等第三方账号，但只能用于发微博等使用微博服务的需求，不能用于用户登录

3、用户在本站没有账号的情况，可以用第三方账号来直接登录，相当于把oauth当成单点登录来用。但前提是第三方站的安全需求级别要比本站高，我们才可以把它当成一个sso。但不推荐此方式，因为oauth把认证凭证直接以get方式传递给了我们，这种设计是有安全风险的。作为一个web系统的sso，oauth是不够安全的，参见上面的两篇资料

为什么上面那种架构会流行

为了方便用户不用输入用户名密码？那就是单点登录的需求，那为什么还要引导用户去设置密码？

为什么要在一个已有用户名和密码的账号上做这个？需要微博的登录态？那为什么不把自己的账号做成登录后记住状态的？

觉得用户记不住自己站的密码，但会记得大站的密码？想同时支持密码和单点登录？OK，这点我稍微能理解，但成本是不是有点大了？

绑定微博只是为了分享微博？那为什么要支持登录？

。。。。。

中国的传统文化博大精深，希望有相关的产品设计人员来帮忙解答下