SAML is used to implement SSO—or Single-Sign-On. SSO allows users to access a variety of services throughout an organization without logging into each one individually. For example, if you were logged into your Facebook account you wouldn’t need to reenter your password to access Messenger.

It is in this way that companies can have a centralized source of user credentials as opposed to tracking users on each site. This also keeps users from having to log in multiple times when they use a variety of applications and services within the same organization.

This post is going to go over options (other than SAML) that you can use to implement SSO, along with the vulnerabilities that come with each of them.

The Tale of Three SSOs

Cookie sharing, SAML, and OAuth are the three most common ways of implementing SSO.

Cooking Sharing Between Subdomains (Shared-Session SSO)

One way that applications can implement SSO is by sharing cookies across subdomains. Browser cookies can be shared across subdomains if their domain flag is set to a common parent domain. In this case, the cookie will be sent for any subdomain of facebook.com.

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

This is the simplest SSO setup. But with its simplicity, this approach also comes with a unique set of vulnerabilities.

The Achilles’ heel of cookie sharing is subdomain integrity. If attackers can steal the shared session cookie by compromising a single subdomain, all the SSO sites would be at risk. Usually, hackers steal the session cookies by finding a subdomain takeover, RCE, XSS, or any other vulnerability that would expose the user’s cookie.

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 individual service.

#security #oauth #hackers