saml

name	saml
description	SAML 2.0 attacks — XSW (XML Signature Wrapping) variants 1-8, comment injection, signature stripping, assertion forgery, IdP metadata abuse.
metadata	{"when_to_use":"saml sso identity provider assertion signature xsw signedinfo","mitre_attack":"T1606.002","subdomain":"authentication","upstream_ref":"skills/_corpus/payloads/SAML Injection/"}

SAML Attack Playbook

SAML is XML-based SSO used heavily in enterprise. Signatures protect assertions but XML's structural flexibility creates many opportunities to confuse signature validators.

1. Capture the flow

# Identify SAML in recon — look for:
# - /SAML/login, /sso/saml, /saml2/login
# - Form param "SAMLRequest" or "SAMLResponse" (base64 + deflate)
# - SP metadata: /SAML/metadata, /sp/metadata.xml
# - IdP metadata: /idp/metadata.xml

# Decode a SAML message in Burp via the SAML Raider plugin
# Or manually
echo "$SAMLResponse_base64" | base64 -d | xmllint --format -

2. XML Signature Wrapping (XSW) attacks

The classic SAML bug class. 8 canonical variants. SAML Raider implements all of them.

XSW1: Wrap signed Assertion inside Response, add evil assertion

<Response>
  <ds:Signature>...</ds:Signature>  <!-- signs the inner Assertion -->
  <Assertion id="evil">
    <Subject>attacker</Subject>
    <AttributeStatement>...</AttributeStatement>
  </Assertion>
  <!-- original signed assertion moved into a deeper child or as sibling of evil -->
  <Assertion id="orig">
    <Subject>victim</Subject>
    ...
  </Assertion>
</Response>

Parser-checks-signature on orig (still valid). App-reads-claims from evil (first assertion). Bypass complete.

XSW2-8

Vary which element is signed, what gets added where, what gets renamed. Run all 8 via SAML Raider's automated XSW tester.

3. Comment injection

SAML libraries that strip XML comments BEFORE signature validation but the application reads the un-stripped version (or vice versa):

<Subject>[e-mail]<!-- foo -->.evil.com</Subject>

Some parsers see [e-mail]; others see [e-mail].

Famous: Cisco DUO + others in 2018 (CVE-2018-0489).

4. Signature stripping

Just delete the <ds:Signature> element. Some servers fail to enforce signature presence.

5. Self-signed assertion (when allowed by misconfig)

Some SPs accept assertions from any IdP listed in their trust store. If the trust store is overly broad, attacker stands up own IdP, generates own cert, IdP signs assertion claiming victim identity.

6. Bypass via SAMLResponse to SAMLRequest confusion

Both are base64'd + deflated XML. Some endpoints handle either. Sending an unsigned SAMLResponse when the endpoint expects a SAMLRequest may bypass auth.

7. Attribute injection via metadata

If SP fetches IdP metadata at runtime from a URL (not pinned), attacker who can poison/spoof that URL injects malicious metadata claiming attacker's IdP signs as victim's IdP.

8. Replay

Many SAML implementations don't track assertion IDs. Capture a victim's SAML response, replay it later. Mitigation: assertions have NotOnOrAfter

• unique ID; SPs should track recently-used IDs in a cache.

9. KeyInfo / certificate confusion

<ds:KeyInfo> can carry the cert inline. Attacker:

• Sends own cert in KeyInfo
• Signs assertion w/ corresponding private key
• Server validates against the cert in KeyInfo (instead of its trust store)

10. Tools

• SAML Raider (Burp plugin) — XSW1-8 automation, signature operations, message editing. Essential.
• samltool.com — XML pretty-print + base64 decode
• samlxss — quick XSS payload tester in SAML attributes
• Python saml2 — manual crafting via lxml

11. PoC pattern

1. Capture victim's SAMLResponse in Burp
2. Decode, identify Subject + AttributeStatement
3. Launch SAML Raider → "XSW Test" → cycle through all 8 variants, observe response
4. Any variant that returns logged-in-as-target = bug
5. If XSW fails, try comment injection: inject <!-- foo --> in claim values
6. If still fails, try signature stripping (delete <ds:Signature>)
7. Document the modified SAMLResponse + the resulting authenticated session as PoC

12. Severity calibration

Bug	Typical
XSW variant accepted → arbitrary user impersonation	Critical 9.8 (most enterprise SSO bounty)
Comment injection accepted	Critical 9.8
Signature stripping accepted	Critical 9.8
KeyInfo cert trust	Critical 9.8
Replay window > 5 min	High 7-8
Self-IdP misconfig	Critical 9.8

13. Defender remediation

• Use a battle-tested library (PySAML2, opensaml-cpp, OneLogin's SAML libs)
• Pin trusted IdPs by cert fingerprint, not URL
• Cache assertion IDs and reject replays
• Validate signature BEFORE comment-stripping (or after, but consistently)
• Reject responses w/o <ds:Signature>
• Never trust <ds:KeyInfo> content — match against pinned trust store

Cross-references

• Upstream catalog: skills/_corpus/payloads/SAML Injection/
• Web2 vuln class details (XSW1-8 mechanics): skills/_corpus/payloads/SAML Injection/Readme.md

Known exemplars

• CVE-2018-0489 (Cisco DUO comment injection)
• Multiple HackerOne $10-30k bounties for XSW in enterprise SSO
• "Duo's SAML Vulnerability" writeup (Duo Security blog)
• Onelogin / Okta historical issues — most modern enterprise IdPs have been hit at least once