saml

# 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 ```bash # 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 ```xml <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): ```xml <Subject>victim@target.com<!-- foo -->.evil.com</Subject> ``` Some parsers see `victim@target.com`; others see `victim@target.com.evil.com`. 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