OAuth协议安全性研究

２０１３年第０３期　曩ｄｏｉ：１０　３９６９／ｊ　ｉｓｓｎ　１６７１・１１２２．２０１３　０３　０１８　ＯＡｕｔｈ协议安全性研究　张天琪　（北京工业大学，北京１０００２２）　摘要：ＯＡｕｔｈ是＇３下最流行的开放式授权协议，目前在整个互联网得到了相当广泛的应用。文章主要　－对ＯＡｕｔｈ协议的整体安全性进行了研究，通过测试案例展示其安全问题造成的危害，并提出了相应的防御措　施以及整体安釜｝生的提升方法。　关键词：ＯＡｕｔｈ；授权协议；账号劫持；开放式授权　中图分类号：ＴＰ３９３．０８　文献标识码：Ａ　文章编号：１６７１—１１２２（２０１３）０３—００６８—０３　Ｓｔｕｄｙ　ｏｎ　ＯＡｕｔｈ　Ｐｒｏｔｏｃｏｌ　Ｓｅｃｕｒｉｔｙ　ＺＨＡＮＧ　Ｔｉａｎ—ａｉ　（Ｂｅｉｊｉｎｇ　Ｕｎｉｖｅｒｓｉｔｙ　ｏｆＴｅｃｈｎｏｌｏｇｙ，Ｂｅｉｊｉｎｇ　１０００２２，Ｃｈｉｎａ）　Ａｂｓｔｒａｃｔ：ＯＡｕｔｈ　ｉｓ　ｎｏｗ　ｔｈｅ　ｍｏｓｔ　ｐｏｐｕｌａｒ　ｏｐｅｎ　ｓｔａｎｄａｒｄ　ｆｏｒ　ａｕｔｈｏｒｉｚａｔｉｏｎ．Ａｍｏｎｇ　ｔｈｅ　Ｉｎｔｅｍｅｔ，ａ　ｗｉｄｅ　ｒａｎｇｅ　ｏｆ　ａｐｐｌｉｃａｔｉｏｎｓ　ｈａｓ　ｂｅｅｎ　ｕｓｅｄ．Ｔｈｉｓ　ａｒｔｉｃｌｅ　ｆｏｃｕｓｅｓ　ｏｎ　ｔｈｅ　ｏｖｅｒａｌｌ　ｓｅｃｕｒｉｔｙ　ｏｆ　ｔｈｅ　ＯＡｕｔｈ　ａｕｔｈｏｒｉｚａｔｉｏｎ　ｐｒｏｔｏｃｏｌ　ｓｔｕｄｙ，ｄｉｓｐｌａｙｓ　ｔｈｅ　ｈａｒｍ　ｃａｕｓｅｄ　ｂｙ　ｔｈｏｓｅ　ｓｅｃｕｒｉｔｙ　ｉｓｓｕｅｓ　ｔｈｒｏｕｇｈ　ｔｈｅ　ｔｅｓｔ　ｃａｓｅ，ａｎｄ　ｐｕｔｓ　ｆｏｒｗａｒｄ　ｔｈｅ　ｃｏｒｒｅｓｐｏｎｄｉｎｇ　ｄｅｆｅｎｓｉｖｅ　ｍｅａｓｕｒｅｓ，ａｓ　ｗｅｌｌ　ａｓ　ｔｈｅ　ｏｖｅｒａｌｌ　ｓｅｃｕｒｉｔｙ　ｕｐｇｒａｄｅ　ｍｅｔｈｏｄ．　Ｋｅｙ　ｗｏｒｄｓ：ＯＡｕｔｈ；ａｕｔｈｏｒｉｚａｔｉｏｎ　ｐｒｏｔｏｃｏｌ；ａｃｃｏｕｎｔ　ｈｉｊａｃｋｉｎｇ；ｏｐｅｎ　ｓｔａｎｄａｒｄ　ｆｏｒ　ａｕｔｈｏｒｉｚａｔｉｏｎ　１　ＯＡｕｔｈ协议特性　ＯＡｕｔｈ（开放授权）是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密资源（如照片、视频、联　系人列表），而无需将用户名和密码提供给第三方应用Ⅲ。ＯＡｕｔｈ是一种授权协议而非认证协议。认证关注的是用户是谁，一般　通过用户名和密码来进行认证。授权关注的是用户在做什么，它以资源为主体，通常的授权形式是组和权限。如果滥用授权和认　证协议，就会导致很多安全隐患。ＯＡｕｔｈ协议最大的进步是能够使第三方在不获得目标网站账号和密码的情况下使用目标网站的　用户资源，这也是当前ＯＡｕｔｈ应用如此之广的一个原因。随着开放式ＲＥＳＴ（ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ　ｓｔａｔｅ　ｔｒａｎｓｆｅｒ，表述性状态转移）风　格的ＡＰＩ的广泛使用，ＯＡｕｔｈ协议也被应用地越来越广泛，现在很多网站建立了自己的开放平台，这些平台会提供、执行一些操　作的ＡＰＩ，有了这些操作的ＡＰＩ，就必然要有安全保证，ＯＡｕｔｈ协议也就应运而生。ＯＡｕｔｈ协议对用户、消费方和服务提供者都　有极大好处。对于用户来说免去了繁琐的注册过程，降低了注册成本，提高了用户体验；对于消费方来说简化了自身会员系统，　同时又带来更多的用户和流量；对于服务提供者来说围绕自身进行开发可以增加用户黏性。ＯＡｕｔｈ协议分为１．０和２．０版本，下面　将分别探讨它们及它们的安全问题。　２　ＯＡｕｔｈ１．０及安全问题　国内很多应用的ＯＡｕｔｈ协议已经升级到了２．０版本，但是部分电商因业务比较广泛，使得升级２．０版本付出的代价很大，故　而仍然使用１．０版本的ＯＡｕｔｈ协议。　ＯＡｕｔｈ１．０授权流程并不复杂，但是实际上由于授权过程中存在很多密钥、令牌及签名运算，它们相互之间又存在各种各样　的牵连，因而开发人员往往关注于繁琐的授权过程而忽略了一些可能造成安全隐患的地方。ＯＡｕｔｈ１．０中存在一个比较严重的安　全漏洞：ｓｅｓｓｉｏｎ　ｆｉｘａｔｉｏｎ　ａｔｔａｃｋ（会话固话攻击）　，产生这个攻击的原因主要是用户被同意授权后，用户被跳转到一个回调地址，　这个回调地址一般是在第三方平台。如果对这个回调地址没有进行检查和限制，也没有任何机制保证整个授权流程只由一个人　完成，那么就会造成安全问题，导致攻击者可以访问目标网站的用户资源。以下是该安全漏洞的攻击流程：攻击者首先启动授　权流程，记录未授权的ｒｅｑｕｅｓｔ＿ｔｏｋｅｎ，用当前ｕｒｌ诱骗用户访问。用户被同意授权后，被重定向到其他位置。攻击者之前记录的　ｒｅⅡｕｅｓｔ　ｏｔ　ｋ　　ｅｎ此时已经被目标授权，使用由这个令牌构造的相应ｕ　ｒ１即可访问用户资源。●　收稿时间：２０１２—１２—１５　作者简介：张天琪（１９９２一），男，北京，本科，主要研究方向：Ｗｅｂ相关安全研究。　Ｉ　６８　２０１３年第０３期　下面给出了一个新浪微博存在的此类安全漏洞　缺陷编号　ＷｏｏＹｕｎ－２０１０－Ｏ０７８１　满洞标题：Ｓｉｎａ撇博ＯＡｕｔｈ提供者存在ｓｅｓｓｉｏ￣ｆｉｘａｔｌｏｎ　ａ￣ａｃｋ潲溺　Ｉｍｐｌｉｃｉｔ　Ｇｒａｎｔ　是客户端的授权流程，无需服务端配合。　这样会导致ａｃｃｅｓｓ—ｔｏｋｅｎ被暴露在客户端，是ＯＡｕｔｈ２．０中公　认的最不安全的授权流程（如图２所示）。　钼关厂商．新渡　漏洞作者：路＾甲　提交时间　２０１０一ｌ　１－０３　公开时问：２０１０－ｌｉ－０８　涌涧类型：设计缺７ａｔ逻辑错误　危害等圾　中　宙评Ｒａｎｋ　１０　曼瓣　漏洞状态　漏洞已经通知厂商但是厂商忽略漏凋　漏洞来源：ｈｔｔｐ：／／ｗｗｗ．ｗｏｏｙｕｎ．ｏｒｇ　黧　Ｔａｇｓ标签：ｓｎ霉费蠛！斑用ｘｓｓ　ｕｒｌ踺转　ＯＡｕｔｈ　ｓｅｓｓｉｏｎ＋ｆｉｘａｔｉｏｎ＋ａｔｔａｃｋ　ＯＡｕｔｈ１．０ａ版本中已经修复了此漏洞。首先为防止＝吱击者篡　改回调地址，ｏａｕｔｈ—ｃａｌｌｂａｃｋ（即回调地址）字段在请求未授权　的ｒｅｑｕｅｓｔ—ｔｏｋｅｎ的时候即传递给平台方并参与签名计算。平台　方获得用户授权后重定向用户到第三方应用时会返回一个随机　值，用在第三方申请ａｃｃｅｓｓ＿ｔｏｋｅｎ的过程当中。由于随机值无法　被猜测，因此系统能够有效防止攻击者劫持授权过程。　３　ＯＡｕｔｈ２．０及安全问题　ＯＡｕｔｈ１．０中只提供了＿一种授权流程，ＯＡｕｔｈ２．０进行了扩充，　它提供了多种授权流程，这里详细介绍其中３种比较流行的授　权流程：Ａｕｔｈｏｒｉｚａｔｉｏｎ　Ｃｏｄｅ授权流程适用　Ｆ有Ｓｅｒｖｅｒ端配合　的应用；Ｉｍｐｌｉｃｉｔ　Ｇｒａｎｔ授权流程适用于无Ｓｅｒｖｅｒ端配合的应　用；Ｒｅｓｏｕｒｃｅ　Ｏｗｎｅｒ　Ｐａｓｓｗｏｒｄ　Ｃｒｅｄｅｎｔｉａｌｓ授权流程直接使用用　户名和密码进行授权。此外还有一种使用ｒｅｆｒｅｓｈ—ｔｏｋｅｎ获取　ａｃｃｅｓｓ—ｔｏｋｅｎ的方式。　ＯＡｕｔｈ２．０与１．０版本的区别在于以下几点　］：　（１）ｒｅｑｕｅｓｔ—ｔｏｋｅｎ在２．０版本中不再使用。　（２）取消所有签名计算，整个授权流程使用ＨＴＴＰＳ确保　安全性。　（３）授权流程大大简化，安全性有所提高。　（４）２．０版本与１．０版本不兼容，是一个全新的协议。这　也是很多老的厂商不进行升级的原因。　下面先来看—下Ｒｅｓｏｕｒｃｅ　Ｏｗｎｅｒ　Ｐａｓｓｗｍ－ｄ　Ｃｒｅｄｅｎｔｉａｌｓ授权　流程（如图１所示）。　、蒋求：。。　　；ｊ　ｈｔｃｌｉｔｅｎｔｐｓ：／～／ｏｐｅｎ．ｉｄ＝ｌｌｌｌｌｌＸＸＸ．ｃｏｍ／ｌ＆ｃｌｏａｕｔｉｅｎｔ　ｈ２／ｓｅｃｒａｃｅｔｃｅｓ＝ｆ７４ｓ—ｔ０４ｋｏ９ｓ７ｏｋｅｎ？　４８７２８３１３　ｉ＆ｇｒａｎｔ．　ｔｙｐｅ＝ｐａｓｓｗｏｒｄ＆ｕｓｅ￣ｎ　ａ｛ｈ＇ｅ＝：ｘｘｘ＆ｐａ％ｗｏｒｄ＝ｘｘｘ　图１　Ｒｅｓｏｕｒｃｅ　Ｏｗｎｅｒ　Ｐａｓｓｗｏｒｄ　Ｃｒｅｄｅｎｔｉａｌｓ授权流程　图１中浏览器发出的ｕｒｌ有几个关键字段：ｃｌｉｅｎｔ．ｉｄ和　ｃｌｉｅｎｔ—ｓｅｃｒｅｔ都是第三方在开放平台注册初始时必须有的值，　ｉｄ是公开的，ｓｅｃｒｅｔ是保密的。ｇｒａｎｔ—ｔｙｐｅ在当前授权模式下　的固定值是ｐａｓｓｗｏｒｄ。ｕｓｅｒｎａｍｅ和ｐａｓｓｗｏｒｄ是用户在资源提　供方注册的用户名和密码。这种授权方式需要开放平台对第　三方有着充分的信任。恶意应用如果使用该方式授权，会导　致暴力破解资源提供方的用户账号和密码。　图２　Ｉｍｐｌｉｃｉｔ　Ｇｒａｎｔ授权流程　第三方平台请求图２中第一个框中的ｕｒｌ，其中ｒｅｄｉｒｅｃｔ—ｕｒｉ　是一个回调地址，当用户同意授权后就跳转到该地址。　ｒｅｓｐｏｎｓｅ—ｔｙｐｅ在当前模式下的固定值是ｔｏｋｅｎ。开放平台响应　这个ｕｒｌ，它直接将ａｃｃｅｓｓ—ｔｏｋｅｎ挂在回调地址后面作为ｕｒｌ的　ｆｒａｇｍｅｎｔ（ｕｒｌ中＃号以后）部分，被用户直接在浏览器中看见。除　了ａｃｃｅｓｓ—ｔｏｋｅｎ外，开放平台还会返回ｅｘｐｉｒｅｓ—ｉｎ（过期时间）、　ｒｅｆｒｅｓｈｔｏｋｅｎ（用于刷新ａｃｃｅｓｓ＿ｔｏｋｅｎ）、ｓｃｏｐｅ（请求的权限）。　下面给出了一个人人网上存在的此类安全漏洞：　缺陷编号：ＷｏｏＹｕｎ－２０１２—０５８０４　漏洞标题：人人￣Ｏａｕｔｈ　２　Ｏ授权可导致用户ａｃｃｅｓｓ＿ｔｏｋｅｎ泄露　相关厂商：人人网　漏洞作者：ＰｉａＣａ　提交时阐：２０１２－０４一ＯＳ　公开时间：２０１２－０５－２０　漏洞类型：敏感信息泄越　危害等圾：嵩　自评Ｒａｎｋ：ｉ０　漏洞状惑：厂商已经确认　漏洞泉源：ｈｔｔｐ：／／ｗｗｗ．ｗｏｏｙｕｎ．ｏｒｇ　Ｔａｇｓ￣签：无　这个漏洞产生的原因是ｃｌｉｅｎｔ—ｉｄ与ｒｅｄｉｒｅｃｔ—ｕｒｉ没有做　过校验或者信任域过大，配合信任域下的ＸＳＳ（跨站脚本攻　击）就可以劫持用户的ａｃｃｅｓｓ—ｔｏｋｅｎ。例如，访问ｈｔｔｐ：／／ｇｒａｐｈ．　ｒｅｎｒｅｎ．ｃｏｍ／ｏａｕｔｈ／ｇｒａｎｔ？ｃｌｉｅｎｔ——ｉｄ＝ｃｄ２７１ｅ３０５１４４４２８５ｂ８ａ１８ｆ１２１　１　ａ０９５ｃｄ＆ｒｅｄｉｒｅｃｔ——ｕｒｉ＝ｈｔｔｐ：／ｚｏｎｅ．ｋｕ６．ｃｏｍ／ｕ／１７９５８６２０＆ｒｅｓｐｏｎｓｅ　—ｔｙｐｅ＝ｔｏｋｅｎ，最后跳转到存在ＸＳＳ的酷６网站页面ｈｔｔｐ：／ｚｏｎｅ．　ｋｕ６．ｃｏｍ／ｕ／１７９５８６２０，攻击者可以在该页面插入一段恶意的　Ｊａｖａｓｃｒｉｐｔ代码来解析存在于ｕｒｌ的ｆｒａｇｍｅｎｔ（ｕｒｌ中｝｝号以后１　部分中的ａｃｃｅｓｓ—ｔｏｋｅｎ。　下面是隐式授权流程下的劫持攻击流程图（如图３所示）：　……一Ⅲ　　ｆ｝蛾珩ａｆ顶弱ｉｉ瑟　详　ｃｃｅｓｓ　ｌ…　　ｌ　…～　…一』　图３隐式授权下的劫持攻击流程图　除了＿上文所说的安全问题，还存在一个越权ＡＰＩ访问的　安全问题。授权服务器通常会给予第三方应用一些访问基础　功能ＡＰＩ的权限。如果用高权限ＡＰＩ，需要指定ｓｃｏｐｅ（请求　６９　２０１　３年第Ｏ３期　的权限）进行申请。若ａｃｃｅｓｓ—ｔｏｋｅｎ没有与应用的ａｐｐｋｅｙ（开　放平台注册时所分配的唯一值）绑定，即任何令牌均可以去　申请任何权限，则可以越权访问受限制的ＡＰＩ。通过在ｕｒｌ　后面添加ｓｃｏｐｅ参数，后面跟上想去越权访问的一个高权限　的ＡＰ１名字来实现。最后在回调地址的ｆｒａｇｍｅｎｔ部分获得　ａｃｃｅｓｓ—ｔｏｋｅｎ，此时该令牌已经被授权使用一些高级权限的　接口。　Ａｕｔｈｏｒｉｚａｔｉｏｎ　Ｃｏｄｅ授权流程需要Ｓｅｒｖｅｒ端配合，属于　两步授权。首先第ｊ方应用跳转到授权应用页面请求ｃｏｄｅ，　用户同意授权后，授权服务器返回ｃｏｄｅ。第三方应用使用　ｃｏｄｅ请求ａｃｃｅｓｓ—ｔｏｋｅｎ，授权服务器以响应体的形式返回　ａｃｃｅｓｓｔｏｋｅｎ。图４给出的是第三方应用两次请求的ｕｒｌ：　ｈｔｔｐｓ：ｌｌａｐｉ．ｗｅｉｂｏ　ｃｏｍ／ｏａｕｔｈ２１ａｕｔｈｏｒｉｚｅ？ｃｌｉｅ￣１　ｊ　ｉｄ＝ｌｌｌｌｌｌｌ＆ｒｅｄｃｅｃｔ　ＵＩｉ＝ｈｔｔｐ：／／ｗｗｗ．ｘｘｘ　ＣＯ　／　ｎａｗｅ！￣？＆！！！曼　ｎｓｅ　一ｔｙ　　ｐ　ｅ三　ｄ　ｈｔｌｐｓ：／／ａｐｉ　ｗｅｉｂｏ．ｃｏｍｌｏａｕｔｈ２／ａｃｃｅｓｓ～ｆｏｋｅｎ　ｉｅｎＬ　ｊ　Ｉｄ＝１１１１１１１＆ｃｌｉｅｎｌ坩ｓｅｃｒｅｔ＝ｌ２９ｄｇｐ０３ｍ２＆　ａｎｔ　ｔｙｐｅ　｛＝ａｕｔｈｏｒｉｚａｔｉｏｎ　ｃｏｄｅ＆ｒｅｄｉｒｅｃｔ　ｕｒｉ＝ｈｔｔｐ：／／ｗｗｗＸＸＸ｛　ｃｏｍ／ｃｏｎｎｅｃｌＪｓｉｎａｗｅｉｂｏ？＆ｃｏｄｅ＝１ｓｋ４２１ｆ０ｓ　　ｉ图４第三方应用两次请求的ｕｒＩ　第一次请求与之前的授权方式比较，仅ｒｅｓｐｏｎｓｅ—ｔｙｐｅ有　了改变，现在固定值是ｃｏｄｅ。第二次请求使用从授权服务器　获得的ｃｏｄｅ请求ａｃｃｅｓｓ—ｔｏｋｅｎ。从图４中可以看到之前获得的　ｃｏｄｅ是ｌｓｋ４２１ｆ０ｓ。　同样这种授权流程也存在安全问题。下面结合测试案例　来展示这个ＣＳＲＦ（跨站请求伪造）攻击【５】。　测试场景：攻击者通过新浪微博劫持目标的３６０主站以　及３６０浏览器账号。　目标首先处于３６０平台登录状态，未绑定任何第三方账号。　攻击者通过新浪微博登录３６０，点击授权后阻止页面自　动跳转。用要跳转到的ｕｒｌ诱骗目标访问，目标访问ｕｒｌ。此　时在用户不知情的情况下将目标的３６０账户绑定到攻击者的　新浪微博上，之后我们可以使用新浪微博账号登录目标的３６０　浏览器，此时可以查看其历史记录、收藏夹等隐私数据。　假设我们已经通过ＣＳＲＦ劫持了用户的某个账号，且此时　目标账号所在网站不仅使用ＯＡｕｔｈ协议，而且还提供ＯＡｕｔｈ　授权登录机制。则我们不仅能够通过别的网站账号来登录我　们的网站，还可以通过我们这个网站账号来登录别的网站。如　果用户使用这个被劫持的账号登录过别的网站，攻击者则可　以通过这个已被劫持的账号继续劫持该用户的其他网站账号，　这样就形成了一个ＣＳＲＦ的递归劫持。有时网站会通过设置　强制登录字段强制用户输入第ｊ方的账号和密码信息，我们　可以通过修改该字段为ｆａｌｓｅ直接读取当前会话来登录，即可　以继续劫持该网站的账号。　除此之外，Ａｕｔｈｏｒｉｚａｔｉｏｎ　Ｃｏｄｅ授权流程还有另外一种　Ｉ　７０　安全问题：ｒｅｐｌａｙ　ａｔｔａｃｋ（授权码重放攻击）。一般情况下，　Ａｕｔｈｏｒｉｚａｔｉｏｎ　Ｃｏｄｅ会随着ａｃｃｅｓｓ—ｔｏｋｅｎ的过期而过期，规范中　建议过期时间为６０～８０ｍｉｎ，且要保证授权码仅可以用一次。　很多资源提供方为了降低授权成本，没有严格按照规范实施，　有的过期时间甚至达到一周，从而可以通过这个Ａｕｔｈｏｒｉｚａ｜ｉｏｎ　Ｃｏｄｅ授权流程去重复获得ａｃｃｅｓｓ—ｔｏｋｅｎ。我们可以通过以下几　种方式获取目标授权码　ｌ：在获得服务器权限的情况下，通过　日志获取大量的目标授权码；通过嗅探获得目标授权码，因为　回调地址位于客户端，不会强制使用ＨＴＴＰＳ，这样就给了攻　击者可乘之机；通过ＸＳＳ获得目标授权码，配合目标网站信　任域下的ＸＳＳ可以实现劫持ｃｏｄｅ。　４　ＯＡｕｔｈ漏洞防御及安全性提升措施　对于资源提供方来说，首先要对ｃｌｉｅｎｔ—ｉｄ和回调地址做　严格校验，确保获取ａｃｃｅｓｓ—ｔｏｋｅｎ的ｃｏｄｅ仅能使用一次以避　免受到重放攻击，尽量避免直接读取当前用户的ｓｅｓｓｉｏｎ进行　绑定。对于资源使用方来说，应该使用Ａｕｔｈｏｒｉｚａｔｉｏｎ　Ｃｏｄｅ方　式进行授权，授权过程中使用ｓｔａｔｅ随机哈希参数，并在服务　端进行判断以防止ＣＳＲＦ攻击，尽量使用ＨＴＴＰＳ保证整个授　权过程的安全性。通过以上防御措施，可以提高整个授权流　程的安全性。　５结束语　由于ＯＡｕｔｈ协议在日常上网过程中时常存在，而且ＯＡｕｔｈ　协议关系到用户的账号、密码等隐私信息，因此它的安全问题　也受到了极大的重视。本文通过介绍ＯＡｕｔｈ１．０和２．０版本巾存　在的安全问题以及相应的防御方式，并且结合部分测试案例让　大家对ＯＡｕｔｈ协议的安全问题有一个直观的了解，并希望更多　的安全研究人员能够关注ＯＡｕｔｈ协议。　（责编马珂）　参考文献：　［１］Ｗｉｋｉｐｅｄｉａ—ＯＡｕｔｈ［Ｚ／ＯＬ］．ｈｔｔｐ：／／ｚｈ　ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／ＯＡｕｔｈ，２０１３　［２］Ｅｒａｎ　Ｈａｍｍｅｒ　Ｅｘｐｌａｉｎｉｎｇ　ｔｈｅ　ＯＡｕｔｈ　Ｓｅｓｓｉｏｎ　Ｆｉｘａｔｉｏｎ　Ａｔｔａｃｋ［Ｚ／ＯＬｌ＿　ｈｔｔｐ：／／ｈｕｅｎｉＶｅ　ｅ．ｃｏｍ／２００９／０４／ｅｘｐｌａｉｎｉｎｇ—ｔｈｅ—ｏａｕｔｈ—ｓｅｓｓｉｏｎ—ｆｉｘａｔｉｏｎ—　ａｔｔａｃｋ／，２００９　［３］Ｅｇｏｒ　Ｈｏｍａｋｏｖ　Ｔｈｅ　Ｓｔｏｒｙ　Ａｂｏｕｔ　Ｔｗｏ　ＯＡｕｔｈ２　Ｖｕｌｎｅｒａｂｉｌｉｔｉｅｓ［Ｚ／ＯＬ］　ｈｔｔｐ：／／ｈｏｍａｋｏｖ　ｂｌｏｇｓｐｏｔ　ｃｏｍ／２０１２／０９／ａ—ｃｏｕｐｌｅ—ｏｆ－ｒｅａｓｏｎｓ—ｗｈｙ—　ｏａｕｔｈ２一ｓｐｅｃ—ｉｓ．ｈｔｍｌ，２０１２．　［４］Ｅｇｏｒ　Ｈｏｍａｋｏｖ　ＯＡｕｔｈ２：Ｏｎｅ　ａｃｃｅｓｓ——ｔｏｋｅｎ　Ｔｏ　Ｒｕｌｅ　Ｔｈｅｍ　ＡｌｌＩＺ／　ＯＬ］．ｈｔｔｐ：／／ｈｏｍａｋｏｖ．ｂｌｏｇｓｐｏｔ．ｃｏｍ／２０１２／Ｏ８／ｏａｕｔｈ２一ｏｎｅ—ａｃｃｅｓｓｔｏｋｅｎ—　ｔｏ—ｍｌｅ—ｔｈｅｍ—ａⅡ－ｈｔｍ１．２０１２．　［５］Ｅｇｏｒ　Ｈｏｍａｋｏｖ　Ｔｈｅ　Ｍｏｓｔ　Ｃｏｍｍｏｎ　ＯＡｕｔｈ２　Ｖｕｌｎｅｒａｂｉｌｉｔｙ［Ｚ／ＯＬ［　ｈｔｔｐ：／／ｈｏｍａｋｏｖ．ｂｌｏｇｓｐｏｔ　ｃｏｍ／２０１　２／０７／ｓａｆｅｒｗｅｂ—ｍｏｓｔ—ｃｏｍｍｏｎ—　ｏａｕｔｈ２．ｈｔｍ１．２（）１　２．　［６］Ｄｎｄｘ．ＯｐｅｎｌＤ和ＯＡｕｔｈ的区别及第三方登录的安全隐患分析　［Ｚ／ＯＬ］ｈｔｔｐｓ：／／ｉｄｎｄｘ．ｃｏｍ／２０１　２／０４／２３／ｏｐｅｎｉｄ—ＶＳ—ｏａｕｔｈ—ａｎｄ—ｔｈｅ—　ｓｅｃｕｒｉｔｙ—ｒｉｓｋ—ｏｆ－ｏａｕｔｈ—ｌｏｇｉｎ／，２０１２