基于OAuth协议的天翼开放平台安全性浅析

［徐博文　贾曼　曹维华　朱华虹］



基于OAuth协议的天翼开放平台安全性浅析

［徐博文贾曼曹维华朱华虹］

摘要OAuth协议是当前互联网最流行的开放授权标准。以天翼开放平台为例，介绍了OAuth2.0协议的工作原理，重点分析了OAuth2.0安全问题的两个焦点，一是技术应用漏洞，即由于授权场景的多样性导致部署时产生逻辑和代码设计漏洞，二是业务应用漏洞，即由于安全机制不够完善以及协议涉及的实体之间无法有效配合导致业务应用层面的安全性降低。

关键词：OAuth2.0 授权协议 天翼开放平台 应用漏洞

徐博文

中国电信股份有限公司广东研究院，主要研究方向为IP网络通信技术。

贾曼

中国电信集团公司网络运行维护事业部数据处，主要研究方向为IP网络通信技术。

曹维华

中国电信股份有限公司广东研究院，主要研究方向为IP技术、移动互联网技术。

朱华虹

中国电信股份有限公司广东研究院，主要研究方向为IP技术、SDN技术。

1　引言

中国电信天翼开放平台为合作伙伴提供统一的开放合作服务门户（Open.189.cn），打造统一的运营商级能力开放合作品牌和入口，平台于2012年3月27日正式上线，基于OAuth协议提供授权服务，支持版本为2.0。OAuth（Open Authorization，即开放授权）为用户资源的授权提供了一个安全、开放而又简易的标准，OAuth授权不会使第三方触及到用户的帐号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权。OAuth提供的是可信的第三方认证，既能通过其统一认证解决用户在不同Web应用之间的身份认证问题，又能实现在保证用户信息安全的基础上，将用户指定的资源授权给第三方，实现用户身份认证以及资源开放授权，因此出现不久即成为RFC标准并获得各大网络服务提供商的支持，包括微软、Google、Facebook、Twitter，以及国内的新浪、腾讯、网易、人人和豆瓣等在内的互联网公司均在其开放平台上提供了OAuth认证接口。本文将以天翼开放平台为例，介绍OAuth2.0协议工作原理，同时探讨OAuth2.0的安全问题。

2　OAuth2.0协议工作原理

（1）协议实体

OAuth2.0协议定义了 4种不同的实体：资源拥有者（Resource Owner），指能够对受保护资源进行授权的实体，如天翼用户。资源服务器（Resource Server），存放用户受保护的资源并通过与授权服务器的交互对资源的访问请求作出应答，天翼开放平台资源服务器地址为api.189.cn。授权服务器（Authorization Server），对资源拥有者进行身份认证，对验证通过的授予访问权限，天翼开放平台授权服务器地址为oauth.api.189.cn，授权服务器和资源服务器构成了天翼开放平台的主体。客户端（Client），指第三方应用系统或程序，可以是一个远程Web站点、一段JavaScript代码或一个本地App，它获得域内用户授权之后可以访问用户存放在资源服务器上的资源，天翼开放平台支持开发者根据平台所提供资源，创建和管理第三方合作应用，通过合作应用调用平台的资源。

（2）协议工作流程

OAuth 2.0协议的基本工作流程如图 1 所示。

图1　OAuth 2.0协议基本工作流程

①客户端向资源拥有者发起“授权请求”（authorization request）；②资源拥有者同意客户端的授权请求，并返回“授权许可”（authorization grant）给客户端；③客户端将“授权许可”提交给授权服务器，请求获得用户资源的访问权限；④授权服务器验证通过后向客户端返回“访问令牌”（access token）；⑤客户端将“访问令牌”提交给资源服务器，请求访问用户资源；⑥资源服务器将对应用户的受保护资源（Protected Resource）返回给客户端。

（3）授权模式

OAuth2.0强调可扩展性和灵活性，为此定义了多种授权模式，以适应多个应用场景授权，包括授权码模式（Authorization Code）、简化模式（Implicit Grant）、客户端授权模式（Client Credentials）以及资源拥有者密码授权模式（Resource Owner Password Credentials），天翼开放平台支持前3种，其中Authorization Code主要用于Web应用，Implicit Grant用于手机和桌面等Native应用，Client Credentials可用于Web和Native应用，但仅限于用来访问一些公共资源，而不是受限资源如某个特定天翼用户的资源。

3　OAuth2.0协议安全问题分析

OAuth 2.0协议领导者之一Eran Hammer认为OAuth2.0没有达到安全和互操作性这两个最重要的目标，“在大部分开发者手中明显出现了不安全的实现结果”［1］。从大量案例［2］来看，OAuth2.0协议的安全焦点集中在技术应用漏洞和业务应用漏洞两个方面。本文并未对天翼开放平台进行安全方面的深入测试，针对OAuth2.0安全性的探讨来自其他案例，天翼开放平台仅作为场景类比和讨论。

（1）技术应用漏洞

由于OAuth2.0授权场景的复杂化，容易导致开放平台方设计和部署不周，或者对应用方的安全指引不足而错误使用应用场合。另外，场景之间的安全问题容易产生交叉，使一些潜在威胁通过场景转换成为显性漏洞［3］。

以第三方登录认证为例，当应用方通过平台方的Access token 获取接口得到用户的授权信息后，将授权信息（Access Token、uid、expire_time）作为本应用账号系统的匹配参数，实现新用户注册或者已有用户的身份认证。在这个流程中，如果应用方在授权信息匹配处理逻辑部分设计不严谨，例如参数选择不当或没有应用方来源验证机制，将导致严重漏洞，最常见的攻击是授权信息篡改，可导致任意登录应用方账号的严重漏洞。

图2　基于天翼开放平台的某手机客户端应用OAuth认证案例

图2是OAuth 2.0应用于移动终端进行用户身份认证的典型案例，在其业务逻辑的第3步，当基于天翼开放平台的某手机客户端应用获取开放平台方返回的Access Token、uid等用户授权信息后，将授权信息上报给手机客户端应用自身的用户认证系统进行账号匹配登录，如果该应用后续用户匹配逻辑不严谨，存在错误选择授权信息作为参数（如单纯选择uid一项）或者没有对授权信息（Access Token）进行来源验证，攻击者可以通过截包篡改匹配参数，比如修改为其他天翼用户uid，从而实现该手机客户端自身用户系统的任意账号登录。

另外，由于部署了OAuth2.0的平台方和第三方应用存在逻辑设计和代码安全方面的问题，攻击者可以对二者的账号系统进行包括截包篡改、CSRF和XSS等多种形式的复合攻击［4］。

（2）业务应用漏洞

OAuth2.0协议作为一种授权认证协议，在业务应用层面涉及到用户、平台以及第三方应用这3个实体，其安全问题由这3个实体综合决定。平台方在部署协议时，需要一套相应的安全机制来保证整个业务环节的安全，而同时又有赖于第三方应用和用户在使用过程中的配合。然而，从对主流开放平台应用情况的调研来看，由于平台方安全机制不够完善，同时用户与第三方应用这两个实体之间缺乏有效配合，导致OAuth2.0协议在业务应用层面安全性降低。

3.1安全机制

（1）对平台资源的权限分级不严格

OAuth认证最终结果是获得用户平台资源的访问授权，如果平台方对平台资源权限分级不严格，将导致用户信息和资源泄露的危险，因此必须对平台资源进行严格的权限等级划分，使第三方应用只能根据自身网络服务需求去申请并获取用户在平台上的相应资源，例如第三方登录认证只授权用户账号和头像信息，邮件客户端只授权用户通信录列表以及邮件读取、发送和修改权限。天翼开放平台对自身能力服务及第三方特色能力即平台资源进行优化配置、整合、分类和分级，形成了以天翼帐号、电信能力、数字内容以及综合信息为主体的四大类开放能力［1］，基于平台的第三方应用需要进行相应的“能力绑定”，因此在平台资源权限分级方面相对完善。

（2）缺乏与其他安全验证机制的配合应用

OAuth认证使第三方获得对用户资源的授权访问，如果该授权是由于漏洞攻击引发的被动授权，那么如果没有其他安全验证机制的配合，攻击将获得成功。谷歌公司最早意识到这一点并且将OAuth认证与两步验证机制（Two-step verification，简称2SV）结合起来，即在谷歌账号系统中启用OAuth认证必须首先绑定手机并通过短信或电话进行一次性密码的身份验证，以保证OAuth认证是在用户知情的情况下发生的。其他平台和应用有的则是在授权页面要求用户填入第三方渠道如备用邮箱获取的验证码来保证授权流程的安全性，但可惜的是大部分平台方和应用仅考虑操作方便性，没有做到将OAuth认证与其他安全验证机制结合起来使用，忽视了账户安全。

3.2协议实体

（1）第三方应用开发者：缺乏自律

在OAuth2.0的整体解决方案中，第三方应用的配合是安全的重要一环，这种配合实际上指的是应用开发者的自律。在平台资源权限进行了严格划分的基础上，开发者应该按照应用自身网络服务需求去申请相应的权限，这些应该在开发者协议条款中着重阐明，然而这种完全依赖开发者高度自律的机制是不可靠的，以Android系统移动应用为例，就普遍存在高权限授权申请的情况。

（2）平台方：审核机制存在漏洞

对第三方应用的约束责任主要在平台方，第一步就是对第三方应用的审核上，审核内容最重要的就是对用户资源权限的申请是否符合要求，是否有越权行为等。然而，从对多个开放平台的调研看，审核标准不一，有的甚至只需要填写应用的基本信息，对用户资源请求权限根本不做任何审查和限制，恶意第三方应用可以绕过审查，非法获取超额权限。天翼开放平台审核机制相对健全，对个人开发者和企业开发者均有较为严格的身份认证，个人必须提供身份证件进行实名认证，企业则需要提供法人和营业执照，对接入应用的信息审核项目也较为丰富。

（3）用户：对OAuth认证的安全性缺乏认识

OAuth协议尽管在国内得到较大应用，但对于大多数用户来说仍然属于新鲜事物，而且国内用户缺乏保护账户信息和权限的习惯，往往在应用方引导下一步步完成授权操作，只体验到易用性而忽略了安全性，例如当前流行的OAuth协议“一键登录”操作，给用户带来极大便利的同时也降低了用户的安全意识，用户越来越不在意自己的账号安全，敏感账户同时授权给多个应用的情况非常常见。

4　结语

OAuth协议促进了Web2.0技术的发展，但同时也带来了安全问题。尽管2.0版本已经解决了协议自身的安全漏洞，但是在应用层面仍然存在诸多问题，解决这些问题不仅需要平台方在部署方面以及多个业务环节的努力，也需要第三方应用的配合，同时藉由OAuth认证的不断普及，用户能够逐步提升对OAuth协议的了解和认识，养成保护个人账户资源的习惯。天翼开放平台与应用开发者通过合作实现便利服务和价值增值，在强调业务扩展的同时，双方同时承担着推广OAuth协议、培养用户安全意识以及规范应用开发业态的责任，真正构建一个更为开放、安全的能力合作生态价值链。

参考文献

1Eran Hammer.OAuth 2.0：通往地狱之路［Z/OL］. http：// article.yeeyan.org/view/50978/307535， 2012

2Horseluke. OAuth 2.0安全案例回顾［Z/OL］. http：//drops. wooyun.org/papers/598， 2013

3T. Lodderstedt， Ed.等. OAuth 2.0 Threat Model and Security Considerations［Z/OL］. https：//tools.ietf.org/html/ draft-ietf-oauth-v2-threatmodel-08， 2012

DOI：10.3969/j.issn.1006-6403.2016.04.003

收稿日期：（2016-03-22）