面向OAuth2.0授权服务API的账号劫持攻击威胁检测

刘奇旭，邱凯丽，王乙文，陈艳辉，陈浪平，刘潮歌

（1. 中国科学院信息工程研究所，北京 100093；2. 中国科学院大学网络空间安全学院，北京 100049）

1 引言

近年来，互联网规模持续增长，各类网络应用已经融入现实生活的方方面面。然而为了登录网络应用，用户不得不持有众多账号，并且限于密码策略和“撞库”风险，这些账号的口令往往还略有不同，这给用户带来了相当大的精神负担，严重影响了用户体验。为解决这一问题，谷歌等公司相继提供了跨应用的用户数据共享接口，单点登录（SSO,single-sign-on）便是其中最受欢迎的解决方案之一。

开放授权（OAuth，open authorization）是SSO已实现的最成熟的授权认证方法，被广泛地用于简化第三方应用程序的用户身份验证和服务器授权。在本文语境中，“OAuth”既表示授权认证方法，也表示实现这种授权认证的协议。OAuth协议先后经历了OAuth1.0、OAuth1.0a和OAuth2.0共3个版本。OAuth1.0a是在OAuth1.0基础上的安全升级，但是OAuth1.0a过于复杂且易用性差，因而被后来的OAuth2.0迅速取代。

各大互联网服务商普遍提供了基于 OAuth2.0协议的登录授权应用程序编程接口（API, application programming interface）供第三方调用。这样，用户仅需要掌握少量的互联网账号，再通过简单的授权操作就能够登录大部分网络应用，这种登录认证方式得到了人们的广泛认同。文献[1]指出，75%的用户在登录网络应用时会选择 SSO的方式而不是使用传统的账号口令。但是，服务商在设计开发OAuth登录授权API时，往往只重视功能性而忽视了安全性。OAuth身处用户登录授权这一关键节点，一旦出现问题将严重威胁用户隐私，甚至造成大面积的隐私数据泄露。2018年1月，国家信息安全漏洞共享平台（CNVD, China national vulnerability database）发布公告，提醒一个因OAuth2.0登录授权 API实现不当而导致的漏洞CNVD-2018-01622，该漏洞使攻击者能够在第三方移动应用上非法登录用户账号，从而导致敏感信息泄露。更令人担忧的是，类似的漏洞在CNVD上已经多达44个。

本文是 OAuth2.0协议实现安全方面的研究，旨在通过大规模测量揭示因 OAuth2.0 API脆弱性调用而导致的账号劫持风险，并形成有效的自动化检测工具。本文的主要贡献如下。

1) 分析了OAuth2.0协议的风险点，在此基础上提出了基于 OAuth2.0认证授权的账号劫持威胁模型。

2) 提出了基于差异流量分析的脆弱性 API识别方法和基于授权认证网络流量检测的账号劫持攻击验证方法，设计实现了面向 OAuth2.0授权服务API的账号劫持威胁检测框架Oscan。

3) 对Alexa排名前10 000的网站中真实部署的3 853个OAuth2.0授权服务API进行了大规模检测，发现360个OAuth2.0 API脆弱性调用。

4) 确认 101个脆弱性调用可以最终导致账号劫持，涉及80个知名网站和10个知名OAuth2.0服务提供商。

2 相关工作

安全界围绕 OAuth2.0协议[2]的安全性开展了深入细致的研究，工作主要集中在分析协议的安全性和研究因部署实现而产生的安全问题，后者又可细分为OAuth2.0 SDK安全性、OAuth2.0部署安全性和OAuth2.0漏洞自动化检测3个方向。各方向的研究工作总结如表1所示。

1) OAuth2.0协议的安全性。此方面的研究方法以模型抽象验证和形式化证明为主要手段，例如Bansal[3]、Fett[4]、Ferry[5]和文献[6-9]均采用形式化语言描述攻击、建立抽象模型，并以此为基础对大量网站进行安全性验证。此外，也有一些工作尝试从加密证明分析[10]的角度研究 OAuth2.0协议的安全性。但是上述工作仅在理论上分析 OAuth2.0协议的安全性，并没有探讨OAuth 2.0协议在部署应用过程中可能产生的安全问题。

2) OAuth2.0 SDK安全性。OAuth2.0软件开发工具包（SDK, software development kit）是由身份提供方（IdP, identity provider）提供给依赖方（RP,relying party）的开发工具包。若SDK存在安全漏洞，则使用该SDK进行开发的RP都将面临安全风险。此方面的重要研究工作有Wang等[11]使用的构建语义模型方法和Yang等[12]使用动态符号执行方法实现的工具SK3Vetter，前者验证了隐含假设的 SDK存在安全风险，后者则发现了流行OAuth2.0 SDK的7类逻辑漏洞。OAuth2.0 SDK安全性研究面临的最大困难是不同厂商的SDK差异性非常大，并且往往只面向某种特定的开发语言，因而对于每种SDK都需要编写专用的检测工具，并且工具也不方便扩展。

表1 OAuth协议已有安全研究工作总结

3) OAuth2.0部署安全性。IdP和RP在共同实现 OAuth2.0协议时，产生了多种安全风险。针对OAuth2.0实现不当引发的跨站请求伪造（CSRF,cross-site request forgery）攻击，Shernan等[13]和Li等[14]分析了忽视 state参数设置的情形下引发的攻击，王丹磊等[15]和Qiu等[16]分析了OAuth2.0授权API中重定向参数的情况。针对OAuth2.0账号劫持攻击，Mainka等[17]利用恶意IdP收集用户的IdP账号密码从而实施账号劫持攻击，Ghasemisharif等[18]则通过嗅探用户IdP账号的cookie重绑定用户账号进行账号劫持攻击。以上 2种攻击方式都是基于OAuth2.0授权码模式。针对OAuth2.0隐式授权模式场景下，Hu等[19]提出了 APP中间人攻击，Wu等[20]通过研究Dropbox的SSO安全风险提出了未授权访问攻击。这些研究通过对真实部署OAuth2.0协议的应用程序进行手工分析，发现了多种漏洞。

4) OAuth2.0漏洞自动化检测。手工分析OAuth2.0漏洞显然无法满足大规模的安全检测需求，因而很多工作针对自动化检测 OAuth2.0漏洞进行了研究。部分工作利用解析视图的 UI元素实现自动化登录，从而实现自动化地漏洞检测。代表性的工作有Zuo等[1]设计的自动化工具AuthScope和Zhou等[21]实现的自动化检测工具SSOScan。前者用于识别移动应用程序中访问控制漏洞，后者用于自动化检测Facebook API的安全性。另外，部分工作利用网络流量分析实现漏洞的自动化检测，代表性的工作有 Bai等[22]设计实现的 AuthScan和Yang等[23]提出的OAuthTester。前者结合动态行为探测与静态程序分析发现了 OAuth2.0协议部署中的7个安全缺陷，后者基于自适应模型对OAuth2.0协议进行了CSRF风险检测。以上自动化漏洞检测工具对OAuth2.0多种安全威胁进行了大量的检测，但只针对一个或少数几个IdP。

为了弥补现有的 OAuth2.0漏洞自动化检测的不足，本文提出了针对账号劫持攻击的威胁检测框架OScan，并在Alexa排名前10 000的网站上进行测试，覆盖了26个OAuth授权登录接口服务商。

3 账号劫持风险分析

OAuth2.0协议描绘了一个完整安全的第三方认证授权的过程，但是协议的实现却可能引入不可预知的安全风险。本节将在回顾OAuth认证授权过程的基础上分析 OAuth2.0协议存在的风险点，并进一步提出基于OAuth2.0认证授权的账号劫持威胁模型。该模型首先描述了一种新的账号劫持攻击方式，然后从攻击者角度描述形成此类威胁的必要条件。

3.1 OAuth2.0协议风险点分析

OAuth2.0协议提供了4种授权模式[2]：授权码模式、简化模式、密码模式和客户端模式。其中授权码模式在互联网上的应用最广泛，该模式下API的安全问题也是本文研究的主要内容。图1以用户采用OAuth方式登录某个网站为例，简要描述了授权码模式下的授权认证过程。其中，RP代表用户即将登录的网站，该网站使用了OAuth授权登录服务；IdP代表OAuth接口服务提供商，是OAuth2.0 API的提供方。

图1 OAuth2.0授权码模式认证授权过程

认证授权的具体步骤是：1) 用户访问网站并请求通过OAuth登录；2) RP通过用户重定向OAuth登录请求至IdP，要求身份认证；3) 用户通过账号密码等在IdP完成用户身份认证；4) IdP返回登录授权码，同时重定向登录请求至RP；5) RP携带授权码向IdP申请访问令牌；6) IdP校验授权码成功并返回访问令牌；7) RP持访问令牌从IdP获得用户信息；8) RP允许用户登录。

在整个认证授权过程中，步骤4)至关重要，处理不当将产生账号被劫持的风险。授权码是用户登录的关键凭据，但是窃取授权码只是劫持账号的充分不必要条件，因为授权码有2个特点：1)归属性，即只能被发起认证请求的RP使用，在其他RP上无效；2)时效性，OAuth2.0安全规范[24]中指出授权码正确使用后则立即失效，无法二次使用。因此，步骤4)中IdP返回的重定向地址是保证授权码被正确使用的关键，确保合法的RP无法获得和使用授权码。只有在这种情况下，恶意第三方劫持到的授权码才是可用的。

大多数网站的开发人员都会严格限制携带授权码的重定向链接，但是目前依然存在一些方法可以有针对性地绕过限制。本文并不讨论如何绕过重定向链接的限制，而侧重于真实互联网上评估已突破这一限制前提下的账号劫持风险。

3.2 基于OAuth2.0认证授权的账号劫持威胁模型

根据3.1节对于OAuth2.0协议风险点的分析，本节提出了一种新的账号劫持攻击方式，并构建了围绕授权码的账号劫持威胁模型。从攻击者角度出发，若想成功劫持OAuth登录账号，需要具备3个条件。

1) OAuth认证成功后返回的授权码可窃取。在OAuth2.0协议中，授权码是用户通过IdP认证并获得登录授权的唯一凭证，授权码对账号劫持的重要性毋庸赘言，关键在于攻击者如何窃取这一认证授权的核心数据。从网络流量的角度看，OAuth2.0是在HTTP基础上的应用实现，具有明文通信这一先天性脆弱点，因此授权码可以被中间人监听；从业务流程角度看，授权码必须先抵达用户浏览器，再以重定向的方式返回给RP，这又势必面临跨站脚本攻击（XSS, cross site scripting）的威胁。概括起来，授权码被窃取并不是一个独立的安全风险，而是伴生于其他安全风险下的数据泄露问题。

2) OAuth认证成功后返回的重定向链接可劫持。图1步骤4)中，用户在IdP上认证成功后，IdP为其生成授权码，该授权码连同重定向至网站的链接一同返回给用户。如3.1节所述，授权码具有时效性，一旦RP使用该授权码向IdP申请访问令牌，则授权码立即失效。这一过程是在用户浏览器和后端服务器的配合下自动完成的，如果攻击者不能劫持携带授权码的重定向链接，那么即使窃取到授权码也来不及使用。

授权码的归属性要求其只能被发起请求的 RP使用，意味着只要攻击者将重定向链接劫持到任意其他非法地址就能保持授权码的可用性。虽然OAuth2.0威胁规范中已经充分考虑到这一风险，并在IdP和RP参数设计规范中禁止跨域的重定向地址，但是出于功能性的考虑，RP在设计重定向链接参数值时往往不设定唯一的重定向地址，而是给出一个本RP的某个目录地址，只检查重定向链接的前缀是否符合要求。这就扩大了合法重定向参数的限定范围，给了攻击者可乘之机。

本文采用的劫持重定向链接的方法正是利用了上述“漏洞”，并不会将重定向地址劫持为一个跨域地址，而是将其劫持为一个既符合IdP API规范却又和原RP给出的地址不相同的地址，即本域下的某个站点。由于未进行跨域修改，该做法往往被RP和IdP认为是合规的。

3) RP无其他机制二次校验用户登录的合规性。当攻击者窃取到有效的授权码时，仅凭授权码而无其他校验机制成功登录也是一个很大的风险。大量实验表明，一个满足上述2个条件的授权码未必能够在攻击者的浏览器上成功登录 RP，例如攻击者M窃取了合法用户A登录RP1的授权码，虽然该授权码尚未失效，但是 M 在使用该授权码登录 RP1时会引发异常而导致登录失败。这一情况又与 IdP无关，因为同样的场景应用于RP2时，就可能登录成功。因此，本文推测这是由RP采用了其他机制二次校验用户登录的合规性，例如cookie验证。至于推测是否正确及有哪些二次检验机制，并不是本文所要探讨的内容。本文关注的是直接使用带授权码的登录请求不需要cookie验证即可成功登录账号的RP。

根据上述 3个条件，本文建立了基于OAuth2.0认证授权的账号劫持威胁模型，并以有限状态自动机表示为图 2的形式。IdP完成用户的身份认证之后就生成了相应的授权码，如果RP或IdP上存在修改重定向链接的风险，则该授权码就转变为“对攻击者有效”的状态，否则相继转变为“对攻击者无效”和“用户账号劫持失败”状态；如果在整个授权码传输过程中存在中间人、XSS等带外数据（OOB, out of band）攻击风险，则该授权码就转变为“攻击者可窃取”的状态，否则相继转变为“攻击者不可窃取”和“用户账号劫持失败”状态；如果 RP上不存在严格的用户登录合规性校验，则该授权码转变为最终的“可成功劫持用户登录”的状态，否则转变为“用户账号劫持失败”状态。与利用窃取 IdP账号相关信息（如cookie等手段）实现的账号劫持攻击方式相比，该模型描述了一种利用条件相对容易的、新的账号劫持的攻击方式。

3.3 账号劫持威胁检测方法

针对3.2节提出的劫持OAuth登录账号的必要条件，本节将提出相应的检测方法。在判断OAuth认证成功后返回授权码是否可劫持账号方面，本文借鉴传统的Web安全检测方法，提出了基于差异流量分析的脆弱性API识别方法和基于授权认证网络流量监测的账号劫持攻击验证方法。

1)基于差异流量分析的脆弱性API识别方法。对于同一个RP的相同OAuth API调用，构造异常重定向地址参数，并分别自动化触发正常调用和多个异常调用，通过比较返回值的差异，判断认证成功后返回的重定向链接是否可劫持，从而确定该API调用是否具有脆弱性。

图2 基于OAuth2.0认证授权的账号劫持威胁模型

2) 基于授权认证网络流量检测的账号劫持攻击验证方法。通过拦截和重放用户真实的OAuth登录请求，实际验证使用劫持的授权码登录账号的过程，确认RP是否存在用户登录的合规性校验机制。

4 OScan设计与实现

围绕基于 OAuth授权码的账号劫持攻击威胁模型及检测方案，本文设计实现了面向 OAuth2.0授权服务 API的账号劫持威胁检测框架 OScan。OScan由OAuth API检测、OAuth2.0 API脆弱性调用检测、OOB攻击风险检测和授权码登录4个子系统构成。除OAuth API检测子系统外的3个子系统，分别检测目标网站是否满足3.2节提出的账号劫持必要条件： OAuth认证成功后返回的授权码可窃取、OAuth认证成功后返回的重定向链接可劫持和RP无其他机制二次校验用户登录的合规性。OScan的系统架构如图3所示。

4.1 OAuth API检测子系统

OAuth API检测子系统由网页爬虫、流量捕获器、分析引擎和OAuth API模式库4个模块构成，提供检测某个网站是否支持OAuth登录认证，判断提供OAuth服务的IdP和提取OAuth API这3个方面的功能。

网页爬虫以目标网站的首页作为输入，功能是触发页面中全部的点击事件，产生网络流量。文献[10]通过静态匹配当前页面 URL中的关键字（如 client_id、grant_type）来判断是否发生 OAuth API调用，但是一些RP在调用OAuth API时会产生页面 URL的跳转，因此这种方法会产生很高的漏报率。与文献[25]提出的基于规则库的网络爬虫方法相似，OScan采用更加精准的捕获并分析实际流量的方法检测网页中的OAuth API调用。流量捕获器实际上是一个HTTP和HTTPS代理，可以捕捉到网页爬虫触发的全部流量，并输入给分析引擎。分析引擎提取其中的请求地址，并在OAuth API模式库中查找匹配，检测是否触发了OAuth API调用。OAuth API模式库收集了来自26个知名IdP的全部OAuth API的模式特征。

这26个IdP由维基百科公布的国际知名OAuth IdP和国内知名OAuth IdP共同组成，覆盖面广泛。如果当前页面中未能发现OAuth API调用，网页爬虫还将按照预置列表搜索登录关键字（如 login、signin、oauth、log-in、sign-in等），OScan还将尝试在首页的下一级发现登录页面。算法 1给出了API提取的伪代码描述。

算法1API提取

输入目标网站，API模式库，登录关键字

输出OAuth授权API

1) 渲染目标网站首页，构建DOM树

2) for DOM节点 in DOM树 do

3) 触发DOM节点的点击事件

4) for 匹配规则 in API模式库 do

5) if 流量 match 匹配规则 then

6) 输出该API调用

7) end if

8) end for

9) for 关键字 in 登录关键字表 do

10) if 关键字 in 流量 then

11) 将其作为新目标重复步骤 1)～步骤14)

12) end if

13) end for

14) end for

4.2 OAuth2.0 API脆弱性调用检测子系统

OAuth2.0 API脆弱性调用检测子系统的任务是检测特定的 OAuth2.0 API是否存在可劫持重定向参数的漏洞，由参数定位、参数修改和差异分析 3个功能模块构成。

OScan检测OAuth2.0 API调用脆弱性的思路如下。首先，参数定位模块以实际OAuth2.0 API调用流量为输入，识别其中的各个参数，尤其是精准定位重定向地址参数。由于OScan只面向26个 IdP提供的有限 API，因此对各个参数的定位采用了枚举的方法。其次，参数修改模块将重定向参数修改为同一父域下的不同子域或同一域下的不同页面，并重新向IdP发起请求。为覆盖更多的测试路径，该模块借鉴“鸟枪法”思路，将多次尝试，分别将重定向参数修改为不同的值。最后，模块接收正常传参和异常传参下API调用的响应返回值，本文利用差分网络流量分析法进行脆弱性识别。即如果检测到任意一次异常传参后的API返回内容与正常传参的情况相同，则表明检测到了OAuth2.0 API脆弱性调用，否则不存在脆弱性调用。算法2给出了OAuth2.0 API脆弱性调用检测的伪代码。

算法2OAuth2.0 API脆弱性调用检测

输入OAuth2.0 API调用列表

输出脆弱的OAuth2.0 API调用

1) for API调用 in OAuth2.0 API调用列表:

2) 回调值=API调用中’redirect_uri’参数值

3) 前，中，尾=以回调值划分的API调用

4) 域名=回调值中的域名

5) 链接=爬取域名网站

6) for 链接1in 链接:

7) if 链接1 != 回调值:

8) 新请求=前+链接1 +尾

9) 响应1=发送新请求

10) 响应2=发送原来的请求

11) if 响应1==响应2:

12) 该OAuth2.0 API调用具有脆弱性

13) break

14) end if

15) end if

16) end for

17) end for

4.3 OOB攻击风险检测子系统

OOB攻击并没有公认的准确定义。本文使用这一术语表示“通过信息系统预定功能之外的方式非法传输数据的技术或行为”，例如Web安全领域的SQL注入、XSS和XXE可都能引发OOB风险，文献[26]也提到了利用XSS的方式。

OScan中实现的OOB攻击风险检测子系统可以自动检测3项风险：网站是否存在XSS漏洞、网站是否可嵌入外部资源和网站是否可以使用HTTP访问。检测到上述任意一种风险，都表明攻击者有机会窃取到OAuth2.0 API返回的授权码。这部分工作在Web安全领域已有成熟的技术[27]和方法，本文不再详述。

4.4 授权码登录子系统

OScan的最后一步工作是尝试使用“劫持”的授权码自动登录网站，并通过与此前人工登录成功的页面对比，判断劫持账号是否成功。如果成功，则确认网站存在基于OAuth2.0认证授权的账号劫持风险。

本文在授权码登录子系统中利用流量分析法来验证使用授权码登录的安全威胁，由授权登录和验证2个模块组成。由于涉及自动化登录，授权模块针对26个IdP，首先收集了其账号的cookie信息，使其不需要输入账号密码即可成功完成认证。授权登录模块使用Burp Suite实现。它模拟用户发送第三方登录认证请求（携带账号cookie信息），自动进行登录授权。然后从拦截的流量中通过识别“code”关键字提取出带有授权码的登录请求，将其发送至验证模块，验证模块收到来自授权模块的请求，向RP发送登录请求（不带cookie信息），获取流量。

若流量中存在类似“remember_user_token”令牌，如图4所示，则验证了该RP存在账号劫持风险；反之，则说明不具有该风险。算法3给出了账号劫持攻击验证算法的伪代码。

图4 验证成功登录流量

算法3账号劫持攻击验证

输入RP列表，IdP账号cookies

输出存在账号劫持风险的RP

1) for RP in RP列表:

2) for cookie in IdP账号cookies:

3) 向RP发送带有cookie的登录请求

4) if code参数 in 流量:

5) 请求1=带code的认证请求

6) end if

7) 向RP发送请求1，获取响应

8) if remember_user_token in 响应:

9) RP存在账号劫持风险

10) else

11) RP不存在账号劫持风险

12) end if

13) end for

14) end for

5 效果评估

本节基于第4节设计的OScan系统，选取Alexa排名前10 000的网站作为测试对象，从是否存在登录劫持风险的角度评测互联网上 OAuth认证授权的安全现状。

5.1 OAuth应用现状

对Alexa排名前10 000的网站进行测量，结果如图5所示，得到OAuth应用现状如下。

图5 API调用流行度

1) Alexa排名前10 000的网站中，有1 881个网站支持OAuth的认证登录，占比接近20%，可见OAuth确实是颇受欢迎的SSO解决方案。

2) 在1 881个支持OAuth认证登录的网站中，累计检测到3 853个OAuth API调用，这表明平均每个网站提供2种不同的OAuth登录认证服务供用户选择。

3) Facebook和谷歌是最受青睐的IdP，市场占比分别达到 35.61%和 26.27%，并且参与测试部国外网站几乎都支持以 Facebook和谷歌账号登录。

4) 包括推特、领英在内的若干个IdP仍然提供基于OAuth 1.0a协议实现的API（图5中带*的IdP），并且3 853频次的OAuth API调用中也有402频次采用了OAuth 1.0a协议，可见老旧的OAuth 1.0a协议仍然占据一定的市场份额。

虽然测量结果表明仍有相当部分网站使用OAuth 1.0a协议认证授权，但更新、更安全的OAuth2.0协议取代OAuth 1.0a协议已经是大势所趋，因此本文后续工作只针对其余 3 451个OAuth2.0 API调用做进一步的登录劫持风险分析。

5.2 脆弱性API调用分析

本文在3.2节提出了劫持OAuth登录账号的3个必要条件，其中，只有条件2)与OAuth API相关，造成重定向链接被劫持的原因既可能是IdP检查重定向参数不严格，也可能是RP未能严格遵循API调用规范，本文将这2种情况统称为“脆弱性API调用”，可以视为一种漏洞。

实验结果如表2所示。在OScan检测的3 451个OAuth2.0 API调用中，有360个是脆弱性调用，占总数的10.43%，并且个别IdP提供的OAuth2.0 API脆弱性调用竟然超过 50%。由此可见，脆弱性OAuth2.0 API调用不仅普遍存在，而且在个别OAuth服务中还相当严重。从测量结果看，并不是隶属于同一IdP下的全部API调用都存在问题，这说明脆弱性API调用并非IdP或RP单方原因，而是双方共同导致的。因此，IdP开发OAuth2.0 API和RP调用OAuth2.0 API时，都应当在满足功能性需求的同时充分考虑安全性需求。

5.3 登录劫持风险分析

本节尝试检测满足劫持OAuth登录账号全部3个必要条件的网站，显然是5.2节分析结果的子集。为满足劫持OAuth登录账号的条件1)，OScan检测至少符合以下一种情况的网站：网站存在可嵌入外部资源的漏洞以及IdP与RP间的通信采用HTTP，是明文流量。为满足劫持 OAuth登录账号的条件3)，本文在每个 IdP上都注册了大量账号，OScan将使用劫持的授权码模仿攻击者尝试实际登录。

实验结果如表3所示。全部360个存在脆弱性OAuth2.0 API调用中，有101个调用可以被攻击者成功用于劫持登录账号，占比达到28.05%。这101个API调用覆盖了80个网站，涉及10个著名的IdP。虽然存在 OAuth登录劫持脆弱性的网站比例不高，但是泄露的隐私可能进一步导致用户IdP账号被窃取，由此引发的次生安全问题将不可估量。

表2 脆弱性API调用结果

表3 API调用登录劫持风险结果

表4 自动化检测工具对比

5.4 OScan的优势分析

本节将OScan与其他OAuth漏洞自动化检测工具进行对比，结果如表 4所示。通过对输入、IdP数量、RP数量、可检测漏洞类型、脆弱点数量、完整攻击风险数量、可否拓展7个方面进行比较，发现OScan在以下4个方面都具有优势。

1) OScan在覆盖的IdP上具有全面性。相较于其他工具仅考虑了一个或少数几个 IdP，OScan覆盖了26个IdP，包括主流的Facebook、谷歌等。

2) OScan对广泛的RP进行了检测。OScan对Alexa排名前10 000的网站进行了检测，大部分的工具所检测的RP数量远远少于OScan的这一数量。

3) OScan能够检测OAuth2.0中新的安全风险点。OScan能识别出360个具有账号劫持攻击风险的脆弱点，这种能力是其他工具不具备的。

4) OScan能够检测完整的攻击风险。OScan在识别出脆弱性API的基础上，还对由此引发的账号劫持攻击进行了检测，这也是其他工具所不具备的能力。

综上，与已公开的类似工具相比，OScan在覆盖的IdP数量、检测的RP数量、检测完整攻击风险等方面均具有非常明显的优势。

5.5 案例分析

某网站支持某 IdP OAuth认证授权，其 API调用如图6所示。其中，client_id参数表示客户端的 ID，用于标识网站应用；redirect_uri参数表示重定向链接；response_type参数表示授权类型；此处的值“code”表示采用授权码模式；state参数表示客户端的当前状态值，可以设定为任意值，认证服务器会原封不动地返回该值，其作用是防止CSRF攻击。

图6 某网站调用某IdP OAuth认证授权API实例

OScan分析表明，该 API中的重定向地址（redirect_uri参数）可以被替换为本站的其他地址，且认证过程采用了未加密的HTTP。图7是重定向地址被劫持后的API调用。

图7 攻击者利用XSS漏洞读取授权码

OScan分析还表明，劫持后的重定向地址http://www.xxxxx.com/p/1fc5dfb44e8f恰好存在XSS漏洞。因此，攻击者可以通过钓鱼邮件诱使用户点击链接发起OAuth认证，从而窃取IdP返回的授权码，完成登录劫持。图8展示了攻击者利用XSS漏洞读取的授权码。

图8 授权码登录接口

6 讨论

6.1 局限性分析

本文研究探讨了OAuth2.0 API的安全问题，构建了基于授权码的账号劫持攻击模型，并在此基础上设计实现了自动化检测工具 OScan。虽然本文利用OScan对10 000个网站进行了大规模的账号劫持风险检测，并得到了实验结论，但本文的工作仍然具有一定的局限性。首先，仅针对基于授权码模式的OAuth2.0授权API进行安全性分析与检测，没有对其他授权模式（如隐式模式）下的授权API进行研究；其次，未覆盖其他平台（如 Android、iOS等）应用程序的授权 API；最后，OScan在技术细节上仍有提高空间，例如API提取的结果会因网络状况受到影响，且在提取出网站登录链接时所匹配的关键字单词集可能不够完善，因此会存在一定的API遗漏的情况。

6.2 缓解措施

为防御针对OAuth2.0授权API的账号劫持攻击，第三方应用程序在实现授权码模式过程中必须严格地遵循规范，本文建议应做到以下3点。1)严格限制重定向链接参数的值。为了防止攻击者篡改重定向链接的值，RP不应当将重定向的值注册为某个目录，而是指定唯一地址。对于IdP而言，应当在开发文档中要求开发人员将重定向链接的参数设置为唯一确定值。2)提高RP和IdP自身的安全性。包括严格限制外部资源的嵌入、全面排查和修复XSS漏洞，防止攻击者通过OOB的方式窃取授权码；整个授权认证过程都部署HTTPS，以通信内容加密的方式确保授权码无法被攻击者窃取。3)对OAuth2.0授权认证过程进行完整性校验，如RP主动检查用户cookie。在RP向IdP申请认证授权时，RP需建立申请认证的用户与某个指定参数之间的联系（如state参数），在后续RP接收到带有授权码的授权请求时，将用户与提交的某个指定参数进行校验，只有符合关联的请求方可继续向 IdP申请令牌，防止攻击者使用窃取的授权码直接成功登录用户账号。

7 结束语

在第三方登录变得越来越受欢迎的同时，安全风险也随之而来。基于此，本文对OAuth 2.0授权API的安全性进行了深入研究，构建了基于授权码的账号劫持攻击模型。此外，为了检测这一安全威胁，本文设计实现了针对 OAuth2.0授权服务 API的威胁检测框架OScan，该工具通过差异流量分析方法识别出脆弱性API，通过基于授权认证网络流量监测的方法进行账号劫持攻击验证。为了评估互联网上 OAuth2.0授权 API的安全现状，本文对Alexa排名前10 000的网站OAuth2.0授权API进行了实验。结果表明，10.43%的API存在重定向链接可被修改的脆弱点，其中 80个第三方网站的用户账号都可以被成功劫持，进而获取用户隐私信息，存在着严重的安全隐患。开发者和IdP都应对此引起重视，严格遵守协议规范，对各个脆弱点进行防范，保证其安全性。

本文所实现的OScan虽然对Alexa排名前10 000的网站中OAuth2.0授权服务API的账号劫持攻击威胁进行了安全性检测测量，但未来仍有提升空间，包括实现对OAuth2.0协议的其他授权模式（如隐式模式）、其他平台（如移动应用）的安全性分析，使 OScan成为适应多平台、多授权模式的OAuth2.0账户劫持攻击威胁检测工具。