SAML authentication attacks

When it applies

The app authenticates via SAML SSO — the browser POSTs a base64 SAMLResponse (an XML assertion signed by the IdP) to the SP's ACS endpoint. Break the signature validation and you forge login as anyone.

Why it works

SAML security rests entirely on the SP correctly validating the XML signature over the assertion. XML signature validation is notoriously error-prone: SPs accept unsigned assertions, validate the wrong element, or can be tricked by XML Signature Wrapping (XSW) — where a signed element is kept for validation but an injected unsigned assertion is what the app actually reads.

Method

1. Capture & decode the SAMLResponse (Burp + SAML Raider extension). Identify what's signed (Response vs Assertion) and the NameID/attributes that set the user.
2. Signature exclusion: strip the <ds:Signature> and send — some SPs accept unsigned assertions.
3. XSW: wrap/inject a second assertion (or move the signature) so the validator checks the original signed blob but the app consumes your forged assertion with NameID=admin (SAML Raider automates the XSW variants).
4. Comment injection: admin@corp.com<!---->.evil in NameID — some parsers read it as admin@corp.com post-canonicalization → login as admin.
5. Other: key confusion (SP trusts attacker cert), XXE in the SAML parser (→ web-xxe), replay if no NotOnOrAfter/InResponseTo checks, Recipient/Audience not validated.

Gotchas

• Identify the exact signed element first — XSW works by satisfying the validator while changing what's used.
• If signatures are properly validated over the assertion with no wrapping bug, pivot to replay/audience/comment issues.
• Prove with two accounts you own: forge from a low-priv login into a privileged NameID.

Verify success

Authentication as a different/privileged user via a forged or manipulated SAMLResponse the SP accepts.

References

PortSwigger SAML; SAML Raider; "On Breaking SAML" (XSW, Somorovsky et al.).