SoK: Single Sign-On Security – An Evaluation of OpenID Connect

未分类

Christian Mainka,Vladislav Mladenov , Ruhr University Bochum,EuroSP 17

概述：这篇文章总结归类了SSO协议中的攻击，并对OpenID Connect的协议和实现安全性进行了分析，提出了Identity Provder Confusion 和 Malicous Endpoints Attack两种新型攻击,实现了名叫PrOfESSOS的SSO评估工具来对OpenID Connect的实现库进行测试

Introduction

Single Sign-On:用户在访问Service Provider时使用第三方Identity Provider登陆。

具体SSO协议有SAML，BrowserID，OAuth,OpenID，OpenID Connect等，OpenID Connect基于OAuth2.0，在2014年被标准化，是最新的SSO协议

以OpenID Connect为例，SSO认证的token的由4个部分组成
1. Identity：issuer，subject
2. Recipient： audience
3. freshness：timestamp，expired，nonce
4. signature

攻击可以归为两类：
Single-Phase attack：针对某个缺少安全检查的特定步骤进行攻击
Cross-Phase attack：操纵整个协议的工作流，作者提出了3种新攻击，实现错误导致的Issuer Confusion，规范错误导致的IdP Confusion和Malicious Endpoints

回答3个问题：
1. 哪些已知的攻击被OpenID Connect在规范中解决？
2. 官方推荐的实现是否遵循了规范，避免了已知的攻击？
3. SSO库的安全性如何被改善？ PrOfESSOS

Background and known attacks

SSO的三个步骤：
Phase 1: Trust Establishment IdP在SP注册，建立信任。这一步可以是管理员事先配置的，也可以是动态注册的.OpenID就是一个类似username.IdP.com的URL (client_id,client_secret,redirect_uri)
Phase 2: Token Generation User在SP被转到IdP，IdP认证后生token，重定向回SP
Phase 3: Token Redmption: SP用token认证User (id_token,access_token)

威胁模型：
类型A：需要victim交互，如点击链接
类型B：不用victim交互，比类型A的攻击更强

作者使用了恶意的IdP来分析SSO安全性，OAuth和OpenID Connect都支持IdP动态注册，协议本身需要提供机制来防范恶意IdP.

分析方法的比较：
手工测试：灵活，不能大规模
形式化分析：只能发现协议规范的问题，不能发现实现问题
静态代码分析：需要代码库，特定语言
动态代码分析：无法分析IdP和SP的直接通讯
Message invariants: ？

Single-Phase Attacks

Class I: ID Spoofing

攻击者用自己控制的IdP向SP发起登陆，攻击者的IdP生成了一个由其他合法IdP维护的用户的token，但是用自己的key签名。如果SP接受了这个token，攻击者就可以以任何用户身份登入。
在OpenID Connect的id_token中，两个参数组成了身份的认证 sub 用户在IdP的ID，iss token签发者，通常是IdP的URL，SP需要验证token签名的密钥属于iss字段的IdP
属于B类模型

Class II:Wrong Recipient

由于一个IdP可能在很多SP注册，恶意的SP收到token后，去其他SP上认证。一个token只能被一个SP使用，SP需要验证token的Recipient确实是自己。 在OpenID Connect id_token中,SP需要验证aud字段是自己的client_id
属于A类模型

Class III: Replay

这个场景是前员工无限期访问SP。 OpenID Connect中的字段有 iat(issue at),exp(expired),nonce
属于A类模型

Class IV: Signature Bypass

签名认证了token的同时，也保证了token没有被修改过。如果签名验证可以bypass，之前的攻击通过修改相应字段都是可行的
属于B类模型

OpenID Connect中token使用了JSON Web Token.JWT头部alg字段表明了Token的签名算法，如果是none的话签名验证就被绕过了.OpenID Connect规范中不允许使用none，但仍有一些实现缺少了这个检查

Cross-Phase Attacks

OpenID Connect的Discovery phase实现了动态IdP注册

IdP Confusion Attack

phase2 和 phase3 之间的问题。phase2的最后， SP从user拿到code，但是并不能确定这个code是哪个IdP的。
条件： SP允许自定义的IdP，SP在attack IdP和 honest IdP里是同一个client_id

用户点击恶意链接，SP重定向到attacker IdP，attacker IdP把用户重定向到honest IdP。 SP认为自己在和attacker IdP通信，用户认为自己在honest IdP认证的

Malicious Endpoints Attacks

phase1 和phase3之间的问题. IdP动态注册时，恶意IdP将注册地址，认证地址设为honest IdP的地址，token地址设为自己的地址。


其他问题：
Server Side Request Forgery：SP向IdP注册时，需要发起一个请求，恶意IdP构造URL探测SP内网
Denial of Service：恶意IdP让SP去get 超大的文件

解决方法：修改OpenID Connect规范，Phase2 SP除了code还要得到issuer

Issuer Confusion

属于实现错误。 id_token中的issuer要和IdP匹配

PrOfESSOS

Web接口，测试SP安全性，使用selenium自动登陆