从知乎被黑说说OAuth这事

刚好从Twitter开始推开放API蚂蚁就开始接触OAuth,后续又有些项目用新浪微博开放平台,还写了几个OAuth登陆QQ、百度、豆瓣的代码。

@李普君OAuth 漏洞预警:黄继新,你的帐号被黑啦

提到的防御蚂蚁觉得有点不科学,想和@李普君 探讨一下。,因为这个被黑事件的原理看起来更像是知乎的工程师实现OAuth时检查state参数的逻辑有漏洞,任何用户可以直接登录微博帐号对应的知乎帐号。

state: 用于保持请求和回调的状态,在回调时,会在Query Parameter中回传该参数。开发者可以用这个参数验证请求有效性,也可以记录用户请求授权页前的位置。这个参数可用于防止跨站请求伪造(CSRF)攻击

参阅:新浪微博Oauth2/authorize

state:非必须参数,用于保持请求和回调的状态,授权服务器在回调时(重定向用户浏览器到“redirect_uri”时),会在Query Parameter中原样回传该参数。OAuth2.0标准协议建议,利用state参数来防止CSRF攻击。

参阅:百度OAuth > Authorization Code授权

为了防止CSRF攻击,在请求人人OAuth 2.0 Authorize Endpoint的时候,需要使用state传递一个用户的唯一标识。授权页面在跳转到rediret_uri时这个标识会被原样返回,以保证授权流程中的安全性。人人网强烈推荐使用这种方式来保持用户的状态,防止CSRF攻击。

参阅:人人网OAuth 2.0 简介

这次攻击本质上是CSRF攻击,需要在Authorization Code的有效期内进行,通常为10分钟。

理论上检查了state参数,检查对应的知乎用户id绑定的session,即使重定向里的code被泄露,攻击者没有应用的secret也是无法实现攻击的

看起来知乎的帐号体系流程上有bug。

更新:

一些补充资料:

第三方应用不能假设授权重定向页面不被泄露,因为它是HTTP GET的,所有的参数很容易被窃听到。最重要的是检查state的逻辑,因为开发平台文档的简化和第三方工程师的粗心,检验state的逻辑如果不在后端有session检查,就会有漏洞。知道创宇给出的防御建议撇清了第三方应用的责任,我觉得是不恰当的。真正重要的是,第三方要假设授权重定向这个页面可能被泄露,然后根据这个安全边界来校验state参数。

原则上,即使code被泄露,攻击者不知道secret和对应的state也是无法实现攻击的。

更新:

最近刚好阅读了一篇详尽的OAuth安全手册OAuth Security Cheatsheet,列举了常见的OAuth漏洞,鉴于OAuth使用的广泛性,强烈推荐感兴趣的工程师们读一读。

喜欢这篇文章就分享到微博吧!
留言请发送到
微信公众帐号
“技术派”

修订历史:


知识共享许可协议

关注@好看簿的蚂蚁

探讨技术、设计、人文和商业
相关的创业话题