Question

Cookie sharing, SAML, and OAuth are the three most common ways of implementing SSO. Each mechanism has unique strengths and weaknesses, and developers choose different approaches depending on their needs.

Cookie 共享、SAML 和 OAuth 是实现 SSO 的三种最常见的方式。每种机制都有其独特的优点和缺点，开发人员根据他们的需求选择不同的方法。

Cooking Sharing

The implementation of SSO is quite easy if the services that need to share authentication are located under the same parent domain, as is the case with the web and mobile versions of Facebook at www.facebook.com and m.facebook.com . In these situations, applications can share cookies across subdomains.

如果需要共享身份验证的服务位于相同的父域下，实施单点登录(SSO) 就非常容易。这在 Facebook 网站和移动应用程序版本 www.facebook.com 和 m.facebook.com 中是这样的情况。在这些情况下，应用程序可以在子域之间共享 cookies。

How Cookie Sharing Works

Modern browsers allow sites to share their cookies across subdomains if the cookie’s Domain flag is set to a common parent domain. For example, if the server sets a cookie like the following, the cookie will be sent to all subdomains of facebook.com :

现代浏览器允许网站通过将 Cookie 的 Domain 标志设置为公共父域来跨子域共享 Cookie。例如，如果服务器设置以下 Cookie，该 Cookie 将被发送到 Facebook.com 的所有子域：

Set-Cookie: cookie=abc123;     Domain=facebook.com ; Secure; HttpOnly

However, not all applications can use this approach, because cookies can’t be shared this way across different domains. For instance, facebook.com and messenger.com can’t share cookies, because they don’t share a common parent domain.

然而，并非所有应用程序都能使用此方法，因为 Cookie 不能在不同域之间以此方式共享。例如，facebook.com 和 messenger.com 不能共享 cookie，因为它们没有共同的父域。

Moreover, this simple SSO setup comes with unique vulnerabilities. First, because the session cookie is shared across all subdomains, attackers can take over the accounts of all websites under the same parent domain by stealing a single cookie from the user. Usually, attackers can steal the session cookies by finding a vulnerability like cross-site scripting.

此外，这种简单的单点登录设置存在独特的漏洞。首先，由于会话 cookie 在所有子域之间共享，攻击者可以通过窃取用户的单个 cookie 接管同一父域下所有网站的帐户。通常，攻击者可以通过查找如跨站脚本等漏洞来窃取会话 cookie。

Another common method used to compromise shared-session SSO is with a subdomain takeover vulnerability.

另一种常用的攻击共享会话单点登录的方法是使用子域劫持漏洞。

Subdomain Takeovers

Put simply, subdomain takeovers occur when an attacker takes control over a company’s unused subdomain.

简单来说，子域接管发生在攻击者接管公司未使用的子域名时。

Let’s say a company hosts its subdomain on a third-party service, such as AWS or GitHub Pages. The company can use a DNS CNAME record to point the subdomain to another URL on the third-party site. This way, whenever users request the official subdomain, they’ll be redirected to the third-party web page.

假设有一家公司将其子域名托管在第三方服务上，例如 AWS 或 GitHub Pages 上。该公司可以使用 DNS CNAME 记录将子域名指向第三方站点上的另一个 URL。这样，每当用户请求正式子域名时，他们将被重定向到第三方网页。

For example, say an organization wants to host its subdomain, abc.example.com , on the GitHub page abc_example.github.io . The organization can use a DNS CNAME record to point abc.example.com to abc_example.github.io so that users who try to access abc.example.com will be redirected to the GitHub-hosted page.

例如，假设一个组织希望将其子域 abc.example.com 托管在 GitHub 页面 abc_example.github.io 上。该组织可以使用 DNS CNAME 记录将 abc.example.com 指向 abc_example.github.io，以便尝试访问 abc.example.com 的用户将被重定向到托管在 GitHub 上的页面。

But if this third-party site is deleted, the CNAME record that points from the company’s subdomain to that third-party site will remain unless someone remembers to remove it. We call these abandoned CNAME records dangling CNAMEs . Since the third-party page is now unclaimed, anyone who registers that site on the third-party service can gain control of the company’s subdomain.

如果这个第三方网站被删除了，从公司子域名到第三方网站的 CNAME 记录会继续存在，除非有人记得删除它。我们称这些废弃的 CNAME 记录为悬挂的 CNAME。由于第三方页面现在无人认领，任何在第三方服务上注册该网站的人都可以控制公司的子域名。

Let’s say the company in our example later decides to delete the GitHub page but forgets to remove the CNAME record pointing to abc_example.github.io . Because abc_example.github.io is now unclaimed, anyone can register a GitHub account and create a GitHub page at abc_example.github.io . Since abc.example.com still points to abc_example.github.io , the owner of abc_example.github.io now has full control over abc.example.com .

假设我们的例子中的公司决定删除 GitHub 页面，但忘记删除指向 abc_example.github.io 的 CNAME 记录。由于 abc_example.github.io 现在未被认领，任何人都可以注册 GitHub 帐户并在 abc_example.github.io 上创建 GitHub 页面。由于 abc.example.com 仍然指向 abc_example.github.io，abc_example.github.io 的所有者现在完全控制 abc.example.com。

Subdomain takeovers allow attackers to launch sophisticated phishing campaigns. Users sometimes check that the domain name of a page they’re visiting is legit, and subdomain takeovers allow attackers to host malicious pages using legitimate domain names. For example, the attacker who took over abc.example.com can host a page that looks like example.com on the GitHub page to trick users into providing their credentials.

子域劫持让攻击者能够启动复杂的网络钓鱼攻击。用户有时会检查他们正在访问的页面的域名是否合法，而子域劫持允许攻击者使用合法的域名来托管恶意页面。例如，劫持 abc.example.com 的攻击者可以在 GitHub 页面上托管一个看起来像 example.com 的页面，以欺骗用户提供他们的凭证。

But subdomain takeovers can become even more dangerous if the organization uses cookie sharing. Imagine that example.com implements a shared-session-based SSO system. Its cookies will be sent to any subdomain of example.com , including abc.example.com . Now the attacker who took over abc.example.com can host a malicious script there to steal session cookies. They can trick users into accessing abc.example.com , maybe by hosting it as a fake image or sending the link over to the user. As long as the victim has already logged into example.com ’s SSO system once, the victim’s browser will send their cookie to the attacker’s site. The attacker can steal the victim’s shared session cookie and log in as the victim to all services that share the same session cookie.

子域接管可能会变得更加危险，如果组织使用 cookie 共享。想象一下，example.com 实施了共享会话基础的 SSO 系统。它的 cookie 将被发送到 example.com 的任何子域，包括 abc.example.com。现在接管了 abc.example.com 的攻击者可以在那里托管恶意脚本来窃取会话 cookie。他们可以通过主持它作为假图像或向用户发送链接来诱骗用户访问 abc.example.com。只要受害者已经登录 example.com 的 SSO 系统一次，受害者的浏览器就会将他们的 cookie 发送到攻击者的站点。攻击者可以窃取受害者的共享会话 cookie 并以受害者的身份登录所有共享同一会话 cookie 的服务。

If the attacker can steal the shared session cookie by taking control of a single subdomain, all example.com sites will be at risk. Because the compromise of a single subdomain can mean a total compromise of the entire SSO system, using shared cookies as an SSO mechanism greatly widens the attack surface for each service.

如果攻击者能够通过控制单个子域名窃取共享会话 cookie，则所有 example.com 网站都会面临风险。因为单个子域名的妥协可能意味着对整个 SSO 系统的完全妥协，使用共享 cookie 作为 SSO 机制极大地扩大了每个服务的攻击面。

Security Assertion Markup Language

Security Assertion Markup Language ( SAML) is an XML-based markup language used to facilitate SSO on larger-scale applications. SAML enables SSO by facilitating information exchange among three parties: the user, the identity provider, and the service provider.

安全断言标记语言（SAML）是一种基于 XML 的标记语言，用于在更大规模的应用程序上实现单点登录。SAML 通过促进三方之间的信息交换而实现 SSO：用户、身份提供者和服务提供者。

How SAML Works

In SAML systems, the user obtains an identity assertion from the identity provider and uses that to authenticate to the service provider. The identity provider is a server in charge of authenticating the user and passing on user information to the service provider. The service provider is the actual site that the user intends to access.

在 SAML 系统中，用户从身份提供者获得身份断言，并使用它来向服务提供者进行身份验证。身份提供者是负责对用户进行身份验证并将用户信息传递给服务提供者的服务器。服务提供者是用户打算访问的实际网站。

Figure 20-1 illustrates how the process works.

图 20-1 说明了该过程的工作原理。

Figure 20-1 : A simplified view of the SAML authentication process

图 20-1：SAML 认证过程的简化视图。

First, you try to access a resource from the service provider. Since you aren’t logged in, the service provider makes you send a SAML request to the identity provider. Once you’ve provided your credentials, the identity provider will send you a SAML response, which you can use to authenticate to the service provider. The SAML response contains an identity assertion that communicates your identity to the service provider. These are usually uniquely identifiable pieces of information such as your username, email address, or user ID. For instance, take a look at the following SAML identity assertion. It communicates the user’s identity via the user’s username:

首先，您尝试从服务提供商访问资源。由于您尚未登录，服务提供商要求您向身份提供商发送 SAML 请求。一旦您提供了凭据，身份提供商将向您发送 SAML 响应，您可以使用该响应来对服务提供商进行身份验证。SAML 响应包含一个身份断言，用于向服务提供商传达您的身份信息。这些通常是可唯一标识的信息片段，例如您的用户名、电子邮件地址或用户 ID。例如，查看以下 SAML 身份断言。它通过用户的用户名来传达用户的身份。

<saml:AttributeStatement>
 <saml:Attribute Name="username">
   <saml:AttributeValue>
     user1
   </saml:AttributeValue>
 </saml:Attribute>
</saml:AttributeStatement>

---