SAML Vulnerabilities

Description

Security Assertion Markup Language (SAML) is an XML-based standard for federated single sign-on (SSO) used extensively in enterprise environments — connecting identity providers (IdPs) like Okta, Azure AD, and Shibboleth to service providers (SPs) such as AWS, Salesforce, and custom enterprise applications. SAML vulnerabilities (CWE-345, insufficient verification of data authenticity) arise from complex XML signature semantics, parser inconsistencies, and implementation oversights in the assertion validation logic.

The most severe SAML vulnerabilities are XML Signature Wrapping (XSW) attacks, SAML attribute injection via XML comment insertion, and XXE in SAML parsers. These vulnerabilities allow an attacker to forge SAML assertions that authenticate them as an arbitrary user — including administrators — without knowing any credentials or having access to the signing private key.

SAML vulnerabilities fall under OWASP A07:2021 (Identification and Authentication Failures) and are categorized as high-severity because they bypass the entire authentication layer of an application, affecting every user of the SSO integration. Enterprise applications relying exclusively on SAML for authentication have no fallback if the SAML validation is circumvented.

How It Works

XML Signature Wrapping (XSW):

SAML assertions are signed with XML Signature. However, XML Signature signs a specific XML element — not the entire document. The vulnerability arises when the SP validates the signature of one element but reads authentication data from a different, unsigned element in the same document.

An attacker modifies a valid SAML assertion by duplicating the signed <Assertion> element, placing the original (signed) element as an invisible duplicate and modifying the visible (unsigned) copy with attacker-controlled data:

<Response>
  <Assertion ID="attacker_copy">
    <Subject><NameID>admin@target.com</NameID></Subject>  ← SP reads this
  </Assertion>
  <Assertion ID="signed_copy">
    <Subject><NameID>attacker@attacker.com</NameID></Subject>  ← Signature covers this
    <Signature>...</Signature>
  </Assertion>
</Response>

The signature is valid (covering the original element). The SP authenticates the attacker as admin@target.com because it reads from the unsigned copy.

XML Comment Injection (CVE-2017-11427 and similar):

Some SAML parsers handle XML comments (<!-- -->) inconsistently during username extraction:

<NameID>admin<!--comment-->@target.com</NameID>

If the signature covers the full element value including the comment, but the SP's username extraction strips the comment, the SP receives admin@target.com while the signature was over admin<!--comment-->@target.com — a valid signature on a different effective value.

Tools: The SAMLRaider Burp Suite extension provides a complete toolkit for intercepting, decoding, modifying, and re-signing SAML assertions. It supports XSW attacks (8 standard wrapping patterns), signature removal, and XXE injection.

# In Burp Suite with SAMLRaider:
1. Intercept SAML response (often base64-encoded POST parameter)
2. Decode with SAMLRaider
3. Apply XSW pattern 1-8
4. Forward modified assertion

Impact

• Authentication Bypass — Logging into the SP as any user without valid IdP credentials
• Privilege Escalation — Impersonating administrator accounts by forging the username claim in the assertion
• Cross-Tenant Access — In multi-tenant SaaS, manipulating tenant identifier claims to access other organizations' data
• Single Sign-On Scope — A successful SAML forgery affects all applications that trust the same IdP-SP relationship
• Persistent Access — SAML sessions can be long-lived, providing extended access after a single successful forgery

Detection

1. Intercept and decode SAML assertions — use Burp Suite with SAMLRaider to intercept the SAMLResponse POST parameter. Base64-decode and inspect the XML structure and signature coverage.
2. Test XSW patterns — use SAMLRaider to automatically generate all 8 XSW patterns against the intercepted assertion and forward each to the SP. A successful login as the target user confirms XSW vulnerability.
3. Test signature removal — strip the <Signature> element entirely and forward the modified assertion. If the SP accepts it, signature validation is not enforced.
4. Test NameID comment injection — modify the NameID value to include XML comments within the username: admin<!--x-->@corp.com. Check if the SP authenticates as admin@corp.com.
5. Test XXE in assertion — inject an XXE entity declaration into the DOCTYPE of the SAML document. Monitor for out-of-band DNS/HTTP callbacks confirming parser-level XXE.
6. Verify assertion freshness — replay an old SAML assertion (captured from a previous login) to test whether the SP enforces the NotOnOrAfter timestamp and prevents assertion replay.

Remediation

Use a well-maintained SAML library with active security maintenance. Avoid building custom SAML parsers. Recommended libraries include python3-saml, OneLogin's SAML toolkits, and Spring Security SAML.

Validate that the signature covers the specific element used for authentication. Implement strict assertion extraction that references only the signed element:

# python3-saml — strict validation
settings = {
    "strict": True,
    "security": {
        "wantAssertionsSigned": True,
        "wantMessagesSigned": True,
        "rejectUnsolicitedResponsesWithInResponseTo": True,
    }
}

Enforce assertion replay prevention. Store and check assertion IDs (InResponseTo, AssertionID) to ensure each assertion is used only once.

Set short NotOnOrAfter windows. Limit assertion validity to 5 minutes maximum. Shorter windows limit the replay window if an assertion is captured.

Disable external entity processing in the SAML XML parser. XXE in SAML parsers has been exploited in production — apply the same parser hardening used for general XXE mitigation.