Home / Knowledge hub / SAML signature wrapping
Knowledge hub
SAML signature wrapping
Moving a signed SAML assertion so the app reads attacker-chosen content instead.
What it means
SAML signature wrapping is an attack on XML signatures. A SAML response carries a signed statement about who the user is. The attacker keeps the genuine signed part in the document, but adds a second, forged statement in a place the application will read.
The signature check passes, because the signed part is still there and unchanged. The app then reads the forged part. The check and the use refer to different pieces of the same document. It is an attack on the gap between checking a document and using it.
Why it matters
The impact is entry under someone else's identity, usually an administrator's. The attacker needs only one validly signed response, perhaps their own, to build a document that claims to be a different person. The result is an account takeover that leaves a normal-looking sign-in in the log.
It is also a flaw you inherit. Many teams use an open-source SAML library or a custom XML handler, and a weakness in how it finds and verifies the signed element becomes your weakness. It is well documented and still found, especially in older or hand-built integrations.
How it shows up
You meet it in any app that accepts SAML responses from a customer's identity provider. Use a maintained library, keep it updated and configure it to require that the assertion actually read is the signed one. Reject documents with more than one assertion or duplicate identifiers.
Mistakes repeat: verifying a signature found anywhere in the document, parsing the XML twice with different rules, and trusting a signature on the envelope but not the assertion. Testing means sending altered, wrapped documents and confirming the app refuses them. See SSO misconfiguration for the wider set of checks.
Questions people ask
SAML signature wrapping, answered
Why does the signature still verify after wrapping?
Because the signed element is unchanged. The attack leaves it in the document and adds a forged element elsewhere. Verification passes on the first, and the app reads the second.
How do we defend against it?
Use a maintained SAML library, require that the signed element is the exact one you read, reject documents with duplicate identifiers or multiple assertions, and validate the XML against the schema.
Is it a flaw in the SAML standard?
It is a class of implementation flaws arising from how XML signatures reference content. Careful implementations avoid it. The OWASP SAML cheat sheet lists it among the attacks to guard against.
Does using an identity provider protect us?
Only partly. The identity provider signs honestly. The flaw is in how your side validates the response, which is entirely yours. The identity provider cannot help here, because the weakness sits in the part of your code that reads the response.
How is it tested?
By submitting responses where the signed assertion is kept but a second assertion naming a different user is added or moved, then checking which one the app signs in. A correct app rejects them.
Related
Terms that sit next to this one
SAML
An older XML standard for single sign-on between a company and its apps.
SSO misconfiguration
A single sign-on setup that trusts the wrong issuer or accepts the wrong audience.
Digital signature
A value that proves who produced data and that it has not changed since.
Identity provider (IdP)
The service that signs people in and tells your app who they are.
Account takeover
An attacker ends up signed in as one of your real users.
Which assertion does your app read?
SAML handling is tested on the running app with altered responses, and in white-box mode a finding can point to the file and line that reads the wrong element. Each finding carries the request and response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.