Protecting Web-Based Single Sign-on Protocols against Relying Party Impersonation Attacks through a Dedicated Bi-directional Authenticated Secure Channel

论文笔记 SSO

作者：Yinzhi Cao, Yan Shoshitaishvili, Kevin Borgolte,Christopher Kruegel, Giovanni Vigna, and Yan Chen

单位：Northwestern University,University of California, Santa Barbara

Abstract & Introduction

本文做了以下工作：

1. 在现有的各类SSO协议中，对伪装RP攻击做了系统性的弱点分析
2. 设计了一个可以克服该类弱点的通信信道（a dedicated, authenticated, bi-directional, secure channel），并在这之上实现了一个OAuth-like和一个OpenID-like的协议
3. 证明了这一channel可认证的特性（用了ProVerif）
4. 评估了该协议的一个实现原型的可行性
5. 建立了一个代理，作为一个第四方，从而实现从原有SSO协议到本文所设计的协议的过渡

Threat Model

文章仅仅考虑攻击者能够通过伪装成RP来获取用户个人信息的情况，主要关注RP和IdP之间的交互过程。

将要讨论的五种的攻击大致可以分为两类：

• 由一个恶意RP所发起的攻击
• 一个好的RP发起请求，但接收到回应的是一个恶意RP

所有非协议层面上的漏洞均不在本文的讨论范围内，如社工、被篡改的或有问题的RP、浏览器的漏洞、实现错误、隐私泄露。

Revisiting Existing SSO Designs and Attacks

身份

• IdP：web origin(scheme, host, port)
• User: a unique identifier(username, email...)，此处假设每个用户都有一个正确且唯一的identifier
• RP: a unique identifier(app id, app name...)，此处假设这一identifier无法被伪造

RP与IdP之间的通信

• HTTP(s) Requests to a Third-Party Server:
  
  • 用户的浏览器-->RP（请求）
  • 用户的浏览器<--RP（重定向至IdP）
  • 用户的浏览器-->IdP（请求）
  • 用户的浏览器<--IdP（身份信息）
  • 存在的问题： RP需要告诉IdP该如何引导用户的浏览器去完成认证（即在IdP确认用户身份后，该如何重定向到RP），这通常是通过添加参数来完成的，然而这一参数是可修改的，从而攻击者就可以进行身份伪造攻击
• In-browser Communication Channel
  
  • 通过JS代码在RP和IdP之间建立通信，比如Facebook Connect（允许用户从外部网站访问Facebook数据）
  • 存在的问题：
    
    1. RP和IdP通信时，其来源必须独立地进行认证，而很多网站并没有实现这一点，包括还有不正确地使用PostMessage时存在的一些漏洞
    2. Flash对象将会在这种通信信道中引入不安全因素，使得攻击者可以窃听RP和IdP之间的交流，而就算开发者由Flash对象转向postMessage，也存在有类似的问题

设计

文章提供了2个解决方案：

• 一个全新的、安全的协议设计（作为一种新的SSO协议部署于IdP上）
• 一个可兼容现有协议的代理（部署于RP上）

IdP Deployment - A clean-slate Design

Identity Design：

使用web origin来作为RP的身份标识

• 如果RP有自己的web origin，则使用RP自己的（如facebookconnect.nytimes.com）
• 如果RP没有web origin，则由IdP提供(如app1.connect.facebook.com)

Communication Channel：

• 建立信道：握手协议
  
  • RP认证IdP的身份，并向IdP发送他的公钥（PK_RP）
  • 收到RP公钥后，IdP认证RP身份
  • IdP生成一个session key(SK)，使用RP的公钥对其加密，除此之外，IdP再分配一个partial channel number给这个会话，也用RP公钥对其加密(PK_RP(N_IdP))
  • RP使用自己的私钥对SK和N_IdP解密，然后回复一个用SK加密的partial channel number（SK(N_RP)），随后将N_IdP和N_RP都存在浏览器中
  • 另外还有一个ControlByte将会被添加到信息中
  • N_RP和N_IdP共同用来检索session key，ControlByte表明了当前会话的状态（会话是否已被销毁）
• 使用信道：发送消息
  
  • 
    信息格式为M=(N_RP, N_IdP, SK(ControlByte, msg_chunk1), SK(msg_chunk2)...)
• 使用信道：接收消息
  
  • 
• 销毁信道：释放资源
  
  • 无论是RP还是IdP想要停止通信，都需要向对方发送一个带有ControlByte=0的消息，例如RP想要停止对话，它首先发送一个ControlByte=0的消息个IdP，收到这个消息的IdP就知道RP希望通信结束，于是它回复一个ControlByte=0给RP，然后释放资源；RP接到IdP的消息后，也会释放资源，结束通信——这个过程类似于TCP中的结束握手。

SSO Protocol over the Channel：

• OAuth-like Protocol：RP依靠access token去向IdP获得用户信息
• OpenID-like Protocol：RP请求IdP认证用户

RP Deployment - Proxy Design

Communication with the Legacy IdP:

1. 注册：Proxy对于IdP来说，应该是在其上注册过的一个应用，每个用户都单独地将其进行注册，从而使得所有用户Proxy的Application ID都各不相同
2. 运行：Proxy就像一个正常RP一样去向IdP请求access token（在OAuth-like protocol中）或者获得能够证明用户身份的证据（在OpenID-like的protocol中），这里Proxy需要所有RP所需凭据的并集，以在之后面对和真正RP的交互。
3. 通信安全：由于此处Proxy和IdP的交互使用的不是文章所提出的安全信道，所以这里的通信应该在一个安全的环境下进行，如浏览器的隐私模式，并且没有任何其他的网站打开着。

Communication with the Legacy RP：

对于RP来说，Proxy就是一个IdP，在OAuth-like的协议下，它需要自己颁发token，并管理token和相对应的权限的关系；而在OpenID-like的协议下，它只需要直接转发即可。

Fetching User's Information：

在OAuth-like的协议下，Proxy使用IdP给予它的token来换取用户数据，然后将用户数据转发给RP。

实现

实现上的一些顾虑：

1. 原先IdP颁发给Proxy的Application ID的机密性：
   
   • 每个用户的Proxy都拥有不同的Application ID，所以攻击者不能通过自己注册一个来获得其他用户的Application ID
   • 一些IdP提供“沙盒模式”（如Facebook），这个模式只有开发者可以进行访问，而在这里，开发者即每个用户自己，从而保证了Application ID的机密性
2. IdP的服务条款
3. IdP的Access Token过期：需要重新获取

评估

整个协议及通信基本上没有安全上的问题——这一点由ProfVerify进行了证实——唯一可能存在问题的是，一个恶意的RP可以获取到Proxy和IdP的通信，所以在Proxy和IdP通信时，必须要在隐私模式，并且没有其他窗口打开的情况下进行。

安全分析

• Facebook和NYTimes
  
  • 问题：通过篡改app_id，一个攻击者可以仿冒NYTimes向Facebook索取其本应颁发给NYTimes的access token，并且由于flash的一些特性，恶意RP可以获取到这一返回信息
  • 解决：
    
    1. 使用web origin去验证RP的身份，所以一个恶意的RP无法仿冒其他RP
    2. Facebook和NYTimes之间的通信是安全的，一个恶意RP即便获取到了两者间的消息，也无法轻易的解密
• JanRain Wrapping GoogleID
  
  • 用户只需进行一次安装JanRain，就可以直接使用现有社交网络或电子邮件账号登陆想要访问的网站。
  • 问题：一个恶意的RP向JanRain登记自己，当这个RP开始通信时，一旦JanRain将通信重定向至Google，这个恶意的RP就会冒充另一个受害RP，并篡改其返回URL为自己的URL。由于Google使用的是HTTP重定向，所以用户信息将就此泄露给恶意RP。
  • 解决：本文所设计的通信方式是一种双向的通信，即一个RP发消息个IdP，IdP将直接回复，而不是通过重定向等手段。
• Facebook and Zoho
  
  • 与上一条基本相同
• JanRain Wrapping Facebook
  
  • 问题：RP错误地设置了其白名单，如sears.com本应将rp.sears.com列为白名单，却错误地设置成了*.sears.com
  • 解决：使用web origin
• Facebook Legacy Canvas Auth
  
  • 问题：在RP app上，IdP的签名未能得到合适的验证，从而使得攻击者可以仿冒IdP
  • 解决：由于这里在一个经过验证的传输信道上传递消息，所以认证IdP的签名是不必要的

性能分析