SAML 2.0 attacks — XSW (XML Signature Wrapping) variants 1-8, comment injection, signature stripping, assertion forgery, IdP metadata abuse.
61
72%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
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.mdSAML is XML-based SSO used heavily in enterprise. Signatures protect assertions but XML's structural flexibility creates many opportunities to confuse signature validators.
# 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 -The classic SAML bug class. 8 canonical variants. SAML Raider implements all of them.
<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.
Vary which element is signed, what gets added where, what gets renamed. Run all 8 via SAML Raider's automated XSW tester.
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).
Just delete the <ds:Signature> element. Some servers fail to enforce
signature presence.
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.
SAMLResponse to SAMLRequest confusionBoth are base64'd + deflated XML. Some endpoints handle either. Sending an unsigned SAMLResponse when the endpoint expects a SAMLRequest may bypass auth.
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.
Many SAML implementations don't track assertion IDs. Capture a victim's
SAML response, replay it later. Mitigation: assertions have NotOnOrAfter
ID; SPs should track recently-used IDs in a cache.<ds:KeyInfo> can carry the cert inline. Attacker:
samltool.com — XML pretty-print + base64 decodesamlxss — quick XSS payload tester in SAML attributessaml2 — manual crafting via lxml<!-- foo --> in claim values<ds:Signature>)| 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 |
<ds:Signature><ds:KeyInfo> content — match against pinned trust storeskills/_corpus/payloads/SAML Injection/skills/_corpus/payloads/SAML Injection/Readme.md0cf691e
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.