An Empirical Analysis of Single Sign on Account Hijacking and Session Management on the Web

出处：USENIX Security’18

简介

这篇文章研究了SSO账号劫持和相关会话管理的情况，区别于以往的研究，本文主要聚焦在IdP账号被劫持对SSO的安全性带来的一系列影响。

同时，作者基于OpenID Connect提出了一种Single Sign-Off扩展方案以降低这类账号劫持的危害。

本文的主要贡献点：

• 首次对SSO生态系统现状进行了大规模分析，调查了Alexa top 1M 的网站使用IdP的情况。
• 对SSO中IdP账号被劫持的后果进行了深入分析，以95个流行的web和mobile RP为样本，分析了IdP账号被劫持对后续授权、RP账号创建等过程的影响。
• 作者的分析发现当前的SSO系统无法阻止攻击者在RP授权被撤销后仍能访问受害人RP账号，针对这种情况他们提出了一种基于OpenID Connect协议的single sign-off扩展；

本文涉及的SSO协议主要是OAuth 2.0和OpenID Connect.

威胁模型

由于本文主要研究IdP账号被劫持产生的影响，这里首先介绍两种IdP认证用户的情况。

• 如果用户没有在当前user agent登录到IdP，那么需要在一个IdP页面输入账号密码以登录，随后IdP会生成一个cookie供后续使用。
• 如果用户在当前的user agent已经登录过IdP了，或者说，之前登录的cookie还有效，那么当用户要在某个RP使用IdP账号登录时，IdP可能就不会再要求用户输入账号密码，而是使用之前的cookie.

因此，这里作者主要考虑了两种威胁模型：

• Phishing：这种途径主要是获取用户账号密码。是一种较为常见的攻击方式。
• Sniff Wifi (Cookie hijacking)：劫持HTTP cookie以劫持用户账号。

网络流量分析

作者以Facebook为例，来阐述cookie劫持的可行性。

作者审计了所有流行Facebook应用(Facebook, Messenger, Instagram) 在iOS, Android, Window mobile的流量，发现浏览iOS上Facebook的应用内浏览器以及访问提供Facebook静态内容的网站时会暴露cookie，因为对域名staticxx.facebook.com上静态内容的请求没有受HSTS保护，同时cookie没有设置Secure标记或该标记没有强制使用。

作者在实验环境中通过重放了捕获cookie中的三个关键值（c_user, datr, xs）成功劫持了一个账号。同时，作者发现，在另外的设备上重用这些cookie并不会产生安全提醒。

作者在2017年1月-5月期间监控了他们所在大学的无线网络的流量，以分析cookie劫持问题的普遍性。

作者最终发现了5,729个不同的有问题的cookie，被使用在对11个不同的Facebook域名的请求中，staticxx.facebook.com是最常见的。在监控期间，这个问题影响了28个版本的iOS Facebook应用，以及14个iOS Messenger应用。

SSO的使用普遍性

作者根据Wikipedia上的一个OAuth provider的列表，形成了一个包含65个支持OAuth 2.0 和/或 OpenID Connect协议的IdP的列表。然后作者开发了一个 工具 来自动化分析Alexa上的网站是否支持这些IdP的SSO服务，这个工具使用了Puppeteer浏览器自动化库。

作者用这个工具分析了 Alexa top 1M 的网站，其中912,206个网站能被成功访问，57,555（6.3%）的网站支持SSO. 其中，Facebook是使用最广泛的IdP，被4.62% (42,232)个网站支持，Google为 2.75% (25,142)，Twitter第三 1.34% (12,294). 作者的分析表明，流行的网站中对SSO的支持率比较高。

另外，作者的分析中发现，有个IdP既是IdP，又是RP，所以就会出现一个IdP被攻破了，会影响它的RP中那些扮演IdP角色的网站，进而影响更多的RP。下图展示了这种级联影响，红色的点表示那些受害者的Facebook账号被攻破不会直接影响但会间接影响的RP.

RP账号接管

这个攻击的前提条件是，用户使用IdP账号在RP创建了一个账号，之后的某个时间点攻击者劫持了用户的IdP账户，进一步劫持该用户的RP账户。

分析方法

作者人工分析了Alexa top 500网站中的29个网站以及66个流行的iOS应用，它们都支持Facebook SSO. 这些RP的选择是来自不同的类别或功能，作者也选择了一些Android 应用进行了分析。

作者给每个网站和移动应用都使用SSO创建了一个新的账号，同时添加了必要的信息。创建账号后，作者按照正常用户行为进行了一些操作，比如发信息，购物等，然后登出。

然后作者使用劫持的cookie登录用户的IdP，然后查看这样的攻击者在RP的访问级别是什么样的（比如查看用户信息、订单记录、发信息等）。

大部分情况下，这类劫持cookie攻击者的访问级别和被攻击用户是一样的，这也很合理，有3个案例攻击者在访问某些服务的时候需要重新进行IdP身份验证。其中（1）Hookup应用，它每次都要求IdP账号重新认证，但是作者发现不选择登录接口而是注册接口可以绕过账号认证；（2）Guardian应用，只能获得部分权限，进行“设置”操作的时候需要重新输入用户的Facebook密码。作者发现创建RP账号的密码不需要重新IdP认证，因此可以创建RP密码，然后再登录获得全部的访问权限；（3）Kayak应用，支付信息、邮件设置、增加新旅客信息需要用Facebook的密码重新认证；

攻击可见性

作者进一步分析了这类攻击是否会留下“足迹”导致攻击被发现。

作者发现这95个RP没有一个通知用户关于其它设备登录或活跃会话的情况。仅10个RP提供选项可以查看当前用户账户的活跃会话，但一般用户不会设置这些选项。在作者的劫持cookie的实验中，也没有发现Facebook会给用户发送警告，攻击者的会话除非超过一个小时否则不会出现在登录list上，这样受害者将没有办法知道自己别攻击了。

持久性访问

攻击者可能会失去对受害者IdP账户的控制，当受害者修改IdP密码后，有9个RP会阻止攻击者访问它们的账户，其中2个每次会话都要求重新进行SSO认证，7个会将用户登录。

密码重置

作者设计了一种新的攻击方式可以让攻击者能持久访问受害者的RP账户，其核心思想是攻击者登录到受害者的RP账户，把关联到RP账户的邮箱设置成自己的，然后进行RP账户密码重置。这样攻击者可以通过邮箱密码登录受害者的RP账户，而受害者还可以正常用SSO登录RP.

作者用这种攻击测试了29个web RP，15个允许攻击者不输入密码的情况下更改email，其中6个更改密码时不需要输入旧密码，剩下9个则发送一个链接到邮箱以重置密码。29个RP中共有22个可以让攻击者在U币知道密码的情况下实现对受害者RP账户的持久性访问。

账号链接

作者提出的另一种攻击方式也能实现持久性访问。其核心思想是攻击者用受害者的IdP账号登录RP后，取消RP账号与IdP账号的关联，然后使用自己的账号登录IdP，将自己的IdP账号与受害者的RP账号关联。然后攻击者再用受害者的账号登录受害者RP，这样就相当于受害者的RP关联到了两个不同的IdP账号。

这种攻击主要是由于RP实现有逻辑错误，任何时候一个RP账户都不能关联到同一个IdP的两个账户。

作者分析发现5个web RP（Pinterest, booking.com, Quora, 9gag, 4shared）受这种攻击影响。

IMDB在被攻击时，会导致攻击者的IdP账号连接到受害者的RP账号，而用受害者的IdP账号登录RP时，会重新建立一个新的账号，这种情况就会把受害者以前的账号挤掉，也是一种攻击类型。

IdP access escalation

作者还发现一种巧妙的攻击方式，可以扩大攻击者在IdP的访问权限。

攻击者通过劫持cookie登录受害者的IdP账号后，可以给受害者账户增加一个新的手机号码，而不需要重新输入密码，然后攻击者利用这个手机号来重置受害者的IdP密码，这样攻击者就能利用账号密码登录受害者的IdP账号了，攻击者还可以移除受害者的邮箱手机号等，避免IdP给用户发送密码被更改的提醒。

Preemptive Account Hijacking

这部分作者说他们提出了一种新的攻击，即受害者还没有用IdP创建一个RP账户，攻击者提前创建了，并填充了一些信息等，然后受害者在后面的某个时间点使用IdP在相应的RP创建账户时，会受到一些危害。

但总的来说这部分内容并不新颖，这种攻击行为在之前SSO协议相关的研究论文中也有提及，对这部分感兴趣的可以看论文的详细描述。

账号被劫持后的补救方案

这部分主要探讨用户在受攻击后，在IdP端或者RP端是否有办法能够阻止攻击者在未来继续访问它们的账户。

在目前的SSO协议中，并没有这样的机制进行补救。理论上SSO协议中，认证一个用户分两层，第一层用户在IdP进行身份认证，第二层RP根据IdP的断言在RP认证用户。在第二层中，RP会生成一个持久性的cookie保存在浏览器中，然后依赖这个cookie值认证用户身份。

所以当攻击者成功攻击后得到了RP的这个cookie，那么只要这个cookie不过期，他就能访问受害者的RP账户。作者的分析中发现，大部分的RP都不支持吊销攻击者的访问权限。同时，即便每个RP支持这样的吊销，IdP账户被攻破也会要求受害者在每个关联的RP都进行这样的操作，非常繁琐不方便。

作者尝试了几种方法查看是否能补救：（1）从IdP登出；（2）从RP登出；（3）修改IdP账户的密码；（4）增加或修改RP账户密码；（5）吊销RP对IdP账户的访问权限；（6）使RP账号的活跃会话失效。然而，分析发现95个RP中，仅10个RP提供某种形式的会话管理，有71个RP没有任何措施可以阻止攻击者对受害人RP账户的访问。

Single Sign-Off

由于当前的SSO方案普遍不能让IdP撤销所有RP账户对它的访问，作者提供了一个解决方案。

这种方案是基于OpenID Connect协议，对它进行了一些扩展。其核心思想是IdP维护一个已授权RP的列表，当用户发现自己被攻击时，首先在IdP端发起single sign-off，IdP要求用户修改密码并进行通过双因子认证（短信等方式）来确认用户身份。用户身份确认成功后，IdP使该IdP账号在所有设备上的会话失效，同时吊销所有关联RP的访问权限；同时，IdP会向列表中的RP发送认证撤销请求，RP收到一个合法的认证撤销请求后，会将该用户账号的所有活跃会话都失效，同时使相关的access token失效。进而实现阻止攻击者对受害者账户的访问。

这个方案的实现方式就是在当前的OpenID Connect方案里增加认证撤销的流程，对协议的改动很小，实现并不复杂，详细参考原文。

总结

SSO中的账号劫持本不是一个新鲜的话题，同时，在之前针对OAuth及Google等企业部署的OpenID Connect协议的研究中，研究者们一般较少考虑IdP账户被攻破的情况，因为IdP一般是比较大的互联网公司，账户安全防护方案比较成熟，同时大量部署HTTPS，较少出现用户的IdP账户被大规模攻破的情况。本文的作者就很聪明，一开始就强调本文关注的是IdP账户被攻破对SSO过程产生的威胁，以区别于以往相关的研究。同时，用一个实际的案例：Facebook的cookie可被劫持以劫持用户的Facebook账号，来证明作者发现的问题的普遍性和严重性。由此展开的后续的攻击主要是一些典型的逻辑漏洞，在这个场景下也很有趣，作者考虑地非常细致，也有一些有意思的新发现，比如一些知名的RP如Quora等支持一个RP账号关联同一个IdP的两个不同账户的情况等。

此外，作者针对发现的问题，提出了切实可行也非常有效的补救方案，区别于以前相关研究的加固防护或修复方案要么太偏理论化现有技术不支持无法应用，要么成本代价太高不实用，本文的方案兼容OpenID Connect，新增的改动很小，实用性高。

总的来说，这是一个很好的工作，值得企业开发人员和安全研究人员细读。