[UPDATE]号称影响10亿App的OAuth2.0使用缺陷

说 OAuth2.0 漏洞/这个协议不安全的人,把头伸过来下,砖头准备好了。

Black Hat 的有关 Paper:

《OAuth User Profile Attack – How to Sign into One Billion Mobile App Accounts Effortlessly》

本质问题在于一些 App 在使用 OAuth2.0 协议时,(估计为了简单)使用的是 Implicit Flow 模式,然而并没严格按照协议的要求去实现,导致可能出现的劫持攻击。这并不是说 OAuth2.0 本身有漏洞或这个协议本身不安全,就好像两年多前的心脏出血漏洞,问题不在于 SSL 这个协议本身,而在于其某种实现方式(OpenSSL)有缺陷。一些媒体文的专业性一直是被诟病的,搞安全的人不要轻信媒体文。

结论与建议看 Paper 的倒数3、2页。

补充说明:

这种攻击的出现,只能说明相关开发文档没写清楚及 OAuth2.0 协议本身的实现上有缺陷(没做好应有的安全校验),这让我想起两年多前的 OAuth2.0 劫持缺陷,当时劫持的是目标网站(如知乎)的目标用户(如黄继新)的账号权限,配合了 CSRF,拿到黄继新的 Access Token,最终控制了他的账号。不过这个议题的问题不一样,可以认为是用你事先准备好的恶意账号去绑定目标 App 的目标用户的账号权限,既然是针对 App 的攻击,那辅助技巧就不大一样了(不像之前用 CSRF 等前端 Hack 技巧),所以我还在琢磨作者说的“Effortlessly”(不费力)是怎么个不费力呢?

欢迎讨论。


[UPDATE]2016/11/7

由于上面 Paper 提到了 Sina,我向微博安全团队的负责人要了相关细节(Paper 团队的研究确实很细致,数据证明方式也是耳目一新,这很难在工业界看到。由于漏洞的敏感性,这些细节暂时不做公布,可以说的是这些细节比上面公布的 Paper 要多得多)。这些细节验证了我上面的一些说法,真实利用上比起两年多前那种直接“偷” Access Token 的方式是要麻烦的,但我还是留个小心眼吧,很多时候漏洞是一回事,利用又是另外一回事,尤其是遇到猥琐流。

注:早年,我们称搞前端 Hack 的人为猥琐流,因为奇技淫巧确实太多,当年的很多奇技淫巧现在偶尔还能被看到拿出来重讲的,这个时代还在如火如荼发展呢:-)

OAuth 及其他类似的认证授权机制(注意认证和授权的区别)在理解上确实复杂,这导致如果没简洁完善的开发文档来参考+高人安全架构来指导,确实容易出问题,大问题…

2 comments

  1. 什么时候能有一篇更具体一些的文章呢?Paper中有提到替换userId,但是整个链路都是https的,如何替换呢??即使控制了域名也做不到啊???

    1. 那仅是个demo,Paper里特别提的那种风险我也说了利用上也许麻烦,我更感兴趣的是整个过程多个环节里的问题

发表评论

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据