Application security encompasses measures taken throughout the application's life-cycle to prevent exceptions in the security policy of an application or the underlying system (vulnerabilities) through flaws in the design, development, deployment, upgrade, or maintenance of the application.

Tuesday, August 14, 2012

SAML Compromised ! ! !

Security Assertion Markup Language (SAML) is an XML-based open standard for exchanging authentication and authorization data between security domains, that is, between an identity provider and a service provider.

In order to protect integrity and authenticity of the exchanged SAML assertions, the XML Signature standard is applied. But it seems from the 14 major SAML frameworks 11 (including Salesforce, Shibboleth, and IBM XS40) are vulnerable from critical XML Signature wrapping (XSW) vulnerabilities.

XML documents containing XML Signatures are typically processed in two independent steps: signature validation and function invocation (business logic). If both modules have different views on the data, a new class of vulnerabilities named XML Signature Wrapping attacks (XSW) exists. In these attacks the adversary modifies the message structure by injecting forged elements which do not invalidate the XML Signature. The goal of this alteration is to change the message in such a way that the application logic and the signature verification module use different parts of the message. Consequently, the receiver verifies the XML Signature successfully but the application logic processes the bogus element. The attacker thus circumvents the integrity protection and the origin authentication of the XML Signature and can inject arbitrary content. Figure below shows a simple XSW attack on a SOAP message.

XSW attacks resemble other classes of injection attacks like XSS or SQLi: in all cases, the attacker tries to force different views on the data in security modules (Ex. Web Application Firewalls) and data processing modules (HTML parser, SQL engine).

A simple XML Signature wrapping attack: The attacker moves the original signed content to a newly created Wrapper element. Afterwards, he creates an arbitrary content with a different Id, which is invoked by the business logic. For more details download the PDF from the this URL:


  1. If i understand correctly, the simple countermeasure is to use encrypted assertions. There, the signature reference ID attributes are not exposed and cannot be manipulated. Unfortunately, the XSW document doesn't really say anything about that, so I'm not sure if that assumption is correct or not.

  2. Hi,

    If you are talking about encryption using SSL mechanism, off course it will provide an extra layer of security but not full proof... Because attacker can use any kind of proxy tool, which are capable to do SSL negotiation. There are some other methods which will be helpful for mitigation like:-

    1. XML Schema validation: validate the whole response message against the applied SAML schemas.

    2. Order and position: order and position of signed and executed elements in the message tree can force the different processing modules to have inconsistent data views.

    3. Signature validation: all frameworks must have signature validation steps.

    4. Trusted signatures: It is essential to check that the signature was created with a trustworthy key.