At a health research data-access portal, a posted SAMLResponse verifies cleanly yet admits a cohort nobody approved — how does XML signature wrapping achieve that?

## The attack needs no key Signature wrapping is unusual among identity attacks because the attacker never touches cryptography. They need one thing: a document the identity provider genuinely signed, addressed to this service provider. Their own legitimate login supplies it. At a research data-access portal, that is an assertion saying they are a junior researcher with one approved cohort; what they want is an assertion saying they may open everything. They cannot edit the assertion — any edit changes the digest. So they do not edit it. They **move** it. ## The mechanism, step by step 1. Capture the valid `<samlp:Response>` containing `<saml:Assertion ID="_orig">` and its enveloped `<ds:Signature>`, whose single `<ds:Reference URI="#_orig">` digests it. 2. Relocate that whole signed assertion to a position the receiving application does not consume — inside `<samlp:Extensions>`, inside a `<saml:Advice>`, or inside a newly introduced wrapper element the receiver tolerates. 3. Build a forged `<saml:Assertion>`, typically a copy with a different `ID` and the attributes the attacker wants, and place it where the original was: the first assertion child of the `<samlp:Response>`. 4. Post the result. Now trace the receiver. The signature-verification step locates a `<ds:Signature>`, reads `URI="#_orig"`, and resolves that fragment **by searching the document for an element whose `ID` is `_orig`**. It finds the relocated original — unmodified, byte for byte after canonicalisation — computes the digest, matches it, checks `<ds:SignatureValue>` over `<ds:SignedInfo>` with the partner's key, and returns success. The application-logic step then asks the document a different question: *give me the assertion*. It answers with the element in the customary position, which is the forgery. | Step | Selects the element by | Which element it gets | |---|---|---| | Signature verification | `ID` lookup driven by the reference URI | The relocated, genuinely signed assertion | | Attribute consumption | Position in the tree | The forged assertion | **The defect is the gap between those two rows.** "The signature is valid" and "this data is signed" are different propositions, and the attack lives entirely in the space between them. ## Why the obvious objections do not stop it - **"The forged assertion is unsigned, so it will be rejected."** Only if something checks that the element consumed was the element verified. A receiver that asks "did the document verify?" and then parses the document afresh never makes that check. - **"Schema validation will reject the extra element."** Several of the classic placements are schema-valid — `<samlp:Extensions>` and `<saml:Advice>` exist precisely to carry additional content — and some receivers validate loosely once a signature has passed. - **"Encrypting the assertion prevents it."** Encryption changes who can read the document, not which element the receiver acts on after decrypting. - **"They would need the signing key."** They need no key. That is the point, and a candidate who answers "the identity provider's key must have leaked" has misread the whole class. - **"Duplicate IDs are illegal in XML."** They are — but `ID`-ness depends on the processor knowing the schema, and a document can be crafted so that the resolution a verifier performs and the traversal an application performs disagree about which element carries the identifier. ## The invariant Stated positively, the property a receiver needs is one sentence: **the element whose attributes are consumed must be the same element whose digest was verified** — not an element with the same name, not an element re-found by a second search over the document, the same one. Every failure in this class violates that sentence, and every interview question about wrapping is really asking whether the candidate can state it. How a particular service-provider implementation enforces it — which library, how the verified node is pinned, how assertion identifiers are remembered against replay — is an implementation subject and a different topic's ground. What belongs to the protocol is the reason the invariant is needed at all: XML Signature protects a subtree selected by reference, and an XML document is a tree in which subtrees can be moved without altering their bytes. ## What it costs when it lands At a data-access portal the assertion carries the entitlement, not just the identity — cohort scopes, consent classes, project membership. A wrapped response does not merely log someone in as somebody else; it hands them an authorisation decision the identity provider never made, and every downstream audit record shows a cleanly verified federated login. That is why this leaf is where SAML interviews get serious.