OAuth授权的XSRF漏洞及其修复

标签: oauth 授权 xsrf | 发表时间:2012-11-24 08:00 | 作者:nospam@nospam.com (秩名)
出处:http://www.kuqin.com/jingyan/

或说前段时间 OAuth2.0 授权被人找出了个漏洞,各个开放平台都有影响,导致一阵恐慌。虽然后来发现其实是夸大其后果了,但也暴露出我们对这个经常用的协议仍一知半解的现状。所以花了点时间,整理了 OAuth1.0 和 2.0 的授权流程、以及其中的隐患和修复方案,供各位同学了解。由于本人也是临阵磨刀,难免疏漏,欢迎指点。

一、OAuth 1.0

a)OAuth1.0的授权流程为

OAuth1.0授权流程(配图取自 http://dev.t.qq.com/

其特点是请求request_token是需要传入app key和app secert, 而app secert是不能公开的, 因此只适合于服务器端授权。同时授权时的交互步骤比较多, 不够简便。

二、OAuth 2.0

a) OAuth2.0有两种授权方式

  1. Authorization code grant (Server Side),适合于有server端的应用授权
  2. Implicit grant(Client Side),适合于通过客户端访问的应用授权

b) Server Side的流程为

OAuth2.0 Server Side授权流程(配图取自 http://dev.t.qq.com/

其中用户在打开的登录页, 登录授权之后得到的是授权码(code), 之后由用户把code填入第三方的应用, 应用的server获取到code的之后, 由server向oauth换取accesstoken, 之后可以把token保存在 server上。

其中授权回调时app server返回的state是用来在请求accesstoken时, 验证这个换token请求是不是同一个用户发起的,授权服务器会把state的值原样的返回给app server。

c) Client Side的流程为

OAuth2.0 Client Side授权流程(配图取自 http://dev.t.qq.com/

其中,app直接把用户重定向到授权服务器登录, 用户登录之后app就能拿到token, 省却了跟app server的交互。但这里有个不太安全的地方, accesstoken是保存在客户端的, 有泄漏的风险。 由于oauth2。0已经放弃了使用app key和app secert来验证请求, 而app key是公开的。 因此只要攻击者拿到了用户的accesstoken, 就能调用api。

三、OAuth的XSRF攻击

a) OAuth 1.0

  1. 攻击者访问可靠的第三方站点(aaa.com), 在该网站发起OAuth认证流程, 保存包含request_token的授权URL, 但不定向到该URL所指的页面
  2. 把该URL发给受害者, 诱骗受害者点击
  3. 受害者点击URL打开授权页, 发现是可靠的站点, 而不会发现有潜在的隐患, 因此会进行授权
  4. 受害者授权之后, 攻击者就可以用上次保存的request_token, 直接走到授权的第5步, 用request_token即可换取到access_token, 之后就可以使用access_token 访问受害者的数据了。

b) OAuth 2.0 (Server Side)

  1. 攻击者访问可靠的第三方站点(aaa.com), 且该网站提供了绑定帐号功能, 在该网站使用攻击者自己的帐号account1 发起OAuth认证和绑定流程, 保存包含code的重定向URL1, 但不定向到该URL所指的页面
  2. 构造一个自动发起绑定请求的页面, 如创建一个img,src=”url1″。 然后把该页面URL2发给受害者, 诱骗受害者点击
  3. 受害者点击URL2时, 如果恰好在 aaa.com 登录了, 浏览器存有aaa.com的登录态, 这时就自动把受害者在aaa.com的帐号绑定到account1上了
  4. 攻击者现在只要用account1登录aaa.com, 就能访问到 受害者的数据。

c) OAuth 2.0(Client Side)

Client Side的授权流程本身没有该问题, 不过由于Client Side是设计来给没有server的移动应用使用的, 其获取的access_token是保存在客户端的, 因此这里有泄漏的风险。

四、XSRF修复

  1. 可以要求OAuth1.0 的方式升级到 2.0, 由于1.0跟2.0的协议相差较大, 因此会有不少迁移特别是调试的工作;
  2. 而OAuth 2.0 (Server Side)的方式, 可以要求app server必须对state进行验证, 从受害者发起的绑定请求, 由于他是中途进入的, app server上并没有保存相应的state, 这时server可以拒绝掉这次绑定请求。
  3. OAuth 2.0(Client Side)并没有这个问题, 可以不用修复。 重点在如何安全的保存access_token上。
  • 默认表情
  • 阿狸
发  布
  或游客留言
  • 默认表情
  • 阿狸
回  复
  或游客留言
www.kuqin.com
数据正在加载中...
无觅相关文章插件,快速提升流量

[ comments ]

相关 [oauth 授权 xsrf] 推荐:

OAuth授权的XSRF漏洞及其修复

- - 酷勤网-挖经验 [expanded by feedex.net]
或说前段时间 OAuth2.0 授权被人找出了个漏洞,各个开放平台都有影响,导致一阵恐慌. 虽然后来发现其实是夸大其后果了,但也暴露出我们对这个经常用的协议仍一知半解的现状. 所以花了点时间,整理了 OAuth1.0 和 2.0 的授权流程、以及其中的隐患和修复方案,供各位同学了解. 由于本人也是临阵磨刀,难免疏漏,欢迎指点.

OAuth 2.0 开放授权的那些事儿

- - SegmentFault 最新的文章
OAuth 2.0 协议是一种三方授权协议,目前大部分的第三方登录与开放授权都是基于该协议的标准或改进实现. OAuth 1.0 版本于 2007 年发布,2.0 版本则在 2011 年发布,其中 2.0 版本取消了所有 token 的加密过程,并简化了授权流程,但因强制使用 HTTPS 协议,被认为安全性高于之前的版本.

OAuth的改变

- lyxint - 火丁笔记
去年我写过一篇《OAuth那些事儿》,对OAuth做了一些简单扼要的介绍,今天我打算写一些细节,以阐明OAuth如何从1.0改变成1.0a,继而改变成2.0的. 在OAuth诞生前,Web安全方面的标准协议只有OpenID,不过它关注的是验证,即WHO的问题,而不是授权,即WHAT的问题. 好在FlickrAuth和GoogleAuthSub等私有协议在授权方面做了不少有益的尝试,从而为OAuth的诞生奠定了基础.

理解OAuth 2.0

- - 阮一峰的网络日志
OAuth是一个关于授权(authorization)的开放网络标准,在全世界得到广泛应用,目前的版本是2.0版. 本文对OAuth 2.0的设计思路和运行流程,做一个简明通俗的解释,主要参考材料为 RFC 6749. 为了理解OAuth的适用场合,让我举一个假设的例子. 有一个"云冲印"的网站,可以将用户储存在Google的照片,冲印出来.

oauth 认证心得

- 非狐外传 - python.cn(jobs, news)
OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准. 简易来说,就是我们可以在某一个第三方服务器,如:新浪,豆瓣,在用户授权,并且不透漏密码等信息给我们的条件下,访问和修改用户的资源. oauth的项目主页为:http://oauth.net/ ,现在国内很多网站的开放平台都采用了Oauth方式来进行授权.

OAuth学习笔记

- 宋大妈 - FeedzShare
来自: 标点符 - FeedzShare  . 发布时间:2011年08月29日,  已有 2 人推荐. OAuth(开放授权)是一个开放标准,允许用户让第三方应用访问该用户在某一网站上存储的私密的资源(如照片,视频,联系人列表),而无需将用户名和密码提供给第三方应用. OAuth允许用户提供一个令牌,而不是用户名和密码来访问他们存放在特定服务提供者的数据.

OAuth 2.0 工作流程

- - 企业架构 - ITeye博客
原文链接:http://www-01.ibm.com/support/knowledgecenter/SSELE6_8.0.0.3/com.ibm.ammob.doc_8.0.0.3/config/concept/con_oauth20_workflow.html%23con_oauth20_workflow?lang=zh.

GitHub - casinthecloud/cas-pac4j-oauth-demo: Demo webapps to test CAS/OAuth/OpenID/SAML client support and OAuth server support in CAS version >= 4.0.0

- -

基于PECL OAuth打造微博应用

- lostsnow - 火丁笔记
最近,国内主要门户网站相继开放了微博平台,对开发者而言这无疑是个利好消息,不过在实际使用中却发现平台质量良莠不齐,有很多不完善的地方,就拿PHP版SDK来说吧,多半都是用TwitterOAuth改的,一旦多平台集成,很容易出现命名冲突之类的问题. 既然官方SDK不给力,那我们只能发扬自力更生的革命精神了.