[关闭]
@1qaz 2017-05-09T13:36:26.000000Z 字数 2612 阅读 1038

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注册
discovery

IdP Confusion Attack

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

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

Malicious Endpoints Attacks

phase1 和phase3之间的问题. IdP动态注册时,恶意IdP将注册地址,认证地址设为honest IdP的地址,token地址设为自己的地址。
malend
malendflow
其他问题:
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匹配
issuerconfusion

PrOfESSOS

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

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注