Data

发布日期: 2024-08-16

更新日期: 2024-08-25

文章字数: 4.5k

阅读次数:

随着企业的发展，完成与工作相关的内容通常需要涉及到若干个系统服务（例如内部聊天用Zoom，文件共享用Dropbox，办公用Office 365，还有员工信息管理系统等等），用户在操作不同的系统时，需要多次登录，很麻烦，我们需要一种全新的登录方式来实现多系统应用群的登录，这就是SSO-单点登录。

用户只需要登录一次就可以访问所有相互信任的应用系统，即一次登录，到处使用，同样一处退出，处处退出。

以游乐场的通票为例：我们只要买一次通票，就可以玩所有游乐场内的设施，而不需要在过山车或者摩天轮那里重新买一次票。在这里，买票就相当于登录认证，游乐场就相当于使用一套 SSO 的公司，各种游乐设施就相当于公司的各个产品。

SSO 类型

SSO 解决方案使用不同的标准和协议来对用户凭证进行验证和身份验证。

安全访问标记语言 ( SAML )：SAML 是一种开放标准，SAML 使用 XML（一种浏览器友好的标记语言）来交换用户标识数据。基于 SAML 的 SSO 服务提供更好的安全性和灵活性，因为应用程序不需要在其系统上存储用户凭证。SAML 2.0 专门针对 Web 应用程序进行了优化，允许通过 Web 浏览器传输信息。
开放授权 (OAuth)：OAuth是一种开放标准授权协议，它允许应用程序安全地从其他网站获取用户信息，而无需提供密码。应用程序不是请求用户密码，而是使用 OAuth 来获得用户访问受密码保护的数据的权限。OAuth 通过 API 建立应用程序之间的信任，允许应用程序在已建立的框架中发送和响应身份验证请求。
OpenID Connect (OIDC)：OIDC位于 OAuth 2.0 之上，用于添加有关用户的信息并启用 SSO 流程。它允许一个登录会话在多个应用程序中使用。例如，OIDC允许用户使用他们的 Facebook 或 Google 帐户登录服务，而无需输入用户凭据。
Kerberos：Kerberos 是一种支持相互身份验证的协议，用户和服务器均可通过不安全的网络连接验证对方的身份。它使用票证授予服务颁发令牌来验证用户和软件应用程序（如电子邮件客户端或 wiki 服务器）。
智能卡身份验证：除了传统的 SSO，硬件也可以实现相同的过程，例如用户插入计算机的物理智能卡设备。计算机上的软件与智能卡上的加密密钥交互以对每个用户进行身份验证。虽然智能卡非常安全并且需要 PIN 才能操作，但它们必须由用户随身携带，存在丢失的风险。它们的操作成本也可能很高

CAS

**CAS（Central Authentication Service） **—— 中央认证服务，是 Yale 大学发起的一个企业级的、开源的项目，旨在为 Web 应用系统提供一种可靠的 SSO 解决方案。

CAS 官网：CAS | Apereo Foundation

CAS 源码：apereo/java-cas-client: Apereo Java CAS Client (github.com)

CAS 组成

CAS Server：CAS Server 负责完成对用户的认证工作 , 需要独立部署。 CAS Server 会处理用户名 / 密码等凭证(Credentials)。
CAS Client：负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到 CAS Server 进行认证。（CAS Client与受保护的客户端应用部署在一起，以 Filter方式保护受保护的资源）

CAS 票据

用户在 CAS 认证成功后，CAS 生成 Cookie （TGC），写入浏览器；

同时生成一个 TGT 对象，放入自己的缓存（Session），TGT 对象的 key 就是Cookie（TGC）的值；

当 HTTPS 再次请求到来时，如果传过来的有 CAS 生成的Cookie，则 CAS 以此 Cookie 值为 key 查询缓存中有无TGT ，如果有的话，则说明用户之前登录过，如果没有，则用户需要重新登录。通过TGT 来获取 ST(Service Ticket)，通过ST来访问具体服务。

TGT（Ticket Grangting Ticket）：CAS Server 创建 TGT，存在 CAS Server 的 Session 里面，根据用户信息签发的，拥有了TGT，用户就可以证明自己在CAS成功登录过。
TGC（Ticket Granting Cookie）：创建 TGT 的同时，生成 TGC。通过 CAS Server 的 response header 的 set-cookie 字段设置 TGC
- 由 CAS Server 通过 SSL 方式发送给终端用户，存放用户身份认证凭证的Cookie，在浏览器和CAS Server间通讯时使用，并且只能基于安全通道传输（Https），是CAS Server用来明确用户身份的凭证。
ST（Service Ticket）：根据 TGT 签发的 ST，是 CAS 为用户签发的访问某一服务的票据（SessionId）
- 用户访问service时，service发现用户没有ST，则要求用户去CAS获取ST。用户向CAS发出获取ST的请求，如果用户的请求中包含Cookie（TGC），则CAS会以此Cookie值为key查询缓存中有无TGT，如果存在TGT，则用此TGT签发一个ST，返回给用户。用户凭借ST去访问service，service拿ST去CAS验证，验证通过后，允许用户访问资源。

SSO 原理

SSO-登录

上面是一张SSO登录原理图，下面我们来分析一下具体的流程：

首先用户访问系统1受保护的资源，系统1发现未登陆，跳转至SSO认证中心，并将自己的参数传递过去
SSO认证中心发现用户未登录，将用户引导至登录页面
用户输入用户名和密码提交至SSO认证中心
SSO认证中心校验用户信息，创建用户与SSO认证中心之间的会话，称为全局会话，同时创建授权令牌
SSO认证中心带着令牌跳转会最初的请求地址（系统1）
系统1拿到令牌，去SSO认证中心校验令牌是否有效
SSO认证中心校验令牌，返回有效，注册系统1的地址
系统1使用该令牌创建与用户的会话，称为局部会话，返回给用户受保护资源
用户访问系统2受保护的资源
系统2发现用户未登录，跳转至SSO认证中心，并将自己的地址作为参数传递过去
SSO认证中心发现用户已登录，跳转回系统2的地址，并附上令牌
系统2拿到令牌，去SSO认证中心校验令牌是否有效
SSO认证中心校验令牌，返回有效，注册系统2地址
系统2使用该令牌创建与用户的局部会话，返回给用户受保护资源

用户登录成功之后，会与SSO认证中心及各个子系统建立会话，用户与SSO认证中心建立的会话称为全局会话，用户与各个子系统建立的会话称为局部会话，局部会话建立之后，用户访问子系统受保护资源将不再通过SSO认证中心，全局会话与局部会话有如下约束关系：

局部会话存在，全局会话一定存在
全局会话存在，局部会话不一定存在
全局会话销毁，局部会话必须销毁

SSO-注销

既然有登陆那么就自然有注销，单点登录也要单点注销，在一个子系统中注销，所有子系统的会话都将被销毁。原理图如下：

logout

SSO认证中心一直监听全局会话的状态，一旦全局会话销毁，监听器将通知所有注册系统执行注销操作

同样的我们也来分析一下具体的流程：

用户向系统1发起注销请求
系统1根据用户与系统1建立的会话id拿到令牌，向SSO认证中心发起注销请求
SSO认证中心校验令牌有效，销毁全局会话，同时取出所有用此令牌注册的系统地址
SSO认证中心向所有注册系统发起注销请求
各注册系统接收SSO认证中心的注销请求，销毁局部会话
SSO认证中心引导用户至登录页面

SSO 安全风险

虽然单点登录为用户带来了便利，但它也给企业安全带来了风险。控制了用户 SSO 凭证的攻击者将获得访问用户有权访问的所有应用程序的权限，这增加了潜在损害的程度。

保证单点登录安全性的方式：

安全协议和标准：使用安全协议和标准，如OAuth 2.0、OpenID Connect和SAML等，这些协议提供了身份认证、令牌管理和令牌传输的安全机制。
强密码策略：要求用户使用强密码，并实施密码策略，例如密码长度、复杂性要求、定期更改密码等。
双因素认证：引入双因素认证，结合密码和其他因素（如短信验证码、指纹识别等）进行身份验证，提高安全性。企业可以使用双因素身份验证 ( 2FA ) 或多因素身份验证与 SSO 来提高安全性。
令牌的安全传输和存储：确保令牌在传输过程中进行加密，并在存储时进行安全保存，防止令牌泄漏或篡改。
会话管理：实施严格的会话管理机制，包括会话过期时间、会话注销和强制重新认证等，以减少会话劫持和会话固定攻击。
防止跨站脚本攻击（XSS）：采用适当的输入验证和输出编码，以防止XSS攻击，确保用户提交的数据不包含恶意脚本。
安全审计和监控：实施日志记录、监控和审计机制，及时检测并响应异常活动和安全事件。(踢蹬，溯源)

常见的安全风险：

令牌泄漏：令牌在传输或存储过程中被未授权的人员获取，导致身份被冒用。
会话劫持：攻击者获取有效会话的控制权，从而冒充合法用户进行操作。
跨站脚本攻击（XSS）：攻击者通过注入恶意脚本，从用户浏览器中窃取会话令牌或其他敏感信息。
令牌篡改：攻击者在传输过程中修改令牌的内容，以获取额外权限或冒充其他用户。
错误配置和漏洞利用：不正确的配置或漏洞导致攻击者绕过认证流程或访问未授权的资源。
社会工程学攻击：攻击者通过欺骗用户获取其凭据或其他敏感信息，例如钓鱼攻击、假冒网站等。

SSO 安全审计

方案简述：消费边界日志（NIDS）和SSO登录日志，从「报文」和「行为」上计算特征（比如UA异常、异地登录/访问是从报文的UA和IP来计算；登录没有权限的系统、短时间登录大量之前没有登录过的系统是从行为上计算），然后通过特征组合形成规则，命中规则后执行踢Token和告警。

审计链路

-> 从NIDS日志中筛选SSO域名（sso.xxx.com）流量，从ResponseHeader、ResponseBody、Cookie中查找TGCX，并解析TGT结构体，同时关联ES中的历史登录日志，找出生成此TGT的IP，UA和登录接口（action）。

-> 从SSO登录日志离线数据(ES)中提取用户过去历史访问过的应用集合，为用户历史应用访问行为基线（如xx时间内访问了xx个新应用）提供数据。

-> 消费SSO登录Kafka日志，进行SSO单点登录审计（TGT盗用审计），主要逻辑：

SSO登录日志写入Mysql，为审计任务提供历史数据（小时级别的），比如同一个TGT在前后不同的IP下使用，要对比其前后设备ID。注：之所以不直接使用ES的数据是因为ES查询稳定性和速度相比Mysql要差，Mysql的数据只存储1天。
逐条审计SSO登录日志，检查是否违反：
- a.TGT生成和TGT使用的环境信息不一致
- b. TGT最近两次使用的环境信息不一致
- c.出现行为异常（如访问非目标岗位应用，没有IAM权限…）

（如果上面审计捕获到任意异常）则

a.将异常登录日志写入Mysql
b.过单个日志异常规则，判断是否是违反某个盗用规则
c.根据同一个IP、dfpid(设备唯一 id)回溯历史异常登录日志，按滑动窗口计算是否满足异常聚集阈值
d. 如果b/c有命中，则下发票据处置决策（如果开启自动下发决策的话）

当识别到一个票据命中盗用规则，或者产生异常特征聚集，则判断该票据被盗用，会通知SSO对票据做过期处置。

在实际场景中需要考虑误报对用户产生的干扰，特别是要防止短时间大量误报伤害大量用户体验，因此要考虑熔断。

金银票据传递攻击

Kerberos协议

Kerberos是一种计算机的认证协议，在域中使用kerberos作为认证手段。他提供了一种单点登录（SSO）的方法，比如打印服务器、邮件服务器和文件服务器。这些服务器都有认证的需求，很自然的，不可能让每个服务器自己实现一套认证系统，而是提供一个中心认证服务器（CAS）供这些服务器使用，这样任何客户端就只需要维护一个密码就能登录所有服务器。

角色：客户端（Client）、身份认证服务（AS）、票据授予服务（TGS）、普通服务器（Server）

Kerberos协议的基本流程是Client先通过AS（身份认证服务）进行身份认证，认证通过后AS会给Client一个TGT（票据授权票），Client将获取到的TGT发送到TGS（票据授予服务）进行身份验证，验证通过后TGS会给Client一个ST（服务票据），Client通过这个ST去访问指定Server上的服务。

金银票据攻击

黄金票据、白银票据攻击是基于kerberos认证协议的攻击方式，常用来做后渗透域控权限维持。由于用户正常访问资源是也会请求服务票证，因此黄金、白银票据攻击具备很高的隐蔽性。

在kerberos认证中，主要解决两个问题

第一个问题：如何证明你本人是XXX用户的问题。（身份问题，黄金票据所在的问题，AS负责）

第二个问题：提供服务的服务器如何知道你有权限访问它提供的服务。当一个Client去访问Server服务器上的服务时，Server如何判断Client是否有权限来访问自己主机上的服务。（白银票据所在的问题，TGS负责）

伪造黄金票据

在kerberos认证中，Client通过AS认证后，AS会给Client一个TGT，而TGT是通过域控服务器上krbtgt账户的Hash进行加密的，所以只有得到krbtgt的Hash，就可以伪造TGT来进入下一步Client与TGS的交互。而在有了黄金票据后，就跳过AS验证，不用验证账户和密码，所以也不担心域管来修改密码。意思就是，当攻击者能够获得krbtgt的Hash后，攻击者就可以伪造一张票据授权票，去伪造成域内的任意用户访问域内kerberos认证的所有服务。

伪造白银票据

黄金票据攻击是伪造TGT，白银票据攻击是伪造ST，在kerberos认证协议的第三步，Client带着ST向Server上的某个服务进行请求，Server接收Client的请求，验证通过后允许Client使用Server上的指定服务。所以只要有了服务器管理员账户的Hash，就能跳过向TGS请求ST的过程，可以直接伪造ST使用Server上的服务。