应用安全四十二：SSO安全

jimmyleeee

已于 2024-04-24 10:51:34 修改

阅读量893

点赞数

文章标签：安全 SSO

于 2023-11-05 21:54:42 首次发布

本文链接：https://blog.csdn.net/jimmyleeee/article/details/134235488

版权

一、什么是SSO

SSO是单点登录（Single Sign On）的缩写，是指在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。这种方式减少了由登录产生的时间消耗，辅助了用户管理，是比较流行的企业业务整合的解决方案之一。

身份验证过程依赖于双方之间的信任关系——身份提供者(IDP)和服务提供者(SP是最终用户想要访问的应用程序)。在最常见的身份验证流下，当用户希望访问服务提供者时，将使用SAML请求消息将其重定向到身份提供者(IDP)。如果用户尚未登录，身份提供者将对其进行身份验证，如果验证成功，它将使用SAML响应消息(通常在POST请求的正文中)将用户重定向回服务提供者。SAML响应消息将包含一个标识用户并描述一些条件的断言(响应的过期时间和访问的范围，该限制声明断言对哪个服务有效)。服务提供者应该验证响应、断言和条件，并且只有在身份验证成功时才向用户提供对应用程序的访问权限。

二、SSO带来的好处

当用户第一次访问应用系统的时候，因为还没有登录，会被引导到IDP认证系统中进行登录；根据用户提供的登录信息，IDP认证系统进行身份校验，如果通过校验，应该返回给用户一个认证的凭据——ticket；用户再访问别的应用的时候就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行校验，检查ticket的合法性。

启用SSO之前：

启用SSO之后：

现在的大部分公司内部用用系统很多，有项目管理系统、bug管理系统、知识管理系统、邮件管理系统、远程机器访问管理等等。如果每访问一次系统都要输入一次密码，确实很麻烦。由于SSO只需要登录一次，就可以访问很多应用，给内部办公带来很多便利，大大提高效率的同时，也给IT管理人员减少了很多工作量。

SSO主要的优点如下：

方便用户：用户只需一次登录，就可以访问所有相互信任的应用系统，无需每次输入用户名和密码，也不需要记住多套用户名和密码。用户更愿意使用复杂的密码策略，促进了安全密码策略的实施。这提高了用户体验，特别是对于需要访问多个系统的用户来说。
方便管理员：管理员只需要管理一套统一的用户账号，方便、简单。相比之下，管理员以前需要管理很多套的用户账号，这不仅给管理上带来不方便，而且容易出现管理漏洞。特别是员工离职时，需要针对多套系统禁用离职员工相关的账号，经常导致会有所遗漏。之前公司就有个同事离职之后，因为账号管理的失误，依然可以使用一个对外的在线网站系统，后来公司强制使用SSO之后，也就自然而然堵上了这个漏洞。管理员可以通过单点登录平台集中管理所有用户的账号和密码信息，方便快捷地进行用户管理。
简化应用系统开发：开发新的应用系统时，可以直接使用单点登录平台的用户认证服务，简化开发流程。单点登录平台通过提供统一的认证平台，实现单点登录。因此，应用系统不需要开发用户认证程序。
提高安全性：通过单点登录，可以减少每个应用系统所需的认证机制数量，从而减少安全漏洞。同时，单点登录的集中式管理可以减少用户账号和密码被泄露的风险。
提高效率：单点登录可以减少用户在多个应用系统之间切换所需的时间和精力，提高工作效率。
增强用户体验：用户只需进行一次登录操作即可访问所有应用系统，避免了重复输入用户名和密码的操作，提高了用户体验。
提高安全性：通过单点登录的集中式管理，可以减少每个应用系统所需的认证机制数量，从而减少安全漏洞。同时，由于单点登录的集中式管理可以减少用户账号和密码被泄露的风险。
增强应用系统的可扩展性和灵活性：新的应用的接入，只要支持已有的SSO机制就可以相对容易接入公司内部并且推广。单点登录平台可以作为应用系统之间信任链路的桥梁，使得不同的应用系统之间可以进行互操作性和集成性更好的协作，提高应用系统的可扩展性和灵活性。
保护敏感信息：SSO使各个应用可以集中在各自业务的逻辑上，而不需要在考虑认证的问题，减少了每个应用系统所需的认证机制，从而减少了安全漏洞。这有助于保护敏感信息的安全性。

三、SSO的缺点

SSO虽然带来很多遍历之处，但也不能说它是完美的，在使用的过程中也要注意可能带来的问题，提前做预防，以防万一。SSO的缺点主要表现在以下几个方面：

单点故障：如果SSO系统出现故障，所有依赖于该系统的应用程序或系统都将无法使用，会导致业务中断，甚至是整个公司的正常运营。有些机构使用外部的供应商提供的服务，如果服务供应商出现问题，也会影响SSO的正常使用。
单点突破：如果SSO的账号被攻击者破解，他就可以通过这一个账号，访问所有的应用，因此需要较强的密码策略，才可以降低账号被破解的可能。
安全风险：SSO自身的一些安全问题也会给整个系统带来系统性风险，需要在实施过程中增加安全保护措施。如果SSO系统自身被攻击或被黑客入侵，所有依赖于该系统的应用程序或系统都将面临安全风险。
实施成本高：SSO系统需要进行复杂的配置和集成，需要投入大量的时间和资源，实施成本较高。现有的商业解决方案不但比较昂贵，而且在实施时需要与内部所有系统集成，需要花费一定的人力和物力。切换SSO的解决方案更是风险很大，费用很高。SSO实现是痛苦的。这可能需要比预期更长的时间。由于每个IT环境都是独特的，并且由于定制需求，因此可能会出现额外的步骤与时间。此外，公司内部需要有团队进行长期监控和维护。
共享风险：SSO对于多用户计算机是有风险的。当一个用户登录且使用完毕之后，没有退出，或者系统的退出功能有问题，虽然退出了，登录凭证依然有效。另一个用户需要使用该机器时，可能会获得之前登陆用户的会话或者。如果您的SSO提供程序与第三方共享数据，则可能导致丢失内部公司信息。这可能会进一步损害公司的隐私。因此，在使用某个产品之前，详细了解隐私问题非常重要，这样才能选择正确的提供商。

四、SSO的标准SAML

简介

实现SSO的方法和标准有很多种，最流行的一种是通过一种基于XML的开放标准，称为安全断言标记语言(SAML)，它是由OASIS（he Organization for the Advancement of

Structured Information Standards）的SSTC（ the Security Services Technical

Committee）研发出来的标准，是一个适用于在线业务伙伴之间交换安全信息的架构，标准的详细信息，可以参考：https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf。目前查到的最新的版本是2008年的V2.0版本，标准里的有些描述已经明显不适合最新的安全态势了。例如：

根据目前的建议其实SSL系列的协议都不建议使用了，而且TLS也建议使用最新的TLS1.2版本。不过，记住一点：尽量使用版本高的安全协议和安全标准就可以了。根据https://wiki.oasis-open.org/security/FrontPage，可以知道V2.1版本本来已经计划了，但是，后来又取消了。

要了解SAML的工作原理和安全相关内容，必须先了解其消息的结构。SAML的结构如下图：

SAML assertions：携带关于主体的声明，声明方声称该声明为真。断言的有效结构和内容由SAML断言XML模式定义。断言通常是由断言方根据依赖方的某种请求创建的，尽管在某些情况下，断言可以以未经请求的方式传递给依赖方。assertions包含一个元素是SubjectConfirmation，SubjectConfirmation可以包含多个元素证明主体。

SAML protocol：协议消息用于发出SAML定义的请求并返回适当的响应。这些消息的结构和内容由SAML定义的协议XML模式定义。例如：Authentication Request Protocol就是Web浏览器需要一个它需要获得一个assertion以便在SP上为用户建立安全上下文时，用于Web浏览器将一个用户从SP重定向到IDP。

SAML bindings：使用低级通信或消息传递协议(如HTTP或SOAP)在参与者之间传输SAML协议消息的方法。例如：HTTP Redirect Binding定义了如何使用HTTP重定向消息(302状态码响应)传输SAML协议消息；HTTP POST Binding定义了如何使用HTML表单控件的base64编码内容传输SAML协议消息。

SAML profiles：SAML profile定义了如何组合和约束SAML断言、协议和绑定，以便在特定的使用场景中提供更好的互操作性。Profile这个词没有找到合适的中文，它是为了满足特定的业务用例，例如Web Browser SSO Profile，定义SAML实体如何使用身份验证请求协议

和SAML响应消息和断言，以实现标准web浏览器的单点登录。它定义了如何将消息与HTTP Redirect、HTTP POST和HTTP Artifact绑定结合使用。还有一些属性Profile(Attribute profile)，它们不引用任何协议消息和绑定，它们定义了如何使用断言以与许多常见使用环境(例如X.500/LDAP目录、DCE)保持一致的方式交换属性信息。

安全断言标记语言(SAML)是用于交换授权和身份验证信息的开放标准。最常见的SAML的实现方式是在浏览器里通过重定向来绑定配置信息。

SAML规范是灵活的，并且有许多选项来涵盖一系列可能的情况。没有两个供应商以相同的方式实现规范。换句话说，关于它的实现各个厂商并不一样，而且SAML有几种“风格”。因此，它可能有机会会带来安全问题。需要明确的是，这并不是说规范设计得不好。相反，当设计协议时，设计师希望涵盖很多可能性。但是，任何SSO集成仍然需要准备好支持某些特殊情况，这就是漏洞暴露的地方。

当涉及到SSO时，有许多小细节需要考虑。虽然规范是标准化的，但具体的实现可不是统一标准的。可以实现某些东西并使其工作，不同的实现也可能带来不同的问题。实现的一个很小的改动可能导致用户登录失败，而且在查找原因时，需要花费很大的力气和时间才能找到具体的原因。

当使用SAML进行身份验证时，是在对用户进行身份验证，但是在验证之后，就无法检查当前的活动会话的状态。在进行身份验证时，可以知道在某个时间点有当前会话，但是会话持续多长时间?如果时间太短——比如24小时——就会很麻烦，要求每个用户每天都登录一次。这就给会话管理带来了挑战性，也给用户的使用带来不便。

1）隐私

在信息技术环境中，隐私通常指的是用户控制其身份数据共享和使用方式的能力，以及阻止其在多个服务提供商处的行为不适当关联的机制。

SAML有许多支持隐私部署的机制：

提供假名机制：SAML支持在身份提供者和服务提供者之间建立假名。这样的假名本身不会使服务提供者之间存在不适当的相关性(如果身份提供者向每个服务提供者断言用户的相同标识符，即所谓的全局标识符，则可能出现这种情况)。
一次性标识符：此类标识符确保每次某个用户通过身份提供者的单点登录操作访问给定的服务提供者时，该服务提供者将无法将其识别为以前可能访问过的同一个人。
充分认证：SAML的身份验证上下文机制允许用户认证在足够的(但不是超过必要的)并且适合于他们可能试图访问某些服务提供者的资源的级别。
SAML允许在服务提供者之间传达用户同意某些操作的声明。如何、何时或在何处获得这种同意不在SAML的范围之内。

2）安全

关于安全方面，SAML定义了许多安全机制来检测和防范此类攻击。主要机制是依赖方和断言方具有预先存在的信任关系，这种关系通常依赖于公钥基础设施(PKI)。虽然SAML不强制使用PKI，但强烈建议使用PKI。

关于每个SAML Binding的安全机制核心的内容包括以下几个方面：

需要保证消息完整性和保密性时，需要使用TLS安全协议；
当依赖方（relying party）向断言方（asserting party）请求一个断言（assertion）时，需要双向认证，TLS协议也提供双向认证的机制；
当通过Web浏览器使用HTTP POST binding发给依赖方（relying party）一个响应消息中包含一个断言（assertion）时，为了保证消息的完整性，必须使用XML签名。

通过以上几点可以看出，关于SAML核心保护的就是消息的CIA安全三要素，无论是发送方还是接收方，都需要严格遵守标准里定义的规则与要求才能安全地使用标准。

五、SAML可能遇到的安全问题

如果要了解SAML可能存在的问题，首先就需要了解SAML的工作流程。SAML有两种模式，一种是SP发起的SSO，另外一种是IDP发起的SSO。下面是SP发起的SSO的流程：

第一步、用户通过浏览器访问SP的网站sp.example.com;

第二步、由于用户没有登录，SP发送一个重定向【302、303】的响应消息给浏览器，重定向到配置好的IDP的站点idp.example.org;

第三步、SSO服务会在IDP站点会判断该账号是否有一个已经登录，如果没有登录，就会通过浏览器显示登录对话框，让用户登录；

第四步、用户通过账号和密码登录；

第五步、浏览器收到登录成功的响应消息以及签名的SAML响应消息发会给浏览器；

第六步、根据响应消息中获取之前访问的SP的站点信息，自动重定向到SP的站点，并且将SAML的响应消息和Token以HTTP POST消息发送SP的断言消费者服务（Assertion Consumer Service），断言消费者服务验证SAML的响应消息，包括消息的签名；如果验证通过，就会为用户创建以SP本地登录成功的安全上下文。一旦确认用户登录成功，SP就会发送一个重定向到用户开始访问的资源的URL。

第七步、SP再次收到资源访问的请求，检查用户是否有权限访问该资源，如果具备访问该资源的权限，将该资源返回给浏览器。

通过这个流程可以发现SAML的流程还是比较复杂，步骤比较多，牵涉到SP、IDP、客户端和用户等，任何一方在实现上出现瑕疵或者配置上的小错误，就可能会影响到整个流程的安全。一个常见的流程是身份提供者向浏览器返回SAML消息，浏览器将消息转发给服务提供者。消息在经过浏览器中转的时候，就存在被篡改的可能。SAML是使用XML实现的，SAML的消息是Base64编码的，很容易通过Base64解码查看消息的具体内容。通常，SAML消息被篡改的内容主要是签名和断言（Assertion）。签名加强IP和服务提供商之间的信任关系；断言指示服务提供商执行哪些受信任的操作，通常允许某个用户访问应用程序的某些资源。任何一个被篡改，就会导致整个信任链的缺失，也就导致整个流程的安全的崩塌。

下面就罗列一下SAML实现过程中可能遇到的问题，以及应对策略。

消息的时效性

SAML消息中都包含了一个关于认证消息的时效性的条件，如下：

<saml:Conditions

NotBefore="2023-11-05T00:00:00Z"

NotOnOrAfter="2023-11-05T00:00:00Z">

<saml:AudienceRestriction>

<saml:Audience>https://sp.example.com/SAML2</saml:Audience>

</saml:AudienceRestriction>

</saml:Conditions>

如果为了省事，将SAML认证消息的有效时间设置的很长或者没有设置有效期间，则此消息中的认证信息泄露的可能性会增大，一旦被攻击者获得，攻击者就可以冒充用户发起请求获取SP提供的服务与资源。每一个SAML消息都要设置一个合理的时间范围，保证完成业务即可，不能设置太长或者不设置时效性。

1. XXE

SAML是基于XML实现的，XML有关的挑战，SAML也同样面对。嵌入的实体可能会带来XXE问题。一个SAML消息是经用户端中转的XML格式的字符串，存在篡改的可能，在使用之前要检查是否有相关的攻击向量，以防有XXE的攻击的发生。关于XXE的攻击可以参考：https://blog.csdn.net/jimmyleeee/article/details/114104185。当使用用户输入的部分作为相应消息的一部分时，也需要经过严格地验证，以防有XML注入的可能。

2. 重放攻击

断言（Assertions）应该包含一个唯一的ID，该ID只能被应用程序接受一次。以防重放SAML消息以创建多个会话。

3. 未严格验证消息签名

一种情况就是SAML消息中没有签名，如果没有签名能够通过SP的请求的话；另外一种是使用未经CA签名的证书签名。这两种方法都可能导致消息被篡改，建议使用经过CA签名的证书来验证消息的签名。

4. 签名包装

有些实现检查有效的签名并将其与有效的断言相匹配，但不检查多个断言、多个签名，或者根据断言的顺序实现也不同。XSW1、XSW2、XSW3、XSW4、XSW5、XSW6、XSW7、XSW8 是八种最常见的XML签名包装攻击。可以手动编辑或者工具编辑原始SAML文件来执行这些攻击。【关于通过XSW实现的攻击，可以冒充任何用户的攻击示例可以参考，https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91-8-23-12.pdf。】

综上所述可能的威胁，可以尝试通过修改SAML消息中的某些字段尝试攻击SAML认证，例如：修改消息中的过期时间，看看是否可以延长消息的有效期；尝试修改消息中的用户ID为其他的用户ID，如果修改成管理员的ID而且可以通过验证，就会有额外的收获；修改UserID为一个无效的ID，如果用户ID无效的处理流程有业务逻辑漏洞，也会有意想不到的收获。

BurpSuite的扩展SAML Raider是一款很好的工具，可以自动探测到SAML消息，提供解码和编译的功能，并且可以发送到Repeater里来发起XSW攻击。SAML Raider添加了一个证书选项卡，使克隆证书变得容易。可以直接克隆证书，也可以创建证书的自签名版本。

六、如何提高SSO安全性

SAML安全性是SSO应用程序中一个经常被忽视的领域。成功的SAML攻击会导致严重的漏洞利用，例如重放会话和获得对应用程序功能的未经授权的访问。要做好它的安全，可以从以下几点做起：

就需要按照标准里要求的使用安全的协议保证传输过程中SAML消息的保密性和完整性。
要使用经过权威CA验证的证书，保证签名是经过可信的机构认证的证书签名的，防止消息被篡改。
要启用安全的加密算法，对于一些不安全的加密算法可以参考：XML Encryption Syntax and Processing Version 1.1
就是针对XML格式数据要做好认证，最好是有一个认证的SCHEMA，防止XML数据被添加节点【关于SAML XML注入攻击可以参考https://research.nccgroup.com/2021/03/29/saml-xml-injection/】或者有XXE攻击的发生。其他具体的安全措施，可以参考：https://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf。
选择IDP时要确认是否提供了多因子认证（MFA），多因子认证是降低密码被窃取的关键组件。确认提供了MFA之后，要和IDP供应商一起确认正确地启用了MFA的功能。
不要相信任何输入，凡是和应用相关的而且是用户输入的内容，都需要经过严格地验证。

总之，应用程序的SSO解决方案给组织带来了优点和缺点。由于创建SSO解决方案的根本原因，SSO解决方案的缺点在某些情况下往往超过其优点，在中小型企业中尤其如此。在现代IT环境中，用户需要无缝地连接到各种各样的IT资源，SSO工具可能会阻碍它们的流程。为了解决这个问题，建议采用实时身份确认流程。这将允许持续身份验证，防止用户被锁定，同时还监视用户更改以通知管理员任何可疑活动。在实现过程中，选择可信的IDP提供商，启用安全措施，加强安全保护。同时，时刻关注安全市场上关于IDP数据泄露的动态，一旦发现有数据泄露事件发生，及时启动应急预案进行干预，将其对公司的影响降到最低。

参考：

https://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf

https://www.zluri.com/blog/sso-security-risks/

https://www.renovodata.com/blog/2019/01/17/single-sign-on

https://stackoverflow.blog/2022/09/12/the-many-problems-with-implementing-single-sign-on/

https://www.netspi.com/blog/technical/web-application-penetration-testing/attacking-sso-common-saml-vulnerabilities-ways-find/

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Understanding and Mitigating Single Sign-on Risk

https://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf

SAML XML.org | Online community for the Security Assertion Markup Language (SAML) OASIS Standard

SAML | Ping Identity

SAML XML Injection | NCC Group Research Blog | Making the world safer and more secure