Attacking Saml

Attacking SAML

SAML security is XML signature validation, and XML signatures are notoriously hard to validate correctly. The assertion is signed — but which element is signed, what the XML parser reads, and what the application ultimately trusts can be three entirely different things. That gap is XML Signature Wrapping, and it is the reason SAML breaks far more often than its cryptography suggests.

Only against systems you are authorized to test.

When to Use

• A request or redirect carries a SAMLRequest or SAMLResponse parameter
• Base64 (plus DEFLATE for the redirect binding) decodes to XML containing <saml:Assertion>, <samlp:Response>, or <saml:Subject>
• The target exposes a /saml/acs, /sso, /saml2/acs, or /Shibboleth.sso Assertion Consumer Service endpoint
• An IdP-initiated login POSTs an assertion straight to the SP with no prior AuthnRequest
• Federation runs through Okta, ADFS, PingFederate, Azure/Entra, Shibboleth, SimpleSAMLphp, or Keycloak
• You control a low-privilege federated account and want to reach another identity or role

When NOT to Use

• The SSO flow is OAuth 2.0 or OpenID Connect (code, id_token, access_token, /authorize, /.well-known/openid-configuration) — use attacking-oauth-oidc
• The token is a JWT (eyJ... with dot separators) rather than signed XML — use attacking-jwt
• General web testing with no SAML artifact in scope — use testing-web-applications
• Golden SAML against a compromised AD FS server or cloud tenant where you already hold the token-signing key — that is a tenant-takeover play in attacking-entra-id
• Evaluating the signature primitives themselves (SHA-1 vs SHA-256, RSA key size, canonicalization algorithm choice) — use reviewing-cryptography

Decode and Inspect

Everything starts with reading the message. The wire format depends on the binding.

# HTTP-Redirect binding: base64 then raw DEFLATE (no zlib header)
echo 'fVLLbtsw...' | base64 -d | python3 -c \
  "import sys,zlib; sys.stdout.write(zlib.decompress(sys.stdin.buffer.read(),-15).decode())"

# HTTP-POST binding: plain base64, no deflate
echo 'PHNhbWxwOl...' | base64 -d | xmllint --format -

The redirect binding uses raw DEFLATE — window bits -15, no header. The POST binding does not deflate at all. Guess wrong and you get garbage; try both.

SAML Raider (Burp extension) is the working environment: it intercepts the ACS POST, pretty-prints the XML, imports the IdP certificate, and drives the signature-wrapping attacks below with a single click. Install it before doing anything by hand.

samltool.com (SAMLtool by OneLogin) decodes and re-encodes messages and is useful for understanding structure — but treat it as offline reference only. Never paste a live production assertion into a third-party website; decode with the commands above instead.

Read these fields first, because they define every attack that follows:

• <ds:Signature> — where it sits and what its <ds:Reference URI="#..."> points to. This is the whole game.
• <saml:Subject><saml:NameID> — the identity being asserted
• <saml:AttributeStatement> — roles, groups, email, entitlements
• <saml:Conditions> — NotBefore, NotOnOrAfter, AudienceRestriction
• <saml:SubjectConfirmationData> — Recipient, NotOnOrAfter, InResponseTo
• Destination and Issuer on the response envelope

XML Signature Wrapping (XSW)

The core SAML attack. The signature is cryptographically valid, but you move the signed element somewhere the signature checker still accepts it while the application logic reads a different, unsigned assertion that you control. The verifier and the consumer disagree about which element is authoritative.

The eight canonical variants (Somorovsky et al.) differ in where the original signed assertion is relocated and where the forged one is injected:

• XSW1 / XSW2 — wrap the whole <Response>; the signature references the original response while a forged response is processed. XSW2 uses a non-enveloping signature position.
• XSW3 / XSW4 — assertion-level. XSW3 makes the forged assertion a sibling of the signed one; XSW4 nests the signed assertion inside the forged one. Same or overlapping IDs.
• XSW5 / XSW6 — the copied assertion envelopes the signature; play games with the ID attribute so the reference still resolves.
• XSW7 / XSW8 — hide in a loose-schema wrapper. XSW7 puts the forged assertion in an <Extensions> element; XSW8 buries the original signed one in an <Object> so it validates but is never consumed.

# Attack in SAML Raider:
#   1. Intercept the ACS POST, select the signed assertion
#   2. Edit NameID / attributes in the assertion the app will read
#   3. Click XSW1..XSW8 in turn — each rebuilds the document layout
#   4. Forward; watch for a successful login as the forged identity

Iterate through all eight. Which one works depends entirely on the SP's XML library and how it selects the assertion to trust — there is no way to predict it, so try every variant before concluding the SP is safe. A successful login as a NameID you never legitimately held is the finding.

Unsigned Assertions and Signature Stripping

Before the wrapping games, test the simplest failure: does the SP verify a signature at all?

• Strip the signature. Remove <ds:Signature> entirely and forward. Some SPs only verify a signature if one is present.
• Empty the signature. Blank the SignatureValue or DigestValue.
• Sign the wrong thing. Sign the response but not the assertion, or vice versa, when the SP only checks one.
• Downgrade the algorithm. Try SignatureMethod of SHA-1 or even md5/no-op where the SP does not pin the expected algorithm.

# xmlsec1 can tell you what a document's signature actually covers
xmlsec1 --verify --pubkey-cert-pem idp.crt --id-attr:ID Assertion response.xml

If the SP accepts a stripped or unsigned assertion, you can forge identity with no cryptography at all — the highest-severity SAML outcome.

Assertion Tampering

Once you can get an assertion accepted (stripped, unsigned, or via a working XSW variant), change what it claims:

• NameID — swap to a target user (admin@corp, another tenant's user)
• Attributes — flip Role/Group/memberOf to admin, add entitlement attributes the IdP never issued, change email to trigger account linking on the SP
• AudienceRestriction — if the SP does not check <Audience>, an assertion minted for another SP in the same federation is replayable here
• NotOnOrAfter / NotBefore — a wide or unchecked validity window lets you replay a captured assertion long after it should have expired
• InResponseTo — for the SP-initiated flow, whether the SP binds the response to its own AuthnRequest ID; if not, injected/replayed responses are accepted

Test each independently. An SP that validates the signature but ignores AudienceRestriction or the replay window is still fully exploitable.

Comment Injection in NameID

A canonicalization bug in several SAML libraries (the 2018 Duo/python-saml/ OneLogin class of CVEs). XML text-node handling and signature canonicalization disagree about how an XML comment splits a text node.

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

The signature is computed over the canonicalized value (which may drop the comment or concatenate the nodes), while the application's text extraction reads only the node before the comment — yielding admin. So a validly signed assertion for admin@evil.com (an account you legitimately own) authenticates you as admin. Try comments inside any identity-bearing field: NameID, and email/username attributes used for account mapping.