OAuth 2.0 认证及其攻击面

OAuth 2.0 认证及其攻击面

     工作上、生活里各种事太多了，公众号有段时间没有更新了 一是目前公众号没几个人，二是没有太多时间。以后尽量一周一更，把自己的笔记分享一下，希望大家喜欢~~

[TOC]

OAuth^[1]是一个关于授权（authorization）的开放网络标准，在全世界得到广泛应用，目前的版本是2.0版（1.0老版本太老应该没必要看了）。介绍OAuth 2.0的设计思路和运行流程，主要参考材料为RFC 6749^[2]。

一、应用场景

OAuth实际上就是为了解决客户端应用、第三方认证服务互不信任的情况，为了理解OAuth的适用场合，让我举一个假设的例子。

有一个"云冲印"的网站，可以将用户储存在Google的照片，冲印出来。用户为了使用该服务，必须让"云冲印"读取自己储存在Google上的照片。

问题是只有得到用户的授权，Google才会同意"云冲印"读取这些照片。那么，"云冲印"怎样获得用户的授权呢？

传统方法是，用户将自己的Google用户名和密码，告诉"云冲印"，后者就可以读取用户的照片了。这样的做法有以下几个严重的缺点。

（1）"云冲印"为了后续的服务，会保存用户的密码，这样很不安全。

（2）Google不得不部署密码登录，而我们知道，单纯的密码登录并不安全。

（3）"云冲印"拥有了获取用户储存在Google所有资料的权力，用户没法限制"云冲印"获得授权的范围和有效期。

（4）用户只有修改密码，才能收回赋予"云冲印"的权力。但是这样做，会使得其他所有获得用户授权的第三方应用程序全部失效。

（5）只要有一个第三方应用程序被破解，就会导致用户密码泄漏，以及所有被密码保护的数据泄漏。

OAuth就是为了解决上面这些问题而诞生的。

二、名词定义

在详细讲解OAuth 2.0之前，需要了解几个专用名词。

（1） ** application**：第三方应用程序，本文中又称"客户端"（client），即上一节例子中的"云冲印"。

（2）**HTTP service**：HTTP服务提供商，本文中简称"服务提供商"，即上一节例子中的Google。

（3）**Resource Owner**：资源所有者，本文中又称"用户"（user）。

（4）**User Agent**：用户代理，本文中就是指浏览器。

（5）**Authorization server**：认证服务器，即服务提供商专门用来处理认证的服务器。

（6）**Resource server**：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。

知道了上面这些名词，就不难理解，OAuth的作用就是让"客户端"安全可控地获取"用户"的授权，与"服务商提供商"进行互动。

三、OAuth的思路

OAuth在"客户端"与"服务提供商"之间，设置了一个授权层（authorization layer）。"客户端"不能直接登录"服务提供商"，只能登录授权层，以此将用户与客户端区分开来。"客户端"登录授权层所用的令牌（token），与用户的密码不同。用户可以在登录的时候，指定授权层令牌的权限范围和有效期。

"客户端"登录授权层以后，"服务提供商"根据令牌的权限范围和有效期，向"客户端"开放用户储存的资料。

四、运行流程

不论是那种类型OAuth 2.0的认证方式，其运行流程可总结为如下图，摘自RFC 6749。

（A）用户打开客户端以后，客户端要求用户给予授权。

（B）用户同意给予客户端授权。

（C）客户端使用上一步获得的授权，向认证服务器申请令牌。

（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。

（E）客户端使用令牌，向资源服务器申请获取资源。

（F）资源服务器确认令牌无误，同意向客户端开放资源。

不难看出来，上面六个步骤之中，B是关键，即用户怎样才能给于客户端授权。有了这个授权以后，客户端就可以获取令牌，进而凭令牌获取资源。

参考链接：http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

五、四种不同认证模式

（1）授权码类型

 授权码（authorization code）方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌。 这种方式是最常用的流程，安全性也最高，它适用于那些有后端的 Web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。

第一步，A 网站提供一个链接，用户点击后就会跳转到 B 网站，授权用户数据给 A 网站使用。下面就是 A 网站跳转 B 网站的一个示意链接。

https://b.com/oauth/authorize?
  response_type=code&
  client_id=CLIENT_ID&
  redirect_uri=CALLBACK_URL&
  scope=read

上面 URL 中，response_type参数表示要求返回授权码（code），client_id参数让 B 知道是谁在请求redirect_uri参数是 B 接受或拒绝请求后的跳转网址，scope参数表示要求的授权范围（这里是只读）。 第二步，用户跳转后，B 网站会要求用户登录，然后询问是否同意给予 A 网站授权。用户表示同意，这时 B 网站就会跳回redirect_uri参数指定的网址。跳转时，会传回一个授权码，就像下面这样。

https://a.com/callback?code=AUTHORIZATION_CODE

上面 URL 中，code参数就是授权码。

第三步，A 网站拿到授权码以后，客户端应用就可以在后端(用户不可见)，向 B 网站请求令牌。

https://b.com/oauth/token?
 client_id=CLIENT_ID&
 client_secret=CLIENT_SECRET&
 grant_type=authorization_code&
 code=AUTHORIZATION_CODE&
 redirect_uri=CALLBACK_URL

上面 URL 中，client_id参数和client_secret参数用来让 B 确认 A 的身份（client_secret参数是保密的，因此只能在后端发请求），grant_type参数的值是AUTHORIZATION_CODE，表示采用的授权方式是授权码，code参数是上一步拿到的授权码，redirect_uri参数是令牌颁发后的回调网址。

第四步，B 网站收到请求以后，就会颁发令牌。具体做法是向redirect_uri指定的网址，发送一段 JSON 数据。

{    
  "access_token":"ACCESS_TOKEN",
  "token_type":"bearer",
  "expires_in":2592000,
  "refresh_token":"REFRESH_TOKEN",
  "scope":"read",
  "uid":100101,
  "info":{...}
}

上面 JSON 数据中，access_token字段就是令牌，A 网站在后端拿到了。

（2）“隐式（implicit）”授予类型

有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。RFC 6749 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）"隐藏式"（implicit）。

 第一步，A 网站提供一个链接，要求用户跳转到 B 网站，授权用户数据给 A 网站使用。

https://b.com/oauth/authorize?
  response_type=token&
  client_id=CLIENT_ID&
  redirect_uri=CALLBACK_URL&
  scope=read

上面 URL 中，response_type参数为token，表示要求直接返回令牌。

第二步，用户跳转到 B 网站，登录后同意给予 A 网站授权。这时，B 网站就会跳回redirect_uri参数指定的跳转网址，并且把令牌作为 URL 参数，传给 A 网站。

https://a.com/callback#token=ACCESS_TOKEN

上面 URL 中，token参数就是令牌，A 网站因此直接在前端拿到令牌，然后用这个令牌去请求资源服务器的数据。

注意，令牌的位置是 URL 锚点（fragment），而不是查询字符串（querystring），这是因为 OAuth 2.0 允许跳转网址是 HTTP 协议，因此存在"中间人攻击"的风险，而浏览器跳转时，锚点不会发到服务器，就减少了泄漏令牌的风险。

这种方式把令牌直接传给前端，是很不安全的。因此，只能用于一些安全要求不高的场景，并且令牌的有效期必须非常短，通常就是会话期间（session）有效，浏览器关掉，令牌就失效了。

（3）密码式

 如果你高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）。  第一步，A 网站要求用户提供 B 网站的用户名和密码。拿到以后，A 就直接向 B 请求令牌。

https://oauth.b.com/token?
  grant_type=password&
  username=USERNAME&
  password=PASSWORD&
  client_id=CLIENT_ID

上面 URL 中，grant_type参数是授权方式，这里的password表示"密码式"，username和password是 B 的用户名和密码。

 第二步，B 网站验证身份通过后，直接给出令牌。注意，这时不需要跳转，而是把令牌放在 JSON 数据里面，作为 HTTP 回应，A 因此拿到令牌。

这种方式需要用户给出自己的用户名/密码，显然风险很大，因此只适用于其他授权方式都无法采用的情况，而且必须是用户高度信任的应用。

（4）凭证式

 最后一种方式是凭证式（client credentials），网上找到两种说法，一种说该类型使用于没有前端的命令行模式，另一种 说法是在用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务的场景。实际上这种授权模式在利用面很少。其过程为： 第一步，A 应用在命令行向 B 发出请求。

https://oauth.b.com/token?
  grant_type=client_credentials&
  client_id=CLIENT_ID&
  client_secret=CLIENT_SECRET

上面 URL 中，grant_type参数等于client_credentials表示采用凭证式，client_id和client_secret用来让 B 确认 A 的身份。 第二步，B 网站验证通过以后，直接返回令牌。这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，即有可能多个用户共享同一个令牌。

六、攻击面

OAuth2.0协议本身是没有问题的，而关于OAuth2.0的漏洞大多是一些配置不当所造成的，严重时甚至可以达到无交互登录任意授权账户。 在上述的认证流程中，不论哪种模式，都是为了从认证服务器获取access_token，用来访问资源服务器。而申请access_token，需要在请求里添加几个必要参数（不一定是下面的全部参数）。如下所示：

client_id：表示客户端的id(我是谁)。
response_type或grant_type：表示授权类型(申请哪种模式) 
scope：表示申请的权限范围(申请哪些权限，由授权服务器定义)。
redirect_uri：表示重定向URI(申请结果跳转至哪儿，也就是CALLBACK_URL ，申请到授权码或者令牌以后，通过该URI回调传递授权码或令牌给客户端  只有授权码模式和授权码简化模式采用)。
state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值(自定义信息希望服务端原样返回，用来预防csrf)。
code：表示授权码，必选项。该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID和重定向URI，是一一对应关系。

而关于OAuth2.0漏洞的挖掘也是围绕其中几个重要参数点展开，大致分为以下几个方面：

1、OAuth劫持

造成这个类型的漏洞主要是未对redirect_uri充足检验或检验可以绕过。 根据OAuth的认证流程，用户授权凭证（授权码或令牌，授权码模式可以获得授权码，简化授权码可以获取令牌）会由服务器转发到redirect_uri对应的地址,如果攻击者伪造redirect_uri为自己的地址,然后诱导用户发送该请求,之后获取的凭证就会发送给攻击者伪造的回调地址.攻击者使用该凭证即可登录用户账号,造成授权劫持。 围绕修改redirect_uri思路，结合网站url跳转漏洞可以尝试获取凭证。

2、CSRF绑定劫持漏洞

攻击者抓取认证请求构造恶意url,并诱骗已经登录的网用户点击(比如通过邮件或者QQ等方式)。认证成功后用户的帐号会同攻击者的帐号绑定到一起。该类型漏洞主要是由于没有配置statec参数进行身份校验。 具体例子可见乌云历史漏洞2014-060493

3、Scope越权访问

案例: https://www.oschina.net/question/12_143105

https://github.com/login/oauth/authorize?client_id=7e0a3cd836d3e544dbd9&redirect_uri=https%3A%2F%2Fgist.github.com%2Fauth%2Fgithub%2Fcallback/../../../homakov/8820324&response_type=code&scope=repo,gists,user,delete_repo,notifications

上面案例中的scope参数扩大到了用户的代码库等其它权限。于是越权拥有了用户的私有代码区操作权限。

References

OAuth: http://en.wikipedia.org/wiki/OAuth
RFC 6749: http://www.rfcreader.com/#rfc6749
https://mp.weixin.qq.com/s/M4qffpKT5vXI1gjkgqjDVg 
http://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html

原文始发于微信公众号（学安全在路上）：OAuth 2.0 认证及其攻击面