0

我将使用以下方案来实现 SSO -

初始登录 -

  1. 每当用户加载客户端应用程序时，他都会被重定向到 SSO 登录页面。
  2. 一旦用户登录，就会在客户端上设置一个加密的 cookie 令牌，并且该值也存储在会话中。

访问另一个应用程序 -

  1. 当用户加载另一个客户端应用程序时，他会再次被重定向到 SSO 登录页面。
  2. SSO 模块首先检查加密的 cookie 是否存在，然后将该值与会话中的值进行比较。
  3. 如果这两者都匹配，它会将用户重定向回经过身份验证的用户。
  4. 否则它会要求用户输入用户名/密码。

此方案是否存在任何安全漏洞？

谢谢，穆尔塔萨

4

1 回答 1

1

对于 SSO 方案，该设计似乎相当标准。当然，即使这个概念是安全的，在该方案的实施中也可能出现漏洞。例如，一个安全的实现需要防止 SSO 身份验证 cookie 的泄露以及对依赖系统的身份断言中的漏洞。此外，身份验证机制本身的漏洞（例如弱密码）可能会在 SSO 环境中被放大，在该环境中，可以使用单个凭据对多个应用程序进行身份验证。

使用加密的 cookie 和会话来识别依赖应用程序的最终用户可能是多余的，如果动机是防御会话劫持攻击，则可能无效。如果包含这些 cookie 的 HTTP 请求曾经以明文形式发送，则会话 ID 和加密的 cookie 密文都将以明文形式发送，这可能会引发欺骗漏洞。（当然，不会发送 cookie 明文，但攻击者只需要 cookie 的密文内容。）为了减轻这种威胁，会话 cookie 应该设置为安全的，并且 SSO 登录页面只能通过 SSL 访问。

如果加密 cookie 的动机是允许在会话生命周期之后保存凭证，则需要注意使用适当的加密实践（例如，密钥管理和使用标准加密算法）。当然，cookie 应该被标记为安全的，以确保（出于实际目的）它不是以明文形式发送的。可能需要采取其他对策，例如在每次断言后更新 cookie 以防止重复，以及限制生命周期（例如，要求每x天重新验证一次）。

该方案还要求验证者在成功认证最终用户后向 RP 做出身份断言。有几种标准协议，例如OAuth和OpenID。

最后，用户应该有权终止 SSO 会话，以防止在用户离开会话时进行未经授权的访问。

当然，需要考虑依赖系统的保证要求——如果 SSO 系统受到损害，风险（在可能性和影响方面）是什么？随着风险的增加，防御妥协的战略和运营对策（例如，风险和脆弱性评估）的成本效益也会增加。

于 2012-07-18T10:56:14.847 回答