@EricaHe
2016-07-29T02:33:51.000000Z
字数 5109
阅读 624
论文笔记 OpenIDConnect
作者：Wanpeng Li, Chris J Mitchell
单位：Information Security Group, Royal Holloway, University of London, TW20 0EX
来源：DIMVA'16
本篇论文主要讲述了：
虽然OpenID Connect的名称上看起来觉得它和OpenID的关系更加亲近，但实际上OpenID Connect是对OAuth 2.0的升级，它在其基础之上加上了身份管理功能，从而使得本用于授权的OAuth 2.0可以进行认证操作。
OpenID Connect在原OAuth 2.0所有的access_token和code的基础上，增加了第三个参数：id_toekn。id_token包含了一系列的声明，由JSON Web Token格式组成，这些声明包括：
id_token会被OP进行数字签名。access_token和id_token都能够通过OP的API进行验证操作。
Google对于OpenID Connect支持4中验证流程：
文章主要讨论了两种攻击场景：
方法：作者将RPs和IdPs都当做黑盒，然后分析在授权过程中产生的browser relayed messages(BRMs)，来寻找可能存在的漏洞。
在作者测试的103个RP中，有69（67%）个使用了Authorization Code Flow，有33（32%）个使用了Hybrid Server-side Flow，以及1个使用了Client-side Flow。
有6个应用在向Google OP请求access_token和id_token（使用code进行换取）时，提交了Google ID，其中有两个没有带上code参数，有一个带上了access_token参数。
经过验证，发现这三个都仅仅使用了Google ID来验证用户的身份，从而使得攻击者可以通过获取受害者的Google ID来进行攻击。
有13个应用使用access_token作为登录凭据来认证用户，而不是通过id_token，并且没有经过OP的验证。
由于access_token自身并不是用户相关的（需要OP自己额外进行检查），所以使用其作为登录凭据，且不通过OP验证是不安全的；而id_token自身内容就表明了其用户的身份，并且经由OP签名，所以才可以作为用户认证的凭据。
有4个应用在整个流程中因没有使用SSL而暴露了access_token，从而使得一个被动的监听者可以截获access_token，根据OAuth 2.0的说明书，access_token不应该未经加密就在RP和浏览器之间进行传递。
除此之外还有一个站点，TheFreeDictionary，虽然使用了SSL，但由于access_token被存到了cookie中，并通过浏览器发送给了网站，而这个消息是未经SSL保护的，从而使得监听者可以通过观察获得该access_token。
在整个登录过程中，RP从OP获得的用户信息应该除了这个RP以外，再没有其他人知道，这就要求在传递access_token和id_token时使用SSL来保护传递的内容。然而有7个应用未能满足这一要求。
在所有的使用Hybrid Server-side Flow的33个应用中，有24个应用存在这个问题，导致这个问题的主要原因是由于缺乏state参数，或者state参数使用不当，使得其未能起到作用。
在Authorization Code Flow中，access_token本应只在服务器端进行传递，以此来防止攻击者截获access_token，真正在RP和浏览器之间进行传递的只有code，不过由于攻击者无法获知RP的client_secret，所以也无法利用。
但是有4个应用将access_token返回给了用户的浏览器，而不是将用户绑定到当前会话之中，而这4个应用同时都没有使用SSL来保护access_token，从而使得攻击者可以通过窃听得到access_token。
利用谷歌的“automatic authorization granting”特性——即用户在授权过一次之后，不再需要用户再次参与到授权过程中来，谷歌将自动返回access token给RP——攻击者可以利用一些漏洞来实现XSS攻击，从而完成对access token的窃取。
所有使用了Authorization Code Flow的应用都无法抵御这一攻击，不过该攻击的实际利用需要漏洞来实现XSS攻击，作者使用的是Android内置浏览器的一个可全局执行XSS的漏洞，Android4.4以下版本将受到该漏洞影响。
虽然在Authorization Code Flow中，没有用户信息在授权过程里被传递，但是有11个RP在完成授权之后，将用户信息未经保护地直接传回给了浏览器，从而使得网络监听者可以获得这些信息。
这里与之前Hybrid Server-side Flow中的Session Swapping的产生原因都是一样的，都是因为没有带上state参数或者state参数使用不正确，两者的区别在于，前者返回的参数不仅仅只有code，还有access token，而后者只有code，由于code是一次性的，所以需要攻击者不断地更新code才能够完成攻击。另外还有前者多半采用的是POST方式，后者采用的是GET方式，这使得攻击方式也有些微的区别。
这个同样也是借助了谷歌的“automatic authorization granting”特性来实现CSRF攻击，根据作者的实验表明，有24个应用无法抵御此类攻击。
在使用Hybrid Server-side Flow的RP中，有70%的RP没有完全按照谷歌给出的文档来，这些修改可能的确改进了RP的用户体验，但同时也增加了引入漏洞的风险。
比如在未经校验的情况下使用access token作为登录凭据，或者使用Google ID之类的易获取信息作为登录凭据。
state参数是防止CSRF攻击的重要方式，然而从RP客户端抽取的数据来看，Google所送出的state参数是一个null值，而且Google的样例代码中，state这个参数并没有被带上。