CtrlK
BlogDocsLog inGet started
Tessl Logo

saml

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

61

Quality

72%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Critical

Do not install without reviewing

Fix and improve this skill with Tessl

tessl review fix ./packages/decepticon/decepticon/skills/standard/exploit/web/saml/SKILL.md
SKILL.md
Quality
Evals
Security

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>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

BugTypical
XSW variant accepted → arbitrary user impersonationCritical 9.8 (most enterprise SSO bounty)
Comment injection acceptedCritical 9.8
Signature stripping acceptedCritical 9.8
KeyInfo cert trustCritical 9.8
Replay window > 5 minHigh 7-8
Self-IdP misconfigCritical 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
Repository
PurpleAILAB/Decepticon
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.