您现在的位置是:首页 > 密码破解

OAuth2.0的安全解析

作者:果E安全网时间:2021-04-16 14:49:27分类:密码破解

简介1.为什么要用OAuth2.0在一个单位中,可能是存在多个不同的应用,比如汽车制造企业会有财务的系统,4S店的销售系统,面向车主的论坛系统,还有ERP、OA、CRM系统等等,如果每个系统都用独立的账号认证体系,会给用户带来很大困扰,也给管理带来很大不便。所以需要设计一种统一登录的解决方案。比如我登陆了百度账号,进贴吧时发现已经登录了,进糯米发现也自动登录了。常见的有两种情况:1)

1.为什么要用OAuth2.0

在一个单位中,可能是存在多个不同的应用,比如汽车制造企业会有财务的系统,4S店的销售系统,面向车主的论坛系统,还有ERP、OA、CRM系统等等,如果每个系统都用独立的账号认证体系,会给用户带来很大困扰,也给管理带来很大不便。所以需要设计一种统一登录的解决方案。比如我登陆了百度账号,进贴吧时发现已经登录了,进糯米发现也自动登录了。

常见的有两种情况:

1)多平台登录,效果是可以用一个账号(比如QQ账号)登录多个不同的网站;多个网站多次登录,但是用户名密码一样,只要记住一个用户名密码;

2)SSO(单点登录)效果是一次输入密码多个网站可以识别在线状态;一次登录可以多次访问不同应用系统;

显然大家希望使用第二种方式,更自由更方便,当然安全风险也随之而来,怎么解决既方便又安全的SSO呢,于是OAuth出现了;

OAuth2.0是一个关于授权(authorization)的开放网络标准,在全世界得到广泛应用,目前的版本是2.0版。 OAuth 2.0的运行流程,有兴趣的朋友可以查看官方文档 RFC 6749。

2. OAuth授权码模式认证流程简介

1561023097188.jpg

  • 授权码模式(authorization code)是功能最完整、流程最严密的授权模式,也是最繁琐最安全的一种模式。它的特点就是通过客户端的后台服务器,与"服务提供商"的认证服务器进行互动。
  • client向资源服务器请求资源,被重定向到授权服务器
  • 浏览器向资源拥有者索要授权,之后将用户授权发送给授权服务器
  • 授权服务器将授权码转经浏览器发送给client
  • client拿着授权码向授权服务器索要访问令牌
  • 授权服务器返回AccessToken和RefreshToken给cilent

3. OAuth2.0协议在使用过程中的不规范,容易引起的风险及正确使用的规范

OAuth2.0协议是目前被运用最为广泛的一个SSO协议,在早期的时候爆发过不少相关的安全方面的漏洞,其实仔细分析后会发现大都都是没有严格遵循OAuth2.0的安全相关的指导造成的。

风险1:redirect_url 回调域名欺骗

  • 服务端必须验证clientid注册的应用与redirect_url是对应的,否则redirect_url会被伪造成第三方欺诈域名,直接导致服务器返回Code被泄露;
  • 服务器生成的临时Code必须是一次有效,客户端使用一次后立即失效并且有效期很短,一般推荐30s有效期,由于Code是通过redirect_url浏览器回调传输容易被截取,可以保证临时Code被客户端正常消费后不会被再次使用

风险2:redirect_url XSS跨域攻击

  • 比如构造一个认证请求,redirect_uri=http://app.com/test?callback=<script src="http://app2.com?getToken.php"></script> 服务器端需要对redirect_url进行检查禁止特殊字符输入,并且对redirect_url进行全匹配,不做模糊匹配可以杜绝XSS攻击

风险3:State 防止CSRF

  • 认证请求url中state参数是最容易被忽略的,大部分IDP不会强制要求客户端使用state参数;
  • 客户端每次请求生成唯一字符串在请求中放到state参数中,服务端认证成功返回Code会带上state参数,客户端验证state是否是自己生成的唯一串,可以确定这次请求是有客户端真实发出的,不是黑客伪造的请求;

风险4:Access_Token泄露

  • 由于Access_Token是通过http协议从服务器端传输给客户端,为了防止旁路监听泄露Access_Token,服务器必须提供https来保证传输通道的安全性(TSL的要求)
  • 客户端获取Access_Token,应该在后台与服务端交互获取Access_Token,不允许Access_Token传给前端直接使用
  • 需要保证Access_Token信息的不可猜测行,以防止被猜测得到;

风险5:令牌有效性漏洞

  • 维持refresh_token和第三方应用的绑定,刷新失效机制的设计不允许长期有效的token存在;

4.增强OAuth2.0协议设计及使用规范

OAuth2.0协议安全性进行进一步增强。

  • 对颁发出去的token权限进行限制,不同用户申请的token根据人员所属组织、角色、岗位进行数据隔离
  • 对登录过程安全性增强,对登录验证方式进行丰富,支持静态密码、手机验证码、OTP、生物识别、FIDO
  • 对Token颁发后的生命周期管理,可以按策略主动注销颁发的Token
  • 对使用OAuth过程进行行为分析,对登录过程进行风险识别
  • 按照不同应用的安全等级进行分级,不同安全级别应用实现二次认证,保障关键系统的安全访问

郑重声明:

果E安全网所有活动均为互联网所得,如有侵权请联系本站删除处理,转载请注明本站地址。

我来说两句