一种改进的OAuth授权机制有效性分析
2018-01-03欧海文付永亮胡馨月
欧海文 付永亮 于 芋 胡馨月
1(北京电子科技学院 北京 100071) 2(西安电子科技大学 陕西 西安 710071)
一种改进的OAuth授权机制有效性分析
欧海文1,2付永亮2于 芋1胡馨月1
1(北京电子科技学院 北京 100071)2(西安电子科技大学 陕西 西安 710071)
国内微博、微信、百度等开放平台的出现,使“第三方”认证授权登录广泛应用到各个领域,因此,OAuth(Open Authorization)协议作为开放平台认证授权系统的标准协议而备受关注。众多研究表明这些开放平台中现今广泛使用的OAuth2.0协议在具体的实现过程中,很容易遭受钓鱼攻击、中间人攻击和CSRF攻击。为了抵抗网络中最常见的钓鱼攻击,研究提出通过防止攻击者伪装成授权服务器来改进OAuth2.0授权机制的解决方案,并证明了改进授权机制的安全有效性。为OAuth2.0协议的安全性改进提供了借鉴。
OAuth2.0 授权机制 有效性分析 钓鱼攻击
0 引 言
OAuth[1]协议作为国内外开放平台的主流认证授权协议,其安全性备受国内外研究人员关注,也已经取得了一些研究成果:王焕孝等[2]对OAuth2.0协议规范进行形式化分析,得出通信三方在失去HTTPS保护时,协议存在不安全情况、并给出了攻击路径;Pai等[3]利用知识流分析方法在Alloy中建模分析,检测到攻击者可以通过代码反编译技术窃取存储在桌面程序的第三方(client端)密钥,进而利用此密钥进行伪装以盗取用户敏感信息;魏成坤等[4]利用Scyther的对手模型和基于该模型的改进算法,对OAuth2.0协议安全性形式化分析,得出协议中存在的攻击模式。
以上研究均表明OAuth2.0协议在具体实现过程中存在安全问题,其中,钓鱼攻击、MITM(中间人攻击)和CSRF(跨站点请求伪造攻击)是最常见的三种攻击模式。也有几种解决方案,比如:引进对客户端或客户端的重定向URI严格检验机制来避免MITM和针对CSRF引入状态参数。但是,无论是OAuth1.0还是OAuth2.0都不能有效验证授权服务器的真伪[5]。如果用户在输入凭证之前未验证网站的真实性,那么,攻击者可利用用户的疏忽窃取用户密码。用户面临网络钓鱼攻击的风险时,如果OAuth系统能够通知用户,并且使用户能够轻松识别网站的真伪,便可以有效抵制恶意客户端(第三方应用)发起的网络钓鱼攻击。不幸的是,这种解决问题的方法很难实现。因为,它要求用户对HTTP/HTTP方面有足够多的了解,况且要求用户对授权页面要时刻注意。Al-Sinani等[6]提出了一种基于浏览器扩展的方式来阻止客户端直接重定向到授权页面。然而,由于移动设备的特点,恶意客户端可以不通过浏览器完成授权,所以该方案在移动设备上无法凑效。
为了解决“钓鱼”问题,尤其是在浏览器和移动设备上的授权服务器的钓鱼攻击,本文提出了一种改进的OAuth2.0授权校验方案,改进后的授权机制具备很强抵抗钓鱼攻击的功能。而且,改进后的OAuth2.0授权机制不要求用户具备丰富的安全相关知识。
1 背 景
1.1 OAuth协议简介
伴随互联网发展脚步,网络技术也逐步迈向成熟。如今的互联网更像一个大环境,内部之间的协作逐步密切,数据信息开放共享的需求也逐渐迫切,将不同的Web服务整合起来逐渐成为发展过程中的一个必然趋势。OAuth协议的出现解决了Web服务整合过程中出现的用户、第三方应用和服务提供方之间在认证授权方面出现的问题。它为用户在客户端应用上点击“第三方”登录时,能够访问存储的受保护数据信息提供了认证标准,与其他授权协议的区别是:OAuth能在不触及用户身份等敏感信息(比如:User_ID和Password)的情况下,允许客户端应用在授权范围内访问该用户托管在服务器上的保护数据。
OAuth协议的最初版本是OAuth1.0,OAuth2.0是1.0版本的升级,但并不向下兼容,其标准在2012年10月份定稿完成。相比1.0版本的实践式总结,OAuth2.0更像是一种框架式指引[7]。首先,OAuth2.0舍弃OAuth1.0中的加密算法,依赖HTTPS传输来保障安全性。其次,OAuth2.0协议摒弃了OAuth1.0版本中双Secret(appSecret、tokenSecret)的验证方式,在访问受保护资源时,只需提供Access Token无需双secret加密或者校验即可完成访问(类似cookies)。再次,OAuth2.0增加了多场景模式,更能满足第三方开发者的需求。
1.2 OAuth2.0协议的几个角色
OAuth2.0协议中的角色定义:
(1) 资源拥有者RO(Resource Owner) :能够授权保护资源的访问权限的实体,即:用户。
(2) 客户端(Client) :在获得授权后,能代表用户请求访问受保护数据信息的第三方应用。可以是桌面应用、Web应用或者其设备中执行的程序。
(3) 授权服务器AS(Authorization Server):检测用户授权信息无误后,发放访问令牌给客户端的服务器。
(4) 资源服务器RS(Resource Server):用户托管受保护数据信息的服务器。能够接受客户端携带访问令牌发起的资源访问申请,并作出响应。
1.3 OAuth2.0协议工作流程
OAuth2.0流程可以分为以下3步:
(1) 获取用户授权;
(2) 发放访问令牌;
(3) 访问受保护资源。
OAuth2.0协议中也增加了刷新令牌的操作,文献[8]给出了具体实现。OAuth2.0协议中的各角色之间的通信抽象流程,如图1所示。
图1 OAuth2.0协议抽象流程
(A) 用户在客户端应用上点击“第三方”登录后,客户端开始发起授权请求。
(B) 用户收到客户端的授权请求后,决定“同意”授权或者“拒绝”响应。
(C) 当用户授权客户端响应后,其携带用户的授权信息向AS发出申请访问令牌(Access Token)的请求。
(D) AS对客户端进行认证,认证通过后,发放Access Token。
(E) 当获得Access Token以后,客户端携带Access Token向RS发起受保资源的申请。
(F) RS认证Access Token确认通过后,向客户端开放用户许可范围内的数据信息,整个授权流程至此结束。
1.4 授权许可类型
OAuth2.0中的授权许可(Authorization Grant)代表一种中间凭证,它代表了RO针对客户端应用获取目标资源的授权。OAuth2.0定义了如下4种Authorization Grant,体现了授权采用的方式以及Access Token的获取机制。
(1) 授权码授权( Authorization Code Grant)。该模式要求:在获取用于向RS发起访问受保护数据信息申请时携带的Access Token之前,需要先向AS获得一个与用户授权信息有关的授权码。
(2) 隐式授权( Implicit Grant)。它代表一种“隐式”授权方式,即客户端在取得RO授权的情况下直接获取Access Token,而不是间接地利用获取到的授权码来取得Access Token。
(3) 资源所有者密码凭证授权( Resource Owner Password Credentials Grant):采用RO的凭证(如:用户名和密码)直接作为获取Access Token的授权方式。该方式要求用户对客户端足够信任。
(4) 客户端凭证授权( Client Credentials Grant):客户端应用自身的凭证直接作为它用于获取Access Token的授权类型。这种类型的授权方式适用于客户端应用获取属于自己的资源,换句话说客户端应用本身相当于资源的拥有者。
2 改进OAuth2.0授权机制的描述
考虑到传输层的安全性不仅在抵抗钓鱼攻击,而且在其他安全领域均可保护传输数据的隐私,改进的OAuth2.0授权机制依托传输层传输。
2.1 定 义
描述改进后的OAuth2.0框架之前,我们首先解释以下框架中额外引进的一些相关实体:
验证网关(VGateway):是真正的密钥协商服务器,用于发送验证信息和接收验证响应。通过一种通信方法(如SMS或电子邮件)验证用户身份,可以有效防止OAuth客户端被攻击者“钓鱼”。它根据用户的授权请求随机生成唯一标识的验证信息,并向实际持有移动设备或电子邮件地址的用户发送信息,从而有效避免钓鱼页面窃取用户名和密码。在整个系统中起着重要作用。
(1) 信息网关(IGateway):发送验证信息并接收响应信息的服务器。简单起见,我们假定IGateway是内部控制、安全可信的。
(2) 验证客户端(VClient):实际上是指用户的移动设备或电子邮箱,它可以从验证网关接收验证信息并对其进行响应。
接着,我们描述相关技术术语的若干定义:
(1) 证书(Credentials):它是由唯一数字标识和匹配共享密钥组合的一对随机码。
(2) 令牌(Token):服务器发出的唯一标识符。 它是授权客户端访问RS上受保护资源的访问凭证。
(3) 用户凭据(User credentials):是用于服务器唯一地标识User并验证User真实性的数据集。通常由用户信息(用户名或用户代理)和一些安全算法验证信息生成。
(4) 客户端凭据(Client credentials):指的是client_key和client_secret。
(5) 临时凭证(Temporary credentials):它引用请求令牌和密钥。
(6) 令牌凭据(Token credentials):指的是访问令牌和密钥。
2.2 改进机制在原OAuth2.0协议上的改进
改进OAuth2.0协议与原OAuth2.0协议相比,包括:用户凭证的体系结构和生成过程均不相同,两处改进分别利用了三方协商和OTP(动态口令)。因此,用户可以避免泄露存储在RS上的密码。OTP是加密系统中广泛使用的加密机制。在OTP中,明文与一次性填充相配对,并且每个位与来自填充的相应位一起加密。 如果密钥设计得好,将很难解密。
2.2.1 OAuth2.0授权的改进架构
项目的主程序在Android应用程序、iOS应用程序、Web服务器和后端API服务器(包括AS和RS)上运行。 为了简单起见,将移动设备或网络浏览器视为OAuth客户端,用户访问云服务器上的资源必须对设备或浏览器授权。 然后,构建一个SMS网关作为验证网关。该项目的设计图如图2所示。
图2 系统架构图
首先,用户通过客户端向RS提交数据信息访问的申请。接着,RS收到请求后向AS发出对授权信息的验证请求。然后,AS向验证网关(SMSGateway)发起用户身份的校验请求。验证网关通过发送验证信息(验证码或验证链接)来完成对用户身份的识别,只有通过了对用户身份的校验后客户端应用才能获得用户授权,进而能够获得用户的数据信息。其中,SMSGateway验证模块是改进OAuth2.0授权机制新增模块。
基于三方协商的思想,引入验证系统作为可信第三方,用户和AS可以在其中彼此验证。验证系统由三个重要部分组成:VGateway、IGateway(SMS或Email)和VClient,具体实现如图3所示。
图3 验证系统
首先,收到验证请求后,VGateway会生成验证信息,并通知IGateway通过短信或电子邮件发送验证信息。
其次,由于是基于识别性更高的短信号码和电子邮件,用户收到验证短信或电子邮件后,可以从AS简单确认。
最后,用户完成信息验证操作后,VGateway可以检测用户真实身份并生成用户凭证以请求AS完成授权。
2.2.2 用户凭证的生成
另一个重要的改进是:生成不可预测的验证消息和用户凭证的方式。在原OAuth2.0协议中,用户凭证是指提前在服务提供商中注册的User_ID和Password。改进后的OAuth2.0授权机制,使用OTP机制生成验证信息和用户凭证。
首先,VGateway确认在请求验证信息时得到的唯一的User_ID和用户手机号码或电子邮件。然后,它生成包含一些不可预测值的验证消息发送给用户。用户通过特殊指令(返回或提交该不可预测值)做出验证信息响应。最后,VGateway会自动生成不可预知的密码,此密码不需要记。
主要步骤描述如下:
(1) 生成User_ID:User_ID=F1(用户注册信息)。其中,函数F1应当满足以下条件:
① 将用户注册信息(如:用户名、电话号码、电子邮箱,等)映射到唯一的字符串。
② 已知User_ID的情况下,难以反推出用户注册信息。
(2) 生成User_PW:User_PW=F2(VR,User_ID)。其中,函数F2应当满足:
① 生成一个能够映射到VR和User_ID的唯一字符串;
② 已知User_PW的情况下,难以反推出VR。
F2有两个参数:VR表示验证响应消息,这是在收到验证信息后用户对VGateway的响应;User_ID是函数F1的作用结果。
(3) 向AS发送User_ID和User_PW。
(4) AS存储用户凭证。
2.3 改进OAuth2.0授权的详细过程
与原OAuth2.0协议过程的区别是:改进后的OAuth2.0授权机制在三次交互的基础上引入了额外的第三方密钥协商和传递机制。协议流程如图4所示。
具体步骤如下:
(1) OAuth客户端通过自身凭证向AS请求临时凭据。
(2) 接收到请求后,AS会检查OAuth客户端的请求是否合法。如果,验证通过,则AS返回临时凭据。否则,返回错误信息。
(3) 获取临时凭据后,OAuth客户端携带临时凭据向AS请求OAuth验证程序(通常是PIN码)。
(4) 在接收到请求后,AS检查临时凭证,并向用户回复一个回调URI。
(5) 用户输入一些注册信息(密码和私密信息除外),并提交给回调URI。
(6) 在接收到可以唯一标识用户的注册信息后,AS请求VGateway向用户的验证客户端(VClient)发送验证信息。
(7) 验证响应:用户根据接收到的验证信息来完成验证操作(例如输入验证码,点击验证链接等)。
(8) VGateway通过用户对验证信息的响应生成用户凭据,并将其发送至AS。
(9) AS生成OAuth_Verifier并将其响应到OAuth客户端。
(10) OAuth客户端通过OAuth验证程序向AS请求Token凭据。
(11) AS检查OAuth验证器,生成令牌凭据并将其发送到OAuth客户端,OAuth客户端获取令牌凭据并存储。
(12) 授权完成。
3 改进OAuth2.0授权有效性评估
接下来我们对改进OAuth2.0授权机制提出的解决方案的有效性进行评估。在与原OAuth2.0协议的对比中,对改进授权机制针对网络钓鱼攻击的安全特性做出描述。
3.1 抵抗钓鱼攻击的安全功能
在原OAuth2.0协议安全性基础上,改进后的OAuth2.0授权机制增强了针对钓鱼攻击的安全特性。本文重点介绍抵抗钓鱼攻击的安全能力,而不是RFC 6819[9]中讨论的其他安全问题。
3.1.1 验证信息
验证信息用于检测和防止恶意客户端应用的攻击。例如,钓鱼攻击的典型情况是攻击者欺骗用户相信网络“钓鱼者”是客户端或授权服务器。在原OAuth2.0协议中,信息显示在授权页面,但是,改进OAuth2.0授权机制通过VGateway发送验证信息的功能,用户可以更简单地识别。如果,攻击者伪造验证消息,真实的VGateway将拦截验证响应。同时,由于验证信息中含有不可预测值,攻击者不能通过枚举的方式来获得验证消息。
3.1.2 验证响应
验证响应帮助AS防止用户凭据遭受钓鱼攻击而被盗。验证消息与验证响应相一致,且每次都不同,因此,由VGateway生成的用户凭据是动态的。与原OAuth2.0协议相比,OTP机制的引入使攻击者进行钓鱼攻击的难度大大增加。
3.1.3 可信的三方协商
由用户、VGateway和AS组成了相互信任的三方密钥协商组。用户在授权过程中不直接与AS交互,用户凭证由用户和VGateway中的验证响应结果生成,并发送到AS。 如果任一方不被信赖,该过程将被终止。
3.2 抵抗网络钓鱼攻击的措施
下面介绍了改进后的OAuth2.0授权机制针对网络钓鱼攻击模式的改进,并证明了对策的有效性。
3.2.1 假冒AS
这是最常见且易于实施的网上诱骗,原OAuth2.0协议无法正确处理。恶意客户端可能会诱骗用户在伪造授权页中输入用户凭据,从而窃取用户密码或其他私密信息。改进OAuth2.0授权机制的对策如下:
(1) 由三方协商组(VGateway、用户和AS)生成密钥(验证信息、验证响应和用户凭证)的机制,使得授权的三个部分彼此可信。由于假冒的AS对VGateway而言不可信,所以攻击会失败。
(2) 由于OTP机制的存在使得盗取密钥没有任何意义,并且,重要的验证消息在用户和VGateway之间进行交互。
3.2.2 假冒VGateway
VGateway是文中改进OAuth2.0授权机制中介绍的一个新角色,其安全性也至关重要。如果假冒VGateway能够凑效,那么攻击者可以通过用户或盗取用户凭证来获取验证响应。
改进OAuth2.0授权机制的对策如下:
(1) 验证消息的不可预测性使得枚举很困难。错误的验证信息导致错误的用户凭证,AS无法验证通过。
(2) 攻击者不能够反推出F2函数。
(3) AS拒绝接收来自不在白名单范围内的VGateway请求。
3.2.3 钓取用户注册信息
原OAuth2.0授权方式中,攻击者可以通过钓鱼攻击使用伪造的回调URI来钓取用户的注册信息(例如电话号码和其他敏感信息),也可以从其他攻击模型中获得。
改进OAuth2.0授权机制的对策如下:
(1) 用户提交给回调URI的注册信息不应该是敏感信息,必须避免输入密码。
(2) 攻击者不能反推出函数F1和F2。
3.2.4 钓取用户凭证
恶意应用程序可能会通过在最终的用户授权过程中滥用嵌入式浏览器,或者通过呈现自己的用户界面,而不是受信任的浏览器系统呈现用户授权界面,来尝试盗取用户凭证。一旦攻击者获得用户凭证,就可以获得资源所有者存储的敏感资源。
改进OAuth2.0授权机制的对策如下:
(1) 对于AS或任何请求响应的真实性问题,使用传输层的安全特性来解决。
(2) 用户凭证依靠VGateway中的OTP动态生成,并发送到AS。该过程发生在服务提供程序中,因此,攻击者很难钓取到用户凭据。
4 结 语
本文通过防止攻击者伪装成授权服务器来改进OAuth2.0授权机制以解决钓鱼攻击问题。改进后的授权机制引入OTP和三方协商的方式,使得攻击者很难通过网络浏览器或移动设备进行钓鱼攻击。而且,为避免原始密码被盗,改进的OAuth2.0授权机制还引入了VGateway来安全生成用户凭证。本文还对改进OAuth2.0授权机制的有效性进行了理论方面的评估。
在以后的工作中,我们可以尝试借助模型检测工具来对改进的OAuth2.0授权进行建模分析。另外,也可以尝试针对OAuth2.0协议在实现过程中存在的其他类型攻击研究改善方案,从而达到进一步完善OAuth2.0认证授权系统的目的。
[1] 刘大红,刘明.第三方应用与开放平台OAuth认证互连技术研究[J].电脑知识与技术,2012,8(22):5367-5369.
[2] 王焕孝,顾纯祥,郑永辉.开放授权协议OAuth2.0的安全性形式化分析[J].信息工程大学学报,2014,15(2):141-147.
[3] Pai S,Sharma Y,Kumar S,et al.Formal Verification of OAuth 2.0 Using Alloy Framework[C]//International Conference on Communication Systems and Network Technologies.IEEE,2011:655-659.
[4] 魏成坤,刘向东,石兆军.OAuth2.0协议的安全性形式化分析[J].计算机工程与设计,2016,37(7):1746-1751.
[5] Hardt D.The OAuth 2.0 authorization framework[EB/OL].[2013-02].http://tools.ietf.org/html/draft-ietf-oauth-v2-31.
[6] Al-Sinani H S.Browser Extension-based Interoperation Between OAuth and Information Card-based Systems[D].Royal Holloway,University of London,2011.
[7] Bansal C,Bhargavan K,Maffeis S.Discovering Concrete Attacks on Website Authorization by Formal Analysis[C]//IEEE,Computer Security Foundations Symposium.IEEE Computer Society,2012:247-262.
[8] 时子庆,刘金兰,谭晓华.基于OAuth2.0的认证授权技术[J].计算机系统应用,2012,21(3):260-264.
[9] Lodderstedt T.OAuth 2.0 Threat Model and Security Considerations[J/OL].2013.http://tools.ietf.org/html/rfc6819.
VALIDITYANALYSISOFANIMPROVEDOAUTHAUTHORIZATIONMECHANISM
Ou Haiwen1,2Fu Yongliang2Yu Yu1Hu Xinyue1
1(BeijingElectronicScienceandTechnologyInstitute,Beijing100071,China)2(XidianUniversity,Xi’an710071,Shaanxi,China)
Third party authentication and authorization login mode has been applied to MicroBlog, WeChat, Baidu and other open platform. As a result, this login mechanism is widely used in various fields of our country. Therefore, the OAuth protocol as a standard protocol of the open platform for authentication and authorization system is closely watched. Many researches show that the OAuth2.0 protocol, which is widely used in these open platforms, is vulnerable to phishing attacks, man-in-the-middle attacks and CSRF attacks during the implementation. In order to resist the most common phishing attacks in the network, this paper proposes a solution to improve the OAuth2.0 authorization mechanism by preventing the attacker from masquerading as an authorization server, and proving the security and effectiveness of the improved authorization mechanism. It provides a reference for the security improvement of OAuth2.0 protocol.
OAuth2.0 Authentication mechanism Validity analysis Phishing attack
2016-12-21。欧海文,教授,主研领域:密码编码与应用技术。付永亮,硕士生。于芋,硕士生。胡馨月,硕士生。
TP393.02
A
10.3969/j.issn.1000-386x.2017.12.037