# Saml

> SAML 2.0 attacks — XSW (XML Signature Wrapping) variants 1-8, comment injection, signature stripping, assertion forgery, IdP metadata abuse.

- Skill: `purpleailab/saml` (Agent Skill)
- Install (CLI): `npx skillmds@latest add purpleailab/saml`
- Raw SKILL.md: https://api.skillmd.com/api/skills/purpleailab/saml/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: purpleailab (https://skillmd.com/u/purpleailab)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/purpleailab/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