0 引 言

随着互联网的飞速发展，各个网站及网络服务不再互相隔离，不同网络平台间的数据共享与协作日益增多，因此跨平台的资源开放与授权的需求日益增大.近年来，国内外各大社交网站如Facebook、Twitter、腾讯、新浪等陆续向社交应用平台转型，相继开发了自己的开放平台，得到用户授权的第三方应用可以通过调用平台提供的开放应用程序接口对用户在平台上的资源进行访问或修改.

第三方应用与开放平台进行数据交互的核心问题在于验证与授权，OAuth协议^[1]作为一个开放标准的协议框架，被广泛应用于开放平台、第三方应用与用户之间的验证与授权.该协议允许用户授权第三方应用访问该用户在某一信息平台上的私密资源(如个人资料、照片、联系人列表等)，而无需将用户名和密码提供给第三方应用.OAuth 2.0^[2]是该标准的最新版本，获取用户授权的第三方应用被授予一个短期有效的令牌，从而在特定时间内访问用户在平台上的特定资源.

OAuth 2.0协议不仅实现了开放平台与第三方应用间的认证互通，还实现了二者业务流的授权互通，因此被各大开放平台广泛采用.在OAuth 2.0的协议标准下，开放平台与第三方应用需要自行实现能够互相配合的安全方案.然而由于第三方应用开发者素质参差不齐，大部分开发者在实现该协议时未能严格执行安全规范，给攻击者以可乘之机，因此针对OAuth 2.0协议的攻击事件层出不穷.Sherman等^[3]指出Alexa排名前10 000且使用OAuth 2.0协议的网站中约有1/4存在遭受CSRF(跨站请求伪造)攻击的风险，Chen等^[4]指出使用OAuth 2.0协议的热门移动应用中约有60%由于部署不当而存在漏洞.

由于OAuth 2.0协议的广泛应用，人们做了大量工作来研究协议的安全性，针对该协议实现过程的攻击方法和相应防范措施受到普遍关注.Chari等^[5]指出最理想的OAuth协议的实现是基于授权码的方案，并且开放平台的认证服务器和第三方应用之间需要使用类似HTTPS的方式进行通信.王焕孝等^[6]对OAuth 2.0协议安全性进行了形式化分析，提出了用户与第三方平台间未使用HTTPS通信的攻击路线，但由于需要攻击者掌握第三方平台的认证口令等信息，攻击难度过大.张天琪^[7]提出了针对一种OAuth 2.0实现方式的CSRF攻击，但在开放平台严格执行协议安全规范的情况下这种攻击无法完成.Prakash^[8]提出将引入OpenID^[9]作为用户与开放平台的认证服务器间的交互的顶层协议，陈伟等^[10]在用户与开放平台的认证服务器间实现数字签名机制，但这些方案都无法避免发生在协议其他环节的攻击.

本文深入分析了OAuth 2.0协议中的授权码许可模式和隐式许可模式两大主流方案的实现流程，给出了典型威胁模型，剖析了协议在第三方开放平台和开发者共同实现的过程中可能出现的脆弱点，提出了针对state参数的CSRF攻击、针对无绑定令牌的攻击这两种攻击路线，并给出了针对这些攻击模式的防范方法和安全规范.

1 OAuth 2.0协议 1.1 OAuth 2.0协议简介

OAuth 2.0标准于2012年10月最终定稿，至今已发展出16个子版本.从业务出发点来讲，制定OAuth 2.0协议的最大动力之一，是希望用一个协议适应多个业务场景授权，即需要既能满足传统客户端授权场景，又要满足无服务器参与的授权场景，甚至还有手机应用授权场景等等.此外，OAuth 2.0协议还致力于简化第三方应用端开发者的工作，并对诸如“第三方登录”等介入形式予以支持.目前OAuth 2.0已成为开放平台领域实现验证与授权的标准协议.

OAuth 2.0协议的设计思路是在开放平台(Server)的认证服务器验证用户(User)身份后，用户授权第三方应用(Client)访问自己在开放平台上的特定资源，第三方应用被授予一个访问令牌，并使用该令牌调用开放平台的应用程序接口访问用户资源.该授权过程模型如图 1所示.

为了满足不同环境的需要，适应在多个场景中授权的需求，OAuth 2.0协议的验证和授权模式主要有以下三种.

1) 授权码许可(Authorization Code)模式：第三方应用作为一个独立的Web服务，通过HTTP和HTTPS方式与用户、开放平台进行交互，用户登录开放平台的认证服务器接受身份验证后，认证服务器向第三方应用发送授权码(Code)，第三方应用再将此授权码以及自己在平台中的身份标识和口令发送给认证服务器换取访问令牌(Token).

2) 隐式许可(Implicit Grant)模式：第三方应用以浏览器插件的形式运行在用户的浏览器中，该插件引导用户前往开放平台的认证服务器接受身份验证后，认证服务器向用户浏览器反馈访问令牌，由该插件截获后提取授权信息并进行后续业务处理.

3) 密码凭证许可(Resource Owner Password Credentials)模式：第三方应用为移动端或PC客户端应用，用户将自己的私有证书(如身份表示及口令)交由第三方应用转发给开放平台的认证服务器，认证服务器向第三方应用反馈访问令牌.这种方式需要用户与第三方应用之间有非常强的信任关系，且只用于移动或PC端的验证与授权，因此适用范围较小.

1.2 OAuth 2.0工作流程

由于OAuth协议中的授权码许可模式和隐式许可模式应用广泛，且绝大多数关于OAuth协议的攻击都针对这两种模式，本节仅分析这两种模式的工作流程.OAuth 2.0的核心理念包括如下几个方面：

① Resource Owner：资源所有者，对资源具有授权能力的实体，在此协议中通常指用户.

② Client：客户端，获取资源所有者授权并对资源进行访问的实体，即第三方应用.

③ Authorization Server：开放平台上的授权服务器，它验证资源所有者的身份，为资源所有者提供授权审批流程，并最终为客户端颁发授权.

④ Resource Server：开放平台上的资源服务器，存储资源所有者的各类资源并处理被授权的客户端对特定资源的访问.

⑤ Access Token：访问令牌，认证服务器将访问令牌颁发给客户端以示授权，客户端凭此访问令牌访问资源服务器上的特定资源.

1) 授权码许可模式

授权码许可模式工作流程如图 2所示，其流程描述如下：

(1) 用户向客户端(即第三方应用)以HTTP请求方式发起对该应用的使用请求；

(2) 客户端向用户返回一个HTTP Redirect回馈，引导用户浏览器跳转到开放平台的认证服务器网页；

(3) 用户由客户端引导对认证服务器发起一个GET形式的HTTP请求，客户端在该请求中添加redirect_url、client_id、state、response_type、scope这5个参数，其中redirect_url字段为用户在完成和认证服务器验证授权过程后的回调地址，用户身份验证成功后授权服务器将引导用户对该回调地址发起一个GET形式的HTTP请求并以GET参数的形式附加一个授权码(code)，client_id字段为客户端在该开放平台中的身份标识，state字段用于防御CSRF(跨站请求伪造)攻击，response_type字段表示此次验证的返回类型，在授权码许可模式下此字段值为“code”，scope字段表示客户端所申请的资源范围.

(4) 用户在认证服务器的登录页面提交自己的身份证明(如用户名与密码)；

(5) 认证服务器向用户返回一个HTTP Redirect响应，引导用户浏览器跳转到客户端的网页；

(6) 用户由认证服务器引导对客户端发起一个GET形式的HTTP请求，认证服务器在该请求中添加state和code这2个参数，其中state字段与(3)中的state值相同，用来防御CSRF攻击，code字段为认证服务器授予客户端的授权码；

(7) 客户端向认证服务器发起一个HTTP请求，此请求多为POST形式，请求中包含code、redirect_url、client_id、client_secret、grant_type这5个参数，其中code字段为认证服务器授予客户端的授权码，redirect_url与(3)中作用相同，client_id与client_secret分别为该客户端在开放平台上的用户名与口令，grant_type为授权类型，在授权码许可模式下此字段值为“authorization_code”；

(8) 认证服务器向客户端返回一个HTTP响应，包含access_token、token_type、expire_in这3个字段，其中access_token字段为认证服务器颁发给客户端的访问令牌，token_type字段为令牌类型，其值为“bearer”(无记名)或“unbounded”(无绑定)，expire_in字段为以秒为单位的访问令牌过期时间；

(9) 客户端向开放平台的资源服务器提交访问令牌并请求资源；

(10) 资源服务器验证令牌并反馈相关资源.

2) 隐式许可模式

隐式许可模式工作流程如图 3所示，其流程描述如下：

(1) 用户通过客户端在浏览器上的插件发起对该应用的请求；

(2) 客户端引导用户浏览器跳转到开放平台的认证服务器网页；

(3) 用户由客户端引导对认证服务器发起一个GET形式的HTTP请求，客户端在该请求中添加redirect_url、client_id、state、response_type、scope这5个参数，其中在隐式许可模式下此字段值为“token”，其他各字段作用与授权码许可模式流程中第(3)步一致；

(4) 用户在认证服务器的登录页面提交自己的身份证明(如用户名与密码)；

(5) 开放平台根据redirect_url参数返回一个url，url片段中带有access_token、uid、expire_time等授权信息字段，其中uid为开放平台中用户的身份标识，其他字段与授权码许可模式流程的第(8)步一致；

(6) 客户端从该url中提取授权信息；

(7) 客户端向开放平台的资源服务器提交访问令牌并请求资源；

(8) 资源服务器验证令牌并反馈相关资源.

2 协议安全机制与威胁分析 2.1 协议安全机制分析

在OAuth 2.0协议的流程中，用户的私钥证书、客户端的访问令牌等敏感数据受到较好的保护.

在此协议使用过程中，用户需要将自己的私钥证书(如平台的登录口令)提交给平台方的认证服务器并指定授权给客户端的资源，平台的认证服务器在接收用户提交的私钥证书时会使用SSL或TLS等加密信道，因此用户的私钥证书的提交过程是安全的.

在OAuth协议的不同模式中，客户端的访问令牌的直接接受者不同，在授权码许可模式中访问令牌被直接发放给客户端，在隐式许可模式中访问令牌被传输给用户的浏览器，此后客户端再从中进行提取.无论在哪种模式下，访问令牌都被建议在以HTTP响应的形式在部署有SSL或TLS的加密信道内传输.

2.2 授权码机制

在授权码许可模式中第三方应用的客户端需要提示授权码(authorization_code)来获取访问令牌(access_token)，而非认证服务器直接通过重定向方式向客户端返回访问令牌，这种设计从安全性角度分析有两方面优势.

其一，通过回调地址(redirect_url)重定向的方式不适合传输敏感数据.浏览器重定向是在一个不安全的信道中进行数据交互，这给攻击者盗取资源所有者的访问令牌带来更多机会.此外，在此协议中不应该假设资源所有者(即用户)的行为是可信赖的，用户的浏览器中的页面可能被植入了跨站攻击脚本来监听访问令牌，恶意用户也可能在接收到访问令牌时对其进行替换.但相比于访问令牌，授权码的敏感程度较低，即使授权码被泄漏，攻击者也会因为难以假冒客户端的身份获得访问令牌.

其二，认证服务器需要验证客户端的身份，如果不引入授权码，客户端的身份验证只能通过授权码许可模式流程中第(2)步重定向来完成，而在这个过程中浏览器重定向是在不安全信道中，就需要额外要求客户端与认证服务器之间使用数字签名技术来进行身份验证.引入授权码后，认证服务器可直接对客户端进行身份验证.

2.3 协议威胁分析

1) 客户端口令窃取

在客户端更新访问令牌和用授权码换取访问令牌时客户端需要同时向平台的认证服务器提交自己的口令，攻击者在获取客户端的口令后可以通过重放攻击获取访问令牌.

对于部分开源项目，攻击者可以从公开的代码库中直接获取客户端的口令.对于其他无法获取源码的部署在本地的客户端，攻击者可以从客户端部署在本地的二进制程序提取口令，即使应用对包含其中的口令进行了充分的混淆，任何能够得到程序发行包的人都可以通过逆向工程的方式提取其中的敏感信息.对于非本地部署的客户端，若其与认证服务器间的通信不在安全信道内，攻击者可以通过中间人攻击对传输的口令进行截获和重放.

2) 访问令牌窃取

在OAuth 2.0协议中，由于访问令牌不与客户端绑定，攻击者若能成功窃取访问令牌，则可以在不需要任何其他验证的情况下访问甚至修改用户的资源.

在访问令牌的传输过程中，多数情况下用户代理(如浏览器)先接收到认证服务器颁发给客户端的访问令牌，客户端从中提取令牌并请求资源，用户终端上的可能存在的恶意程序或其浏览器中页面被嵌入的跨站攻击脚本可以窃取传输到本地的访问令牌，攻击者也可以从部署到本地的客户端的本地存储区中提取访问令牌.此外，访问令牌存储在认证服务器和第三方应用的数据库中，攻击者可以通过注入攻击等针对数据库的攻击方法获取大量访问令牌.

3) 授权码窃取

相比于客户端口令和访问令牌，授权码的敏感性较低，然而授权码许可模式中，授权码的泄漏仍然能导致一定的风险.攻击者可以通过截获并替换客户端接收的授权码，使客户端在之后与认证服务器的交互中获取其他用户的访问令牌.

在授权码许可模式的流程中，认证服务器以HTTP重定向的方式引导接受过验证的用户向客户端发送授权码，HTTP重定向由用户发起，且在非安全信道中传输，攻击者可对此进行中间人攻击.此外，授权码存储在认证服务器和第三方应用的数据库中，攻击者也可以通过注入攻击等针对数据库的攻击方法获取授权码.

3 典型攻击方法

在OAuth 2.0的协议标准下，开放平台与第三方应用需要自行实现能够互相配合的安全方案.多数第三方应用在实现此协议时未能严格遵守安全规范，从而留下安全漏洞.通过对国内外几个开放平台中的多个第三方应用进行安全分析，本节提出两种针对OAuth 2.0协议实现过程中常见的安全漏洞的攻击路线，并给出防范方法.

3.1 CSRF攻击

CSRF^[11]即跨站请求伪造(Cross-site request forgery)攻击，其目的是冒用其他用户身份发起恶意请求.攻击者将一个精心构造的GET方式的HTTP请求嵌入一个网页中并诱使用户访问，浏览器在解析网页时在用户不知情的情况下自动地以用户的身份发起恶意请求，从而达成攻击目的.

在授权码许可模式中，客户端接收授权码的过程可能遭受CSRF攻击，客户端接收的授权码被截获并替换为攻击者的授权码，客户端在用授权码换取访问令牌的过程中获得的访问令牌就会变为攻击者的令牌，攻击者便可冒充其他用户身份在开放平台上窃取利益，如平台发送给特定用户的奖励、资源等.

3.2 针对state参数的攻击

在1.2节所描述的授权码许可模式中，第(3)步和第(6)步HTTP请求中的随授权码一起传输的state参数用于防范CSRF攻击.客户端引导用户浏览器向认证服务器请求授权码时附加一个随机的state参数，认证服务器发放授权码时也附加一个同样的state参数，客户端接收到含有授权码的HTTP请求时验证请求中的state参数是否和发出的一致.攻击者在无法猜测state参数的值时难以构造正确的HTTP请求来进行CSRF攻击.

在国内外绝大多数开放平台的实现中，state参数并非强制启用，部分第三方应用在实现时未使用state参数，部分第三方应用使用了过短或固定的state参数.对于未使用或使用固定state参数的第三方应用，攻击者可直接发起CSRF攻击，对于使用过短state参数的第三方应用，攻击者可以通过穷举的方式可以以极小的代价和极高的成功率完成CSRF攻击.

3.3 双向CSRF攻击

由于授权码在使用一次后就失效，因此上述CSRF攻击需要攻击者频繁地更新嵌入恶意网页中用于跨站攻击的HTTP请求的授权码参数.攻击者在进行上述攻击的同时，可以对开放平台的登录过程进行CSRF攻击从而完成攻击的自动化实现.

国内外部分开放平台的登录系统未部署CSRF防御机制(如人人网、Facebook等)，攻击者可以在恶意网页中构造登录开放平台的跨站请求脚本，并在其中放入自己的私钥证书(如用户名和经过加密的口令等)，用户遭受攻击后会在不知情的状态下以攻击者身份登录到开放平台中.在用户请求使用第三方应用时，开放平台的认证服务器会将用户的身份误认为攻击者从而向客户端发放攻击者的授权码.

3.4 无绑定令牌的攻击

由于OAuth 2.0协议中的访问令牌(access_token)具有不与第三方应用绑定的属性，所以窃取访问令牌后攻击者可以在不经过第三方应用的情况下调用开放平台的应用接口(API)直接对用户的资源进行访问甚至修改.

3.5 令牌劫持攻击

除授权码许可模式以外，在OAuth 2.0协议的其他模式中，认证服务器颁发的访问令牌都经由用户代理(如浏览器)发送给第三方应用.国内外大部分第三方应用在申请访问令牌时未使用HTTPS协议，访问令牌在颁发时以普通的HTTP响应报文的形式被用户代理接收，因此攻击者可以通过监听用户与认证服务器的通信从而窃取访问令牌.

此外，部分第三方应用在接收到访问令牌后不对其资源所有者(即用户)进行验证，仅根据随令牌一同在HTTP响应报文中传输的uid参数判定资源所有者的身份.攻击者通过截获包含访问令牌的HTTP响应报文并替换其中的访问令牌，保留其中的原uid参数，受害用户就会以自己的身份登录到第三方应用后在不知情的状态下访问或修改攻击者的资源，使攻击者受益.

3.6 实验验证及分析

本文针对若干个使用OAuth 2.0 协议并带有漏洞的第三方应用网站进行测试，测试方法为CSRF攻击以及双向CSRF攻击，使用 HTTP 协议调试代理工具BurpSuit拦截、分析并重放经修改的报文.

1) 双向CSRF攻击

双向CSRF攻击流程如图 4所示，具体过程描述如下：

(1) 受害者登录第三方应用；

(2) 攻击者通过CSRF攻击诱使受害者访问攻击者登录开放平台的HTTP请求；

(3) 受害者以攻击者身份登录开放平台；

(4) 攻击者通过CSRF攻击诱使受害者发起联合登录请求；

(5) 受害者请求第三方平台发起联合登录；

(6) 第三方应用与平台进行交互后完成验证；

(7) 攻击完成，受害者应用账号被绑定到特定平台账号上.

2) CSRF攻击

CSRF攻击流程如图 5所示，具体过程描述如下：

(1) 攻击者进入第三方服务，并发起联合登录请求；

(2) 第三方应用引导攻击者进入开放平台并验证身份；

(3) 开放平台向攻击者返回第三方应用的回调地址，其中包含授权码code，此时攻击者保留该授权码或整个回调地址，不进行下一步授权过程；

(4) 受害者登录到第三方应用；

(5) 攻击者通过CSRF攻击诱使受害者访问攻击者之前获得的回调地址；

(6) 受害者访问该回调地址，第三方应用提取到其中包含的攻击者的授权码code；

(7) 第三方应用将授权码code交给开放平台；

(8) 开放平台接收授权码code后向第三方应用发放攻击者的访问令牌access_token；

(9) 攻击完成，攻击者将自己的访问令牌绑定到受害者账号.

3) 结果与分析

实验结果如表 1所示.针对使用授权码许可模式的OAuth 2.0协议，若平台方不强制进行state字段验证并且第三方应用方未进行state字段验证，则CSRF攻击可行性高，难度较低；若平台方登录和应用方接收联合登录请求都未部署CSRF防御，则可进行双向CSRF攻击.两种攻击方法都可让受害者的应用账户被绑定至特定平台账户.

4 防范策略及建议

为防御针对OAuth 2.0协议的CSRF攻击，第三方应用在实现授权码许可模式过程中必须使用随机性强且足够长的state参数，并设定一个较短的过期时间，此参数须与用户绑定而不能被用户篡改.实现方案如下：

1) 用户在对第三方应用发起使用请求时第三方应用服务器生成一个64比特位以上的随机数；

2) 第三方应用服务器将此随机数进行md5编码，存入用户HTTP请求的session中的state字段，并设定失效时长为60 s，并将此编码发送给开放平台的认证服务器，作为其此次会话的state参数；

3) 第三方应用服务器接收来自认证服务器并经用户浏览器重定向的HTTP请求，提取其中的授权码和state参数，并将此state参数与此HTTP请求的session中的state字段比较，若二者一致则判定有效.

由于HTTP请求的session保存于接收请求的Web服务器中，session与用户绑定且用户无法对其进行修改，在session的state字段失效前系统有充足的时间进行正常的验证与授权，而攻击者无法在此时间内穷举64 bit随机数并且向第三方服务器发起请求，因此本方案安全性良好，且实现对系统性能影响极小.

为防御此类访问令牌劫持攻击，第三方应用在申请访问令牌时应使用HTTPS发起请求，避免令牌在传输过程中被窃取.此外，第三方应用不应当通过接收到的包含访问令牌的HTTP响应报文中的uid参数判定资源所有者身份，而应向开放平台的资源服务器提交访问令牌后调用相应API确定资源所有者身份信息.

5 结 论

OAuth 2.0协议是目前应用最为广泛的联合登录授权协议，协议关系到使用者在网络中的敏感信息，其安全性受到极大重视.通过分析OAuth 2.0协议中两大主流模式的实现过程和安全机制，本文给出了针对协议中部分敏感数据的威胁模型，总结了第三方应用和开放平台在实现和部署协议的过程中易出现的安全漏洞，并提出了相应的攻击路线和防范策略.下一步的研究工作在于依据本文提出的策略实现一个安全性较强的OAuth 2.0的协议应用库，为第三方开发者提供安全性良好的开发框架.