Vulnarex | Elite Cybersecurity Learning Platform

#The Logic Flaw in XML Trust#link

SAML security relies on digital signatures. However, XML is a complex language that can be structured in many ways. XML Signature Wrapping (XSW) is an attack where the attacker modifies the identity of a user without invalidating the signature.

The Divergence: Verifier vs. Business Logic

XSW exploits a gap in how a SAML Service Provider (SP) processes an assertion. The 'Signature Verifier' checks one part of the XML, but the 'Business Logic' (the part that logs the user in) reads a different part.

callout

The attacker 'wraps' the original, signed assertion inside a new XML element and adds a fake, unsigned assertion with administrative privileges.

xml

<samlp:Response>
  <!-- The Verifier finds the signed block here and validates it -->
  <saml:Assertion ID="_legit_id">
    <saml:Subject>User: Guest</saml:Subject>
    <ds:Signature>...</ds:Signature>
  </saml:Assertion>

  <!-- The Application Logic reads the first Assertion it finds -->
  <saml:Assertion ID="_fake_id">
    <saml:Subject>User: Administrator</saml:Subject>
  </saml:Assertion>
</samlp:Response>

If the SP's code uses a generic method like `getElementsByTagName('Assertion')[0]` to identify the user, it will pick up the fake Administrator assertion, even though the signature it validated belonged to the Guest assertion.

Unrecognized block format segment:

info

💡 XSW is often detected by looking for multiple `<Assertion>` tags in a single SAML response, which is rarely necessary for legitimate traffic.

Analyzing a Captured SAML Response

root@vulnarex:~#grep -c "<saml:Assertion" capture.xml

The terminal output shows two assertions in one response. In a standard SSO flow, there is usually only one. This is a primary indicator of an XSW attempt.

Step	Attacker Action	Server Response
Capture	Intercept legit SAML assertion	None
Wrap	Add fake admin assertion to the XML	None
Submit	POST modified XML to SP	Signature is VALID (for legit block)
Access	User is logged in as Admin	Logic reads fake block

Defensive Implementation

STRICT SECURE AUDIT RULE

To prevent XSW, the SP must strictly tie the signature to the specific element being used for authentication.

▪Use a strict XPath to find the signed element
▪Verify that the signed element's ID matches the one used by the business logic
▪Reject any response containing multiple assertions
▪Validate the entire SAML Response signature, not just the Assertion signature

STRICT SECURE AUDIT RULE

Using generic XML libraries that 'flatten' the document before parsing is a common way XSW vulnerabilities are introduced.

quiz BLOCK (★ 50 XP)

Why does the signature not fail during an XSW attack?

Select your proof vectors above

challenge BLOCK (★ 100 XP)

The Logic Gap