OAuth授权流程的安全建模研究

林满佳，唐 屹

（广州大学数学与信息科学学院，广东广州 510006）

OAuth授权流程的安全建模研究

林满佳，唐 屹*

（广州大学数学与信息科学学院，广东广州 510006）

文章实例分析基于国内开放平台的OAuth授权流程.结合协议标准与网络踪迹，使用Alloy语言对授权流程建模，分析其中的安全问题，利用Alloy分析器找到了可能导致中间人攻击的漏洞，并实际验证了这个漏洞.在此基础上，比较分析了国内其他一些开放平台的类似问题，提出了解决问题的思路.

OAuth协议；开放平台；Alloy语言；中间人攻击

OAuth协议是一类授权协议，允许用户利用其在第三方站点（IDP）的帐号和口令，访问某个站点（RP）.这个协议常被用来构造开放平台，IDP扮演着用户认证服务器的角色，RP可以依据IDP的认证信息而非用户在IDP的帐号和口令，授权用户访问并定制访问内容，实现单点登录.现有的OAuth版本为2.0，本文所称的OAuth即为这个版本.

OAuth由于使用第三方帐号登录，其安全问题一直为人们所关注.OAuth威胁模型定义了OAuth 2.0安全指南［1］，提供开发者可以遵循的涉及协议本身的威胁综合模型及对策.一些形式化方法被用来确认文献［1］中涉及的安全威胁，例如，PAI等使用Alloy建模语言［2］，SLACK等利用Murphi验证了OAuth2.0客户端流［3］；CHARI等利用通用可组合安全框架，分析了OAuth2.0的服务器流［4］，但这些研究，缺乏对实现细节及应用环境的综合考虑.SUN等对现有的OAuth单点登录实现进行了一些实证分析［5］，但这些分析中所涉及的IDP不是国内流行的IDP，而且也没有提出具体的安全隐患解决方案.

本文以国内的开放平台为基础，分析OAuth授权流程的安全性，笔者实证分析了腾讯QQ开放平台的OAuth授权流程，采用Alloy语言进行建模分析，对可能存在的安全脆弱性进行了分析与验证.在此基础上，比较分析了国内其他一些开放平台的相关问题，提出了解决问题的一些思路.

1 OAuth授权流程及应用实例

1.1 授权流程

OAuth授权过程包含4个角色：用户U、浏览器B、站点RP以及第三方站点IDP，其授权流程可以分为2类：服务器端流程（图1）和客户端流程（图2）.

图1 服务器端Fig.1 Server-side

服务器流程需要RP服务器端的配合.用户向RP发出IDP帐号登录请求，RP在收到请求后做出响应，将浏览器重定向到IDP进行身份验证.在IDP对用户身份验证成功后，会把一个包含有表示对RP授权的授权码响应发回给浏览器，这时，浏览器重定向到RP，RP使用授权码与IDP进行交互以获取访问令牌，并进而访问用户的配置数据.

图2 客户端Fig.2 Client-side

客户端流程无需RP服务器端的参与，但需要客户端脚本的支持.流程开始时，用户选择用IDP账号登录，并通过浏览器向IDP发出身份验证请求.当IDP对用户身份验证成功后，会发出一个带有用户配置数据的给RP授权的重定向响应，但用户配置数据并不直接转到RP，需要浏览器从RP下载并运行脚本，提取用户配置信息并提交给RP.

客户端流程比服务器流程更加简便，因为在IDP对用户的身份验证成功后，客户端流程的RP获得的是带有用户配置数据的响应，而服务器流程的RP在收到授权响应后还要进一步与IDP进行交互才能获得用户的配置数据.但服务器流程相对安全，因为客户端流程直接获得的用户配置信息会暴露在浏览器上并导致泄露.

1.2 腾讯OAuth授权流程

以用户利用其QQ帐号登录酷6网站来分析腾讯OAuth授权流程.

1.2.1 浏览器从酷6重定向到腾讯

当用户选择利用腾讯QQ帐号登录酷6站点后，便开始了腾讯OAuth授权流程，首先，浏览器响应酷6的第三方登录请求，把连接重定向到腾讯的页面，其重定向的URL如下：

注意到重定向的URL包含一系列的参数：如酷6站点的ID（client＿id），授权成功后的回调地址（redirect＿uri）以及用户请求访问范围（scope）等.

1.2.2 腾讯验证用户的身份

腾讯收到重定向过来的信息，首先会检测相关的站点是否合法，然后展开对用户身份进行验证.依据用户是否已处于登录状态，弹出确认页或登录页.

1.2.3 酷6获取授权码

尽管获取腾讯访问令牌的方式有2种，但在笔者的实验中仅出现服务器端的方式.腾讯的响应将引导浏览器重定向到URL：

并附上授权码code.之后酷6再使用授权码向腾讯请求访问令牌以获取用户的配置数据.

2 基于Alloy的建模分析

Alloy是一种用于描述协议或软件系统的属性和行为的声明性语言规范［6］.利用Alloy对OAuth协议进行建模时，需要对授权过程中的每个实体建立一个签名，对有限制条件的实体增加约束事实.这些实体可分为3类：①协议涉及的角色；②角色交互过程的参数；③协议进行授权交互时的相关的网络元素.

以对协议交互过程的参数签名为例.在腾讯开放平台授权流程中，需要传递一些参数，如标识RP的client＿id，重定向的地址redirect＿uri，RP可访问范围scope，授权码code等［7］.这些参数包含name属性和value属性，笔者定义1个包含名字和值属性对的签名attributeNameValuePair｛name：Token，value：Token｝，然后通过这个签名派生出上述各参数.

为描述授权过程，定义以下的主要谓词.

（1）ClientRedirectsToTencent［］：描述浏览器由酷6重定向到腾讯的过程；

（2）UserLogin［］：描述用户登录腾讯站点获得授权的过程，实际实现中，由2个二选一的谓词TencentPromptsAuthorization和TencentPromptsAu-thorizationAfterLogin组成，分别表示未登录与已登录QQ的情形；

（3）ClientHasAccessToken［］：描述酷6站点获得授权码以及用户配置数据的方式，即腾讯开放平台所支持的两种授权过程，由2个二选一的谓词ClientGetsServerSideAccessToken和TencentSendsClientSideCode组合而成，分别表示服务器端模式和客户端模式.

对于上述的每个谓词，可以通过run命令检测其是否存在对应的实例.Alloy分析器是在有限范围内搜索满足限制条件的实例，因此，在运行run命令的时候要指定签名的个数.例如，运行命令run ClientGetsServerSideAccessToken for 6 but 18 Token，11 Time，10 Event，表示在签名Token的个数≤18，Time个数≤11，Event个数≤10，其它签名个数≤6的范围内搜索满足谓词ClientGetsServer-SideAccessToken的实例，其中Token表示授权交互过程中所需传递参数的名字以及其对应的值，Event表示HTTP请求／响应，Time表示HTTP请求／响应开始和结束的时间点，可以保证HTTP请求／响应是顺序进行的［8］.

通过Alloy分析器搜索，可以找到满足上述谓词的实例，即能找到服务器端流程的实例，可以直观地看出酷6站点获取访问令牌的过程.

3 腾讯OAuth授权流程存在的安全威胁

注意到在授权流程开始时，酷6返回给腾讯的响应信息包括：client＿id、redirect＿uri、scope.这些由RP至浏览器的信息是通过HTTP传输而来并重定向，这使得攻击者可以通过中间人攻击，篡改所传输的信息.并不是所有参数的篡改都起作用.修改client＿id和redirect＿uri会导致腾讯返回错误的信息，因为client＿id已经是在腾讯注册过了，并且redirect＿uri是client＿id对应主域名下的地址，所以，可以修改的是缺乏完整性保护的scope［9］.

3.1 Alloy描述攻击行为

为了能够描述上述中间人攻击，定义签名ProxiedHTTPTransaction，它继承于签名HTTPTransaction.ProxiedHTTPTransaction的主要行为就是截获客户端发给用户的响应，并对响应进行修改后发给用户.

为了证明OAuth存在中间人攻击，可以定义一个断言（assert），代码截图见图3.

图3 断言代码Fig.3 Code of assert

其中，签名ProxiedHTTPTransaction描述了中间人攻击的行为，即攻击者在不影响整个授权流程的情况下，修改重定向Location头中的scope参数的值，其它参数的值保持不变，结果是客户端的请求访问范围scope发生了变化.在该签名前面加上关键词no，表示该断言基于腾讯OAuth授权建立的模型不存在上述的中间人攻击.

最后，通过命令check NoMitmNetworkAttack-Possible for 6 but18 Token对这个断言进行检测. Alloy分析器找到一个反例，说明这个断言不成立，服务器授权流程存在中间人攻击.

3.2 攻击的验证性实验

为验证可能的攻击行为导致增加或减少客户端请求授权项.笔者利用webscrab截获从酷6发送到浏览器的登录响应，见图4.

图5利用webscarab修改授权信息，笔者修改响应参数里面的授权项即scope，把它从get＿user＿info改为all，all表示申请腾讯QQ的所有权限，这就增加了授权项，修改前的授权页面见图6，修改后的授权页面见图7.

图4 修改前的HTTP响应Fig.4 An HTTP response beforemodification

图5 修改后的HTTP响应Fig.5 An HTTP response aftermodification

图6 scope＝get＿user＿info的授权页Fig.6 An authorization page with scope＝get＿user＿info

图7 scope＝all的授权页Fig.7 An authorization page with scope＝all

通过本实验可知，使用中间人攻击修改了授权请求中scope参数，使得站点向腾讯QQ申请的权限增加了读取、发表腾讯微博信息的权限.用户可能会因为站点所申请的权限过大过多，而拒绝授予该站点访问自己在腾讯QQ中资源的权限，这就直接导致了授权的失败.

3.3 分析与讨论

社交网站由于拥有大量用户的参与，可以用作IDP用户认证服务器，实际上，国内的许多社交网站，都基于OAuth构造开放平台提供第三方的认证服务.

与腾讯QQ开发平台类似，新浪微博将一个最完整的授权分为3个步骤：登录－普通授权－高级授权.当用户的新浪微博帐号处于登录状态时，页面会自动跳转到普通授权页，高级授权不是必须，如果开发者不申请scope权限，系统会自动跳过此步骤，回调应用.由于存在高级授权页面，使得授权项的更改并不能顺利进行，因为用户可以在授权确认页中，对不想授予第三方应用的权限进行取消.

通过对开心网开放平台和人人网开放平台的测试，表明这2个平台并没有出现复选框要求用户进行勾选的，可以在用户不察觉的情况下修改授权项.

笔者注意到需要授权的网站RP通常通过HTTP协议向浏览器发出重定向响应的，在这响应中就包括了第三方应用所需申请得到的权限，使得攻击者可以修改scope参数.解决的方案可以有①在RP和用户浏览器之间建立HTTPS连接，这就要求RP提供HTTPS服务；②在RP与IDP的通信中增加验证scope完整性的流程，这可以使用消息验证码来确保关键参数的完整性［10］.

4 结束语

本文以通过腾讯开放平台访问酷6网站为例，分析OAuth授权流程，尤其是服务器授权流程，并在此模型的基础上进行安全性分析.借助Alloy分析器，对授权流程可能存在的安全脆弱性进行分析和实证检验，提出了解决方案.

［1］ RFC 6819-OAuth 2.0［S］.Threatmodel and security considerations tools.ietf.org／html／rfc6819.

［2］ PAIS，SHARMA Y，KUMAR S，etal.Formal verification of OAuth 2.0 using Alloy framework［C］∥In Proceedings of the International Conference on Communication Systems and Network Technologies（CSNT），2011：655-659.

［3］ SLACK Q，FROSTIG R.OAuth 2.0 implicit grant flow analysis using Murphi［EB／OL］.［2011］http：／／www.stanford. edu／class／cs259／WWW11／，2011.

［4］ CHARIS，JUTLA C，ROY A.Universally composable security analysis of OAuth v2.0［C］∥Cryptology ePrint Archive，Report2011／526，2011.

［5］ SUN ST.Konstantin Beznosov：The devil is in the（implementation）details：An empirical analysis of OAuth SSO systems［C］∥ACM Conference on Computer and Communications Security，2012：378-390.

［6］ JACKSON D.Software abstractions：Logic，language and analysis［M］.Cambridge，Massachusetts London：MIT Press，2006.

［7］ WILSON C，BOE B，SALA A，etal.User interactions in social networks and their implications［C］∥Acm Eurosys，2009.

［8］ BANSAL C，BHARGAVAN K，MAFFEISS.Discovering concrete attack on website authorization by formal analysis［C］∥IEEE Comput Secur Found Sym，2012（25）：247-262.

［9］ MADEJSKIM，JOHNSON M，BELLOVIN SM.A study of privacy settings errors in an online social network［C］∥IEEE Internut Confer Pervas Comput Commun Workshop，2012（10）：340-345.

［10］HU P，YANG R，LIY，etal.Application impersonation：problems of vauth and APIdesign in online social network［C］∥Second Edi Acm Confer Onlin Soc Network，2014（14）：271-278.

On modeling the security of oauth-based authorization

LIN Man-jia，TANG Yi

（School of Mathematics and Information Sciences，Guangzhou University，Guangzhou 510006，China）

Wemodel and analyze the OAuth authorization process based on an open platform instance in China. The analysis is on the combination of protocol specification and real network traces with using the Alloy language.We focus on the addressed security problems.By using the Alloy analyzer，we find a vulnerability that could be exploited to aman-in-the-middle attack.We give a proof of concept exploitation in real applications. We further discuss some other open platformswith similar experiments and propose a solution to this problem.

OAuth protocol；open platform；Alloy language；man-in-the-middle attack

TP 311

A

【责任编辑：陈 钢】

1671-4229（2015）03-0059-06

2015－03－20；

2015－04－15

林满佳（1990－），男，硕士研究生.E-mail：747374803＠qq.com

*通信作者.E-mail：ytang＠gzhu.edu.cn