Your Software at my Service:Security Analysis of SaaS Single Sign-On Solutions in the Cloud

论文笔记 SSO

作者：Christian Mainka，Vladislav Mladenov，Florian Feldmann，Julian Krautwald，Jörg Schwenk

单位：Horst Görtz Institute for IT-Security, Bochum, Germany

Abstract & Introduction

定义：
SaaS（Software-as-a-Service）指一些抛弃本地部署方式，改为在云端提供服务的软件，可以通过互联网进行访问。

本文主要讨论的主题：
由于SaaS让数据存储到了云平台上，那如何建立安全的访问控制机制就成为了重要的议题。文章主要针对其中SaaS上的SSO认证框架——SAML（Security Assertion Markup Language）部署的安全性进行讨论。

SaaS Provider Model

SAML认证流程：

SaaS认证流程：

首次验证（尚未获得Session ID）：

1. 用户名/密码
2. SSO
   
   • 将用户重定向到IdP：SSO模块从数据库中获得其合作的IdP，然后生成一个token request并转向IdP，
   • 认证获得的令牌：从User Database获得IdP的证书，从得到的token中获得用户信息，然后将其发给AAM去获得用户对应的权限，并由给用户颁发Session Cookie

再次验证：

由Session Management来从Session Cookie中获得用户信息，然后发给AAM

SSO认证令牌

无论采用何种SSO机制，在SAML Assertion的过程中，一个SSO认证token中总有一些内容是固定的：

1. Identity：代表了一个用户
2. Freshness：随机数或时间戳，限制token的使用
3. Destination：使token只能被一个特定的SaaS-CP（SaaS-Cloud Platform）使用
4. Signature或HMAC：用于保护token信息，至于哪些信息需要保护则由IdP决定。IdP使用它自己的私钥来生成签名，而其对应的公钥则在一张证书里，这张证书被存储于SP中。但需要注意的是，这里的证书和PKI没有关系，它只是一个公钥再加上一些元信息。

总而言之，token=(Identity, Freshness, Destination)。

攻击模型

1. 攻击者可以根据SaaS-CP的格式生成合法的消息，但是不知道任何秘密信息，也无法产生签名——除非攻击者拥有自己的私钥公钥。
2. 攻击者在SaaS-CP上拥有一个合法的token，以及这个token对应的签名。这个token可以通过XSS或搜索引擎搜索得到，但不包括通过中间人攻击或者窃听得到的token。（攻击者自己也是合法用户也包含在内）
3. 攻击者能够说服受害者点击由攻击者发给他的一个链接。或者还能进一步假设，在单击链接的时候，受害者已经在这个SaaS-CP上登录过了。

相关攻击

攻击模型1

Signature Exclusion：
token未要求对其进行签名，从而攻击者可以篡改其中的信息。

Certificate Faking：

由于SAML使用的是XML Signature standard，所以证书可以被加入到token中去，所以攻击者可以使用自己的密钥对token进行签名，然后将相对应的密钥对做成证书加进去，一起发给SP。
如果SP没有在验证之前，首先验证证书是否可信，则可能造成问题。

XML External Entity Attack：
攻击者可以将一个包含有DTD(Document Type Definition)的XML消息发送给应用（这个甚至不一定要是SAML token），有些有问题的应用就会去解析DTD，并执行其中的定义，此时攻击者就可以使用XML外部实体攻击获得其中的文件内容。

但是这种情况并不常见。

XSLT Attack：
XSLT（Extensible Stylesheet Language Transformation）可以将XML文件转换为其他格式的文件，且这个转换将在数字签名验证前执行。
这个的利用方式和上一种差不多，只不过这里要求发送的一定得是一个SAML token，虽然签名是否正确并不需要在意。

攻击模型2

Replay Attack：
SP未对Freshness作校验，从而使得只要一个合法的token，无论在何时都能够登录SP。

XML Signature Wrapping：

当SSO认证和处理部分对一个token的解读不同时，攻击者就可以通过注入恶意数据来达成攻击。

在此例中，SSO Verificator利用Reference来找到相应的ID进行签名校验，而SSO Processor则自动处理它所获得的第一个token内容，从而使该token绕过了检测。

Token Recipient Confusion：

SP未能对Recipient参数进行适当的校验，使得一个在S_A能够获得合法t_A令牌的攻击者，可以将该令牌转发给S_target，从而获得进入的权限。

不过这个方式要求S_A和S_target使用相同的IdP。

另外，作者还可以自己搭建一个SaaS-CP（S_bad），来获取在其上注册用户的发给他的token。

攻击模型3

Certificate Injection

在测试的所有SaaS-CP中都开放有网络接口，其中一个能够导入证书。于是攻击者就可以通过构造CSRF攻击，向AAM模块导入恶意的证书，即攻击者拥有这张证书所对应的私钥，从而可以为任何token签名。CSRF攻击要求攻击者能够说服受害者去点击他所构造的链接。

结果

总结

• 大部分的SaaS-CP都很好地理解了签名机制，并正确部署
• 很多应用并没能够提供对于Freshness和Destination的有效验证，这有可能是因为请求中含有大量的冗余信息，开发者可能对于该如何选择需要验证的参数存在一定的困惑；还有些虽然进行了验证，但是并没有使用签名去保护，从而导致该参数可被修改。
• 有50%的测试应用都未能抵御XML Signature Wrapping，尽管在2012年已有许多研究提出了这一问题。
• 对于XML External Entity和XSLT Attack来说，许多实现并没有部署自己的XML parser和XML Transformation，而是使用了现成的免费库，而如果这些库启用了External Entities或XSLT，这两种攻击就有可能实现。由于这两个功能都很少被使用，所以应该默认关闭，如果真的要用，也要有选择性地使用。
• 在实现时，要从整体上去考虑整个系统的安全性，而不是单个模块地进行考虑，有些攻击可以利用几个模块一起来实现。