On Breaking SAML: Be Whoever You Want to Be

Juraj Somorovsky1, Andreas Mayer2, Jorg Schwenk1, Marco Kampmann1, and Meiko Jensen1

1Horst Gortz Institute for IT-Security, Ruhr-University Bochum, Germany2Adolf Wurth GmbH & Co. KG, Kunzelsau-Gaisbach, Germany

{Juraj.Somorovsky, Joerg.Schwenk, Marco.Kampmann, Meiko.Jensen}@rub.de,Andreas.Mayer@wuerth.com

AbstractThe Security Assertion Markup Language (SAML) is awidely adopted language for making security statementsabout subjects. It is a critical component for the develop-ment of federated identity deployments and Single Sign-On scenarios. In order to protect integrity and authentic-ity of the exchanged SAML assertions, the XML Signa-ture standard is applied. However, the signature verifica-tion algorithm is much more complex than in traditionalsignature formats like PKCS#7. The integrity protectioncan thus be successfully circumvented by application ofdifferent XML Signature specific attacks, under a weakadversarial model.

In this paper we describe an in-depth analysis of 14major SAML frameworks and show that 11 of them,including Salesforce, Shibboleth, and IBM XS40, havecritical XML Signature wrapping (XSW) vulnerabilities.Based on our analysis, we developed an automated pen-etration testing tool for XSW in SAML frameworks. Itsfeasibility was proven by additional discovery of a newXSW variant. We propose the first framework to an-alyze such attacks, which is based on the informationflow between two components of the Relying Party. Sur-prisingly, this analysis also yields efficient and practicalcountermeasures.

1 Introduction

The Security Assertion Markup Language (SAML) is anXML based language designed for making security state-ments about subjects. SAML assertions are used as se-curity tokens in WS-Security, and in REST based SingleSign-On (SSO) scenarios. SAML is supported by majorsoftware vendors and open source projects, and is widelydeployed. Due to its flexibility and broad support, newapplication scenarios are defined constantly.

SAML ASSERTIONS. Since SAML assertions con-tain security critical claims about a subject, the validityof these claims must be certified. According to the stan-

dard, this shall be achieved by using XML Signatures,which should either cover the complete SAML assertion,or an XML document containing it (e.g. a SAML Au-thentication response).

However, roughly 80% of the SAML frameworks thatwe evaluated could be broken by circumventing integrityprotection with novel XML Signature wrapping (XSW)attacks. This surprising result is mainly due to two facts:

• Complex Signing Algorithm: Previous digital sig-nature data formats like PKCS#7 and OpenPGPcompute a single hash of the whole document, andsignatures are simply appended to the document.The XML Signature standard is much more com-plex. Especially, the position of the signature andthe signed content is variable. Therefore, many per-mutations of the same XML document exist.• Unspecified internal interface: Most SAML

frameworks treat the Relying Party (i.e. the WebService or website consuming SAML assertions) asa single block, assuming a joint common state forall tasks. However, logically this block must be sub-divided into the signature verification module (latercalled RPsig) which performs a cryptographic opera-tion, and the SAML processing module (later calledRPclaims) which processes the claims contained inthe SAML assertion. Both modules have differentviews on the assertion, and they typically only ex-change a Boolean value about the validity of the sig-nature.

CONTRIBUTION. In this paper, we present an in-depth analysis of 14 SAML frameworks and systems.During this analysis, we found critical XSW vulnerabili-ties in 11 of these frameworks. This result is alarminggiven the importance of SAML in practice, especiallysince SSO frameworks may become a single point of at-tack. It clearly indicates that the security implicationsbehind SAML and XML Signature are not understoodyet.

Second, these vulnerabilities are exploitable by an at-tacker with far fewer resources than the classical networkbased attacker from cryptography: Our adversary maysucceed even if he does not control the network. He doesnot need realtime eavesdropping capabilities, but canwork with SAML assertions whose lifetime has expired.A single signed SAML assertion is sufficient to com-pletely compromise a SAML issuer/Identity Provider.Using SSL/TLS to encrypt SAML assertions, and thus toprevent adversaries from learning assertions by intercept-ing network traffic, does not help either: The adversarymay e.g. register as a regular customer at the SAML is-suer, and may use his own assertion to impersonate othercustomers.

Third, we give the first model for SAML frameworksthat takes into account the interface between RPsig andRPclaims. This model gives a clear definition of successfulattacks on SAML. Besides its theoretical interest, it alsoenables us to prove several positive results. These resultsare new and help to explain why some of the frameworkswere not vulnerable to our attacks, and to give advice onhow to improve the security of the other 11 frameworks.

Last, we show that XSW vulnerabilities constitute animportant and broad class of attack vectors. There is noeasy defense against XSW attacks: Contrary to commonbelief, even signing the whole document does not neces-sarily protect against them. To set up working defenses,a better understanding of this versatile attack class is re-quired. A specialized XSW pentesting tool developedduring our research will be released as open source to aidthis understanding. Its practicability was proven by dis-covering a new attack vector on Salesforce SAML inter-face despite the fact that specific countermeasures havebeen applied.

RESPONSIBLE DISCLOSURE. All vulnerabilitiesfound during our analysis were reported to the respon-sible security teams. Accordingly, in many cases, weclosely collaborated with them in order to patch thefound issues.

OUTLINE. The rest of the paper is organized as fol-lows. Section 2 gives a highlevel overview on SAML,and Section 3 adds details. The methodology of the in-vestigation is explained in Section 4, and the detailed re-sults are described in Section 5. In Section 6 we presentthe first fully automated XSW penetration test tool forSAML. Section 7 gives a formal analysis and derives twocountermeasures. In Section 8 we discuss their practi-cal feasibility. Section 9 presents an overview on relatedwork. In the last section we conclude and propose futureresearch directions.

ClientRelying Party(RP)

Identity Provider (IdP)

45

SAML ResponseTokenIssuing andSigning

Token Redirect

6

Token Response

7

Token Redirect

8

Signature validationToken evaluationUser authorization [SSL/TLS]

3Token

Request

1Login

Request

[SSL/TLS]

2SAML RequestTokenIssuing

Figure 1: A typical Single Sign-On scenario: The uservisits the RP, which generates a request token. He redi-rects this token to the IdP. The issued token is sent to theuser and forwarded to the RP. Even though the channelis secured by SSL/TLS, the user still can see the token.

2 Motivation

In this section we introduce two typical SAML scenariosand some widely used SAML frameworks.

SAML-BASED SINGLE SIGN-ON. Typical Internetusers have to manage many identities for different webapplications. To overcome this problem, Single Sign-Onwas developed. In this approach the users authenticateonly once to a trustworthy Identity Provider (IdP). Aftera successful login of a user, the IdP issues security to-kens on demand. These tokens are used to authenticateto Relying Parties (RP).

A simplified Single Sign-On scenario is depicted inFigure 1. In this setting, a user logged-in by the IdP firstvisits the desired RP (1). The RP issues a token request(2). This token is sent to the user (3) who forwards itto the IdP (4). The IdP issues a token response for theuser including several claims (e.g. his access rights orexpiration time). In order to protect the authenticity andintegrity of the claims, the token is signed (5). Subse-quently, the token is sent to the user (6), who forwards itto the RP (7). The RP validates the signature and after-wards grants access to the protected service or resource,if the user is authorized (8). This access control decisionis based on the claims in the validated token.

SECURING WEB SERVICES WITH SAML. Anothertypical application scenario is the use of SAML togetherwith WS-Security [29] in SOAP [21] to provide authen-tication and authorization mechanisms to Web Services.SAML assertions are included as security tokens in theSecurity header.

SAML PROVIDERS AND FRAMEWORKS. Theevaluation presented in this paper was made through-out the last 18 months and includes prominent and well-used SAML frameworks, which are summarized in Ta-ble 1. Our analysis included the IBM hardware appliance

Framework/Provider Type Language Reference ApplicationApache Axis 2 WS Java http://axis.apache.org WSO2 Web ServicesGuanxi Web SSO Java http://guanxi.sourceforge.net Sakai Project (www.sakaiproject.org)Higgins 1.x Web SSO Java www.eclipse.org/higgins Identity projectIBM XS40 WS XSLT www.ibm.com Enterprise XML Security GatewayJOSSO Web SSO Java www.josso.org Motorola, NEC, RedhatWIF Web SSO .NET http://msdn.microsoft.com Microsoft Sharepoint 2010OIOSAML Web SSO Java, .NET http://www.oiosaml.info Danish eGovernment (e.g. www.virk.dk)OpenAM Web SSO Java http://forgerock.com/openam.html Enterprise-Class Open Source SSOOneLogin Web SSO Java, PHP, Ruby, Python www.onelogin.com Joomla, Wordpress, SugarCRM, DrupalOpenAthens Web SSO Java, C++ www.openathens.net UK Federation (www.eduserv.org.uk)OpenSAML Web SSO Java, C++ http://opensaml.org Shibboleth, SuisseIDSalesforce Web SSO — www.salesforce.com Cloud Computing and CRMSimpleSAMLphp Web SSO PHP http://simplesamlphp.org Danish e-ID Federation (www.wayf.dk)WSO2 Web SSO Java www.wso2.com eBay, Deutsche Bank, HP

Table 1: Analyzed SAML frameworks and providers: The columns give information about type (Web Service orBrowser-based SSO), programming language (if known), web site, and application in concrete products or frameworks.

XS40, which is applied as an XML Security Gateway.Other examples of closed source frameworks are theWindows Identity Foundation (WIF) used in MicrosoftSharepoint and the Salesforce cloud platform. Importantopen source frameworks include OpenSAML, OpenAM,OIOSAML, OneLogin, and Apache Axis 2. OpenSAMLis for example used in Shibboleth and the SDK of theelectronic identity card from Switzerland (SuisseID).OpenAM, formerly known as SUN OpenSSO, is an iden-tity and access management middleware, used in majorenterprises. The OIOSAML framework is e.g. used inDanish public sector federations (e.g. eGovernment busi-ness and citizen portals). The OneLogin Toolkits inte-grate SAML into various popular open source web appli-cations like Wordpress, Joomla, Drupal, and SugarCRM.Moreover, these Toolkits are used by many OneLogincustomers (e.g. Zendesk, Riskonnect, Zoho, Knowl-edgeTree, and Yammer) to enable SAML-based SSO.Apache Axis2 is the standard framework for generatingand deploying Web Service applications.

3 Technical Foundations

In this section we briefly introduce the SAML standardand XML Signature wrapping attacks. Additionally, forreaders unfamiliar with the relevant W3C standards, wepresent XML Signature [14] and XML Schema [36].

3.1 XML Signature

The XML Signature standard [14] defines the syntax andprocessing rules for creating, representing, and verifyingXML-based digital signatures. It is possible to sign awhole XML tree or only specific elements. One XMLSignature can cover several local or global resources.A signature placed within the signed content is calledan enveloped signature. If the signature surrounds thesigned parts, it is an enveloping signature. A detachedsignature is neither inside nor a parent of the signed data.

<Signature ID?><SignedInfo>

<CanonicalizationMethod/><SignatureMethod/>(<Reference URI? >

(<Transforms>)?<DigestMethod><DigestValue>

</Reference>)+</SignedInfo><SignatureValue>(<KeyInfo>)?(<Object ID?>)*

</Signature>

Figure 2: XML Signature data structure (”?”: zero or oneoccurrence; ”+”: one or more occurrences; ”*”: zero ormore occurrences).

An XML Signature is represented by the Signature

element. Figure 2 provides its basic structure. XMLSignatures are two-pass signatures: the hash value ofthe resource (DigestValue) along with the used hashalgorithm (DigestMethod) and the URI reference tothe resource are stored in a Reference element. Ad-ditionally, the Transforms element specifies the pro-cessing steps which are applied prior to digesting ofthe resource. Each signed resource is represented bya Reference element in the SignedInfo element.Therefore, SignedInfo is a collection of hash val-ues and URIs. The SignedInfo itself is protectedby the signature. The CanonicalizationMethod andthe SignatureMethod element specify the algorithmsused for canonicalization and signature creation, and arealso embedded in SignedInfo. The Base64-encodedvalue of the computed signature is deposited in theSignatureValue element. In addition, the KeyInfo el-ement facilitates the transport of signature relevant keymanagement information. The Object is an optional el-ement that may contain any data.

<saml:Assertion Version ID IssueInstant><saml:Issuer><ds:Signature>?<saml:Subject>?<saml:Conditions>?<saml:Advice>?<saml:AuthnStatement>*<saml:AuthzDecisionStatement>*<saml:AttributeStatement>*

</saml:Assertion>

Figure 3: SAML assertion structure.

3.2 XML SchemaThe W3C recommendation XML Schema [36] is a lan-guage to describe the layout, semantics, and content ofan XML document. A document is deemed to be valid,when it conforms to a specific schema. A schema con-sists of a content model, a vocabulary, and the used datatypes. The content model describes the document struc-ture and the relationship of the items. The standard pro-vides 19 primitive data types to define the allowed con-tent of the elements and attributes.

Regarding to our evaluation of SAML based XMLSignature Wrapping attacks there is one important el-ement definition in XML Schema. The any elementallows the usage of any well-formed XML documentin a declared content type. When an XML processorvalidates an element defined by an any element, theprocessContents attribute specifies the level of flex-ibility. The value lax instructs the schema validator tocheck against the given namespace. If no schema infor-mation is available, the content is considered valid. In thecase of processContents="skip" the XML processordoes not validate the element at all.

3.3 SAMLSAML is an XML standard for exchanging authentica-tion and authorization statements about Subjects [11].Several profiles are defined in [10]. The most importantprofile is the Browser SSO profile, which defines how touse SAML with a web browser.

A SAML assertion has the structure described in Fig-ure 3. The issuing time of the assertion is specified insaml:IssueInstant. All attributes are required.

The saml:Issuer element specifies the SAML au-thority (the IdP) that is making the claim(s) in the asser-tion. The assertion’s saml:Subject defines the princi-pal about whom all statements within the assertion aremade. The saml:*Statement elements are used tospecify user-defined statements relevant for the contextof the SAML assertion.

To protect the integrity of the security claims madeby the Issuer, the whole saml:Assertion element mustbe protected with a digital signature following the XML

Signed

Processed

Envelope

Assertion

Header

ID=“123“

Signature

SignedInfo

Reference URI=“#123“

Response

Assertion

Signature

SignedInfo

Reference URI=“#123“

ID=“123“

Body

Binding root element R

Figure 4: SAML message examples (SOAP and REST):The SAML assertion is put into a root element R andsigned using an enveloped signature. When signing theSOAP body, an additional detached signature is used.

Signature standard. Therefore, the SAML specifica-tion [11] requires that either the saml:Assertion ele-ment or an ancestor element must be referenced by theSignature element, with an enveloped XML Signature([11], Section 5.4.1). Furthermore, Id-based referencingmust be used ([11], Section 5.4.2), which opens the wayfor XSW attacks.

In REST based frameworks, the SAML assertion istypically put into an enveloping Response element.Frameworks applying SOAP insert the SAML assertionsinto the SOAP header (or the Security element in-side of the SOAP header). For clarification purposes,consider that the SAML assertions are signed using en-veloped XML Signatures and are put into some bindingroot element R (see Figure 4).

3.4 XML Signature Wrapping Attacks

XML documents containing XML Signatures are typi-cally processed in two independent steps: signature val-idation and function invocation (business logic). If bothmodules have different views on the data, a new class ofvulnerabilities named XML Signature Wrapping attacks(XSW) [27, 23] exists. In these attacks the adversarymodifies the message structure by injecting forged ele-ments which do not invalidate the XML Signature. Thegoal of this alteration is to change the message in sucha way that the application logic and the signature verifi-cation module use different parts of the message. Con-sequently, the receiver verifies the XML Signature suc-cessfully but the application logic processes the boguselement. The attacker thus circumvents the integrity pro-tection and the origin authentication of the XML Signa-ture and can inject arbitrary content. Figure 5 shows asimple XSW attack on a SOAP message.

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

Signed

Processed

Envelope

Wrapper

Header

ID=“123“

Signature

SignedInfo

Reference URI=“#123“

Body

Body

CreateKeyPair

MonitorInstances

ID=“attack“

Figure 5: A simple XML Signature wrapping attack: Theattacker moves the original signed content to a newly cre-ated Wrapper element. Afterwards, he creates an arbi-trary content with a different Id, which is invoked by thebusiness logic.

4 XSW Attacks on SAML

In this section we first characterize the assumed threatmodel. Second, we describe the basic attack principlethat underlies our analysis of the 14 frameworks.1

4.1 Threat ModelAs a prerequisite the attacker requires an arbitrary signedSAML message. This could be a single assertion A or awhole document D with an embedded assertion, and itslifetime can be expired. After obtaining such a message,the attacker modifies it by injecting evil content, e.g. anevil assertion EA. In our model we assume two differ-ent types of adversaries, which are both weaker than theclassical network based attacker:

1. Advacc. To obtain an assertion, this attacker regis-ters as a user of an Identity Provider IdP. Advaccthen receives, through normal interaction with IdP,a valid signed SAML assertion A (probably as apart of a larger document D) making claims aboutAdvacc. The attacker now adds additional claims EAabout any other subject S, and submits the modifieddocument D′ (A′) to RP.

2. Advintc. This adversary retrieves SAML assertionsfrom the Internet, but he does not have the abil-ity to read encrypted network traffic. This canbe done either by accessing transmitted data di-rectly from unprotected networks (sniffing), or inan ”offline” manner by analyzing proxy or browsercaches. Since SAML assertions should be worthlessonce their lifetime expired, they may even be posted

1Please note that from now on we distinguish between the documentD and the root element R. This is to make clear the distinction betweenthe element referenced by the XML signature, and the document root:Even if the root element R of the original document D is signed, wemay transform this into a new document D′ with a new evil root ER,without invalidating the signature.

A1 S1 EA

A1 S1R ER EA

A1 SR S1 ER EA

Legitimate content Injected evil contentSigned

Processed

Signing Type 1)

Signing Type 2)

Signing Type 3)

Figure 6: Types of signature applications on SAML as-sertions on the left. The new malicious content neededto execute the attacks depicted on the right, accordingly.

in technical discussion boards, where Advintcmayaccess them.

4.2 Basic Attack PrincipleAs described in the previous section, XML Signaturescan be applied to SAML assertions in different ways andplaced in different elements. The only prerequisite is thatthe Assertion element or the protocol binding element(ancestor of Assertion) is signed using an envelopedsignature with Id-based referencing. In this section weanalyze the usage of SAML assertions in different frame-works and the possibilities of inserting malicious con-tent. Generally, SAML assertions and their signaturesare implemented as depicted in Figure 6:

1. The first possible usage of signatures in SAML as-sertions is to insert the XML Signature S1 as achild of the SAML assertion A1 and sign only theAssertion element A1. This type can be used in-dependently of the underlying protocol (SOAP orREST).

2. The second type of signature application in SAMLsigns the whole protocol binding element R. TheXML Signature can be placed into the SAML asser-tion A1 or directly into the protocol binding root ele-ment R. This kind of signature application is used indifferent SAML HTTP bindings, where the wholeResponse element is signed.

3. It is also possible to use more than one XML Sig-nature. The third example shows this kind of signa-ture application: the inner signature S1 protects theSAML assertion and the outer signature S addition-ally secures the whole protocol message. This kindof signature application is e.g. used by the Simple-SAMLphp framework.

In order to apply XSW attacks to SAML assertions,the basic attack idea stays the same: The attacker has

to create new malicious elements and force the assertionlogic to process them, whereas the signature verificationlogic verifies the integrity and authenticity of the originalcontent. In applications of the first signature type, theattacker only has to create a new evil assertion EA. In thesecond and third signing types, he also has to create thewhole evil root ER element including the evil assertion.

4.3 Attack Permutations

The attacker has many different possibilities where to in-sert the malicious and the original content. To this end,he has to deal with these questions:

• At which level in the XML message tree should themalicious content and the original signed data beincluded?• Which Assertion element is processed by the as-

sertion logic?• Which element is used for signature verification?

By answering these questions we can define differentattack patterns, where the original and the malicious el-ements can be permuted (Figure 7). We thus get a com-plete list of attack vectors, which served as a guidelinefor our investigations.

For the following explanations we only consider sign-ing type 1) defined in Figure 6. In this signing type onlythe Assertion element is referenced.

The attack permutations are depicted in Figure 7. Inaddition, we analyze their SAML standard conformanceand the signature validity:

1. Malicious assertion, original assertion, and signa-ture are left on the same message level: This kind ofXML message can have six permutations. None ofthem is SAML standard compliant, since the XMLSignature does not sign its parent element. The di-gest value over the signed elements in all the mes-sages can be correctly validated. We can use thistype of attack messages if the server does not checkthe SAML conformance.

2. All the three elements are inserted at different mes-sage levels, as child elements of each other, whichagain results in six permutations: Messages 2-a and2-b show examples of SAML standard conform-ing and cryptographically valid messages. In bothcases the signature element references its parent –the original assertion A1. Message 2-c illustrates amessage which is not SAML standard conform asthe signature signs its child element. Nevertheless,the message is cryptographically valid. Lastly, mes-sage 2-d shows an example of an invalid messagesince the signature would be verified over both as-sertions. Generally, if the signature is inserted as the

A1 S1EA

R

A1

S1

EA

R

A1

S1

EA

R

2) Three Levels (6 Permutations)

3) Two Levels (12 Permutations)

A1

S1

EA

R

A1

S1

EA

R

A1

S1

EA

R

A1

S1

EA

R

1) One Level (6 Permutations) Signed

Processed

Signature Invalid

not SAML-conform

a) b) c) d)

a) b)

EA S1A1

R

EA

S1

A1

R

c)

EA

S1

A1

R

d)

SAML-conform

Figure 7: Possible variants for XSW attacks applied onmessages with one signed SAML assertion divided ac-cording to the insertion depth of the evil assertion EA,the original assertion A1 and the signature S1. The var-ious permutations are labeled according to their validityand SAML-conformance.

child of the root element, the message would also beeither invalid or not SAML standard compliant.

3. For the insertion of these three elements we use twomessage levels: Message 3-a shows an example ofa valid and SAML compliant document. By con-structing message 3-b, the signature element wasmoved to the new malicious assertion. Since it ref-erences the original element, it is still valid, but doesnot conform to the SAML standard.

The analysis shown above can similarly be applied tomessages with different signing types (see Figure 6).

5 Practical Evaluation

We evaluated the above defined attacks on real-worldsystems and frameworks introduced in Section 2. In thissection we present the results.

5.1 Signature Exclusion AttacksWe start the presentation of our results with the simplestattack type called Signature exclusion attack. This at-tack relies on poor implementation of a server’s securitylogic, which checks the signature validity only if the sig-nature is included. If the security logic does not find theSignature element, it simply skips the validation step.

Root

Assertion ID=“evil“

Assertion ID=“123“

Signature

SignedInfo

Reference URI=“#123“

Root

Assertion ID=“evil“

Assertion ID=“123“

Signature

SignedInfo

Reference URI=“#123“

Root

Assertion ID=“evil“

Assertion ID=“123“

Signature

SignedInfo

Reference URI=“#123“

Signed

ProcessedRoot

Assertion ID=“evil“

Assertion ID=“123“

Signature

SignedInfo

Reference URI=“#123“

OIOSAMLHiggins, Apache Axis2, IBM XS 40 Security Gateway OpenAM, Salesforce

Figure 8: XML tree-based illustration of refined XSW attacks found in Type 1 signature applications.

The evaluation showed that three SAML-based frame-works were vulnerable to these attacks: Apache Axis2Web Services Framework, JOSSO, and the Java-basedimplementation of SAML 2.0 in Eduserv (other versionsof SAML and the C-implementation in Eduserv were notaffected).

By applying this attack on JOSSO and Eduserv the at-tacker had to remove the Signature element from themessage, since if it was found, the framework tried tovalidate it. On the other hand, the Apache Axis2 frame-work did not validate the Signature element over theSAML assertion at all, even if it was included in the mes-sage. Apache Axis2 validated only the signature over theSOAP body and the Timestamp element. The signatureprotecting the SAML assertion, which is included sep-arately in the Assertion element, was completely ig-nored.

5.2 Refined Signature WrappingTen out of 14 systems were prone to refined XSW at-tacks.

Classified on the three different signature applicationtypes given in Figure 6, five SAML-based systems failedin validating Type 1 messages, where only the asser-tion is protected by an XML Signature. Figure 8 depictsthe XML tree-based illustration of the found XSW vari-ants. Starting from left to right, Higgins, Apache Axis2,and the IBM XS 40 Security Gateway were outfoxedby the two depicted permutations. In the first variantit was sufficient to inject an evil assertion with a dif-ferent Id attribute in front of the original assertion. Asthe SAML standard allows to have multiple assertions inone protocol element, the XML Schema validation stillsucceeded. The second attack type embedded the orig-inal assertion as a child element into the evil assertionEA. In both cases the XML Signature was still standardconform, as enveloped signatures were applied. Thiswas broken in the case of OIOSAML by using detachedsignatures. In this variant the original Signature ele-ment was moved into the EA, which was inserted be-fore the legitimate assertion. The last shown permuta-tion was applicable to the cloud services of Salesforce

Root

Assertion

Root ID=“123“

Signature

SignedInfo

Reference URI=“#123“

ID=“evil“

Assertion

Root

Assertion

Root ID=“123“

Signature

SignedInfo

Reference URI=“#123“

ID=“evil“

Assertion

Guanxi, JOSSO WSO2

Figure 9: XML tree-based illustration of refined XSWattacks found in Type 2 signature applications.

and the OpenAM framework. At this, the genuine asser-tion was placed into the original Signature element. Asboth implementations apply XML Schema for validatingthe schema conformance of a SAML message, this wasdone by injecting them into the Object element, whichallows arbitrary content. Again, this is not compliantto the SAML standard because this mutation transformsthe enveloped to an enveloping signature. Finally, theOneLogin Toolkits were prone to all shown attack vari-ants as they did not apply XML Schema, validated theXML Signature independent of it’s semantic occurrenceand used a fixed reference to the processed SAML claims(/samlp:Response/saml:Assertion[1]).

We found three susceptible implementations, whichapplied Type 2 messages, where the whole message isprotected by an XML Signature. We depict the attackson these implementations in Figure 9. In the Guanxiand JOSSO implementations the legitimate root elementwas inserted into the Object element in the originalSignature. The Signature node was moved into theER element which also included the new evil assertion.In the case of WSO2, it was sufficient to place the orig-inal root element into the ER object. Naturally, some-one would expect that enforcing full document signingwould eliminate XSW completely. The both given ex-amples demonstrate that this does not hold in practice.Again, this highlights the vigilance required when im-plementing complex standards such as SAML.

Finally, we did not find vulnerable frameworks thatapplied Type 3 messages, where both the root and the as-

sertion are protected by different signatures. Indeed, onelegitimate reason is, that most SAML implementationsdo not use Type 3 messages. In our practical evaluation,only SimpleSAMLphp applied them by default. Never-theless, this does not mean that XSW is not applicable tothis message type in practice.

5.3 OpenSAML VulnerabilityThe attack vectors described above did not work againstthe prevalently deployed OpenSAML library. The reasonwas that OpenSAML compared the Id used by the signa-ture validation with the Id of the processed assertion. Ifthese identifiers were different (based on a string compar-ison), the signature validation failed. Additionally, XMLmessages including more than one element with the sameId were also rejected. Both mechanisms are handled inOpenSAML by using the Apache Xerces library and itsXML Schema validation method [34]. Nevertheless, itwas possible to overcome these countermeasures with amore sophisticated XSW attack.

As mentioned before, in OpenSAML the ApacheXerces library performs a schema validation of every in-coming XML message. Therefore, the Id of each el-ement can be defined by using the appropriate XMLSchema file. This allows the Xerces library to iden-tify all included Ids and to reject messages with Id

values which are not unique (e.g. duplicated). How-ever, a bug in this library caused that XML elementsdefined with xsd:any content were not processed cor-rectly. More concretely, the content of the elementsdefined as <xsd:any processContents="lax"> werenot checked using the defined XML Schema. Therefore,it was possible to insert elements with arbitrary – alsoduplicated – Ids inside an XML message. This created agood position for our wrapped content.

It is still the question which of the extensible elementscould be used for the execution of our attacks. This de-pends on two processing properties:

1. Which element is used for assertion processing?2. Which element is validated by the security module,

if there are two elements with the same Id?

Interestingly, the two existing implementations ofApache Xerces (Java and C++) handled element deref-erencing differently.

For C++, the attacker had to ensure that the originalsigned assertion was copied before the evil assertion. Inthe Java case, the legitimate assertion had to be placedwithin or after the evil assertion. In summary, if twoelements with the same Id values occurred in an XMLmessage, the XML security library detected only the first(for C++) or the last (for Java) element in the message.This property gave the attacker an opportunity to use

Signed

ProcessedResponse

Assertion

Extensions

Assertion

C++ Java

Signature

SignedInfo

Reference URI=“#123“

ID=“123“

Response

Assertion

Assertion

Signature

SignedInfo

Reference URI=“#123“

ID=“123“

ID=“123“

ID=“123“

Object

Figure 10: XSW attack on OpenSAML library.

<element name="Extensions" type="samlp:ExtensionsType"/><complexType name="ExtensionsType">

<sequence><any namespace="##other" processContents="lax"

maxOccurs="unbounded"/></sequence>

</complexType>

Figure 11: XML Schema definition of the Extensions

element.

e.g. the Extensions element for the C++ library, whoseXML Schema is defined in Figure 11. However, theExtensions element is not the only possible position forour wrapped content. The schemas of SAML and XMLSignature allow more locations (e.g. the Object elementof the Signature, or the SubjectConfirmationData

and Advice elements of the Assertion).The previously described behavior of the XML

schema validation forced OpenSAML to use the wrappedoriginal assertion for signature validation. In contrast,the application logic processed the claims of the evil as-sertion. In Figure 10, we present the concrete attack mes-sages of this novel XSW variant.

The successful attack on OpenSAML shows that coun-tering the XSW attack can become more complicatedthan expected. Even when applying several countermea-sures, the developer should still consider vulnerabilitiesin the underlying libraries. Namely, one vulnerability inthe XML Schema validating library can lead to the exe-cution of a successful XSW attack.

5.4 Various Implementation Flaws

While reviewing the OneLogin Toolkit, we discoveredanother interesting flaw: the implementation did not careabout what data was actually signed. Therefore, any con-tent signed by the IdP was sufficient to launch a XSWattack. In our case we used the metadata of the IdP 2 andcreated our own self-made response message to success-fully attack OneLogin.

2The SAML Metadata [12] describes properties of SAML entitiesin XML to allow the easy establishment of federations. Typically, themetadata is signed by the issuer and publicly available.

Besides the fact that a SAML system has to checkwhat data is signed, it is also essential to verify by whomthe signature was created. In an early version of Sim-pleSAMLphp, which applied Type 3 messages, we ob-served that an attacker could forge the outer signature ofthe response message with any arbitrary key. In short,the SimpleSAMLphp RP did not verify if the includedcertificate in the KeyInfo element is trustworthy at all.The key evaluation for the signed assertion was correctlyhandled.

5.5 Secure FrameworksIn our evaluation of real-world SAML implementationswe observed that Microsoft Sharepoint 2010 and Simple-SAMLphp were resistant to all applied test cases. Basedon these findings the following questions arise: Howdo these systems implement signature validation? Inwhich way do signature validation and assertion process-ing work together? Due to the fact that the source code ofSharepoint 2010 is not publicly available, we were onlyable to analyze SimpleSAMLphp.

According to this investigation the main signaturevalidation and claims processing algorithm of Simple-SAMLphp performs the following five steps to counter-act XSW attacks:

1. XML Schema validation: First, the whole re-sponse message is validated against the appliedSAML schemas.

2. Extract assertions: All included assertions are ex-tracted. Each assertion is saved as a DOM tree ina separate variable. The following steps are onlyapplied on these segregated assertions.

3. Verify what is signed: SimpleSAMLphp checks, ifeach assertion is protected by an enveloped signa-ture. In short, the XML node addressed by the URIattribute of the Reference element is compared tothe root element of the same assertion. The XMLSignature in the assertion is an enveloped signatureif and only if both objects are identical.

4. Validate signature: The verification of every en-veloped signature is exclusively done on the DOMtree of each corresponding assertion.

5. Assertion processing: The subsequent assertionprocessing is solely done with the extracted and suc-cessfully validated assertions.

When not considering the signature exclusion bugfound in the OpenAthens implementation and its Java-based assertions’ processing, this framework was alsoresistant to all the described attacks. The analysis of itsimplementation showed that it processes SAML asser-tions similarly to the above described SimpleSAMLphpframework.

Frameworks / Providers Sign

ing

type

Sign

atur

eex

clus

ion

Refi

ned

XSW

Soph

istic

ated

XSW

Not

vuln

erab

le

Apache Axis 2 1) X XGuanxi 2) XHiggins 1.x 1) XIBM XS40 1) XJOSSO 2) X XWIF 1) XOIOSAML 1) XOpenAM 1) XOneLogin 1) XOpenAthens 1) XOpenSAML 1) XSalesforce 1) XSimpleSAMLphp 3) XWSO2 2) X

Table 2: Results of our practical evaluation show that amajority of the analyzed frameworks were vulnerable tothe refined wrapping techniques.

5.6 SummaryWe evaluated 14 different SAML-based systems. Wefound 11 of them susceptible to XSW attacks, while themajority were prone to refined XSW. One prevalentlyused framework (OpenSAML) was receptive to a new,more subtle, variant of this attack vector. In addition,three out of the tested frameworks were vulnerable toSignature Exclusion attacks. We found two implemen-tations, which were resistant against all test cases. Theresults obtained from our analysis are summarized in Ta-ble 2.

6 XSW Penetration Test Tool for SAML

Motivated on our crucial findings from the extensiveframeworks’ analysis and the vast amount of possibleattack permutations, we implemented the first fully au-tomated penetration test tool for XSW attacks in SAML-based frameworks. In this section we briefly describethe basic design decisions for our tool. Afterwards, wemotivate its usage by revisiting the Salesforce SAML in-terface. This interface yielded a new possibility for aninteresting XSW attack even after a deep investigationwith different handcrafted messages.

Our tool will be integrated into the WS-Attackerframework3 and offered as open source to support thehuge Web Services and SSO developers’ community.

6.1 Penetration Test ToolAccording to the theoretical and practical analysis of dif-ferent SAML frameworks (see Section 4, 5), we gainedthe following general knowledge about XSW attacks:

3http://ws-attacker.sourceforge.net

• XML Schema validation: Some of the SAMLframeworks check message conformance to the un-derlying XML schema. Therefore, it is necessary touse XML schema extension points for placing thewrapped content. If the extension elements are notprovided in the message, they have to be explicitlyincluded.• Order and position: The order and position of

signed and executed elements in the message treecan force the different processing modules to haveinconsistent data views.• Processing of the Ids: Several SAML frameworks

explicitly check, if the Id in the handled assertionis also used in the Reference of the XML Signa-ture. Application of this countermeasure alone doesnot work, as there is still the option to use more el-ements with equal Ids.• Placement of the Signature element: TheSignature element can be placed in the newly cre-ated evil assertion or stay in the original assertion(cf. the attacks on Higgins, Apache Axis2 and IBMXS40 in Figure 8). Both cases must be considered.• Signature exclusion: In three out of 14 frameworks

implementation bugs caused that the signature vali-dation step was omitted.• Untrusted signatures: It is essential to check that

the signature was created with a trustworthy key.Otherwise, the attacker can forge a signature withany arbitrary key and embed the corresponding cer-tificate in the KeyInfo element.

Based on this knowledge, we developed a library,which allows the systematic creation of a vast amountof different SAML attack vectors. Its processing canbe summarized in the following steps. First, the librarytakes a signed XML document containing a SAML as-sertion and analyzes the usage of XML Signature. Theelement referenced by the signature is stored as a string.Subsequently, it creates a new malicious message includ-ing an evil assertion with modified content (e.g. theNameID and/or Timestamp element). Then, it searchesdynamically for extension points in the XML Schemadocuments (e.g. XML Schemas for SAML, HTTP bind-ing, XML Signature, or SOAP). It places the extensionelements into the malicious message (e.g. a new Object

element is created and placed into the given Signature

element). Afterwards, the library embeds the stored orig-inal referenced element into each of the possible mali-cious message elements. For each position, a combina-tion of different attack vectors – considering changes inthe Ids of the newly created elements and the positionsof the Signature elements – are created. For complete-ness, test cases for signature exclusion and untrusted sig-natures are provided. With these attack vectors, develop-

Signed

Processed

Response

Assertion

Assertion

Signature

SignedInfo

Reference URI=“#123“

ID=“123“

ID=“123“

Audience

saml.salesforce.com

Figure 12: A successful XSW attack performed againstthe patched Salesforce SAML interface.

ers can systematically test the security of their (newly)developed SAML libraries.

6.2 Salesforce SAML Interface Revisited

After reporting the XSW vulnerability to Salesforce, thesecurity response team developed a simple and promis-ing countermeasure: the SAML interface solely acceptedmessages containing one Assertion element4. On re-quest of the Salesforce security team, we investigatedthe fixed SAML interface with handcrafted messagescontaining wrapped contents in different elements. Ourmanual analysis did not reveal any new attack vectors.Every message containing more than one Assertion el-ement was automatically rejected. Therefore, we firstconsidered this interface to be secure.

A few months later, after finishing the development ofour penetration test tool, we decided to retest the Sales-force SAML interface and prove the feasibility of our ap-proach. Surprisingly, the automated penetration test toolrevealed a new successful attack variant by inserting thewrapped content into the Audience element – a descen-dant of the Conditions element. This element typicallycontains a URI constraining the parties that can consumethe issued assertion. The wrapped message is depicted inFigure 12. As can be seen in the figure, both Assertion

elements needed to contain the same Id attribute.This scientifically interesting attack vector stayed un-

analyzed as the Salesforce security team did not exposeany concrete information about their SAML interface.However, this finding shows how complex the develop-ment of secure signature wrapping countermeasures is.This motivates for further development of automatic pen-etration test tools for XSW.

Salesforce security team afterwards implemented acountermeasure, which could successfully mitigate allour attack types. Its details were not revealed.

4This countermeasure is not standard-conform as one message cangenerally contain several assertions. Therefore, we do not consider thisremedy in our countermeasure analysis in Section 7.

IdP1

IdP2

IdP3

Advacc

Advintc

RPsig RPclaims RPwork

Figure 13: Overview of the components in our formalmodel.

7 Analysis and Countermeasures

In order to define what a successful attack on a SAMLimplementation is, we have to define the possibilities ofthe adversary, and the event that characterizes a success-ful attack. We do this in form of a game played betweenthe adversary on one side, and IdP and RP on the otherside. Additionally, we derive two different countermea-sures. Their practical application is described in Sec-tion 8.

7.1 Data Model

A SAML assertion A can be sent to a Relying Party RPeither as a stand-alone XML document, or as part of alarger document D. (D may be a complete SOAP mes-sage, or a SAML Authentication response.) To processthe SAML assertion(s), the Relying Party (more specifi-cally, RPclaims) searches for the Assertion element andparses it. We assume that A is signed, either stand-alone,or as part of D.

7.2 Identity Provider Model

We define an Identity Provider IdP to be an entity that is-sues signed SAML assertions, and that has control overa single private key for signing. Thus, companies likeSalesforce may operate several IdPs, one for each do-main of customers.

An Identity Provider IdP operates a customer databasedbIdP and is able to perform a secure authenticationprotocol with any customer contained in this database.Furthermore, he has control over a private signing key,where the corresponding public key is trusted by a set ofRelying Parties RP := {RP1, . . . ,RPn}, either directly,or through means of a Public Key Infrastructure. Afterreceiving a request from one of the customers registeredin dbIdP, and after successful authentication, he may is-sue a signed XML document D, where the signed partcontains the requested SAML assertion A.

7.3 Relying Party ModelWe assume that processing of documents containingSAML assertions is split into two parts: (1) XML Sig-nature verification RPsig, and (2) SAML security claimsprocessing RPclaims (see Figure 13). This assumption isjustified since both parts differ in their algorithmic base,and because this separation was found in all frameworks.If RPclaims accepts, then the application logic RPwork ofthe Relying Party will deliver the requested resource tothe requestor.

The XML Signature verification module RPsig is con-figured to trust several Identity Provider public keys{pk1, . . . , pkr}. Each public key defines a trusted do-main within RP. After receiving a signed XML documentD, RPsig searches for a Signature element. It appliesthe referencing method described in Reference to re-trieve the signed parts of the document, applies the trans-forms described in Transforms to these parts, and com-pares the computed hash values with the values stored inDigestValue. If all these values match, signature ver-ification is performed over the whole SignedInfo ele-ment, with one of the trusted keys from {pk1, . . . , pkr}.RPsig then communicates the result of the signature veri-fication (eventually alongside D) to RPclaims.

The SAML security claims processing moduleRPclaims may operate a customer database dbRP, and mayvalidate SAML assertions against this database. In thiscase if the claimed identity is contained in dbRP, the asso-ciated rights are granted to the requestor. As an alterna-tive, RPclaims may rely on authorization data contained indbIdP. In this case, the associated rights will be containedin the SAML assertion, and RPclaims will grant these.

Please note that the definition of the winning eventgiven below does not depend on the output of the sig-nature verification part RPsig, but on the SAML asser-tion processing RPclaims. This is necessary since in allcases described in this paper, signature verification wasdone correctly (as is always the case with XML Signa-ture wrapping). Therefore, to be able to formulate mean-ingful statements about the security of a SAML frame-work, we must make some assumptions on the behaviorof RPclaims.

There are many possible strategies for RPclaims to pro-cess SAML assertions: E.g. use the claims from the firstassertion which is opened during parsing, from the firstthat is closed during parsing (analogously for the last as-sertion opened or closed), or issue an error message ifmore than one Assertion element is read.

7.4 Adversarial ModelPlease recall the two different types of adversarieswe have mentioned in our threat model in Section 4.Advintc is the stronger of the two: He has the ability to

partially intercept network traffic, e.g. by sniffing HTTPtraffic on an unprotected WLAN, by reading past mes-sages from an unprotected log file, or by a chosen ci-phertext attack on TLS 1.0 along the lines of [5]. Pleasenote that already this adversary is strictly weaker than theclassical network based attacker known from cryptogra-phy. Advacc, our weaker adversary, only has access tothe IdP and RP, i.e. he may register as a customer withIdP and receive SAML assertions issued about himself,and he may send requests to RP.

We define preconditions and success conditions of anattacker in the form of a game G. If Adv mounts a suc-cessful attack under these conditions, we say that Advwins the game. This facilitates some definitions.

During the game G, the adversary has access to avalidly signed document D containing a SAML assertionA issued by IdP. He then generates his own (evil) asser-tion EA, and combines it arbitrarily with D into an XMLdocument D′. This document is then sent to RP.

Definition 1. We say that the adversary (either Advintc orAdvacc) wins game G if RP, after receiving document D′,with non-negligible probability Pr(WinAdv) bases its au-thentication and authorization decisions on the securityclaims contained in EA.

Remark: For all researched frameworks, the winningprobability was either negligible or equal to 1. Within theterm ”negligible” we include the possibility that Adv is-sues a forged cryptographic signature, which we assumeto be impossible in practice. If an adversary wins thegame against a specific Relying Party RP, he takes overthe trust domain for a specific public key pk within RP.Advacc may do this for all pk where he is allowed to reg-ister as a customer with the corresponding IdP who con-trols (sk, pk). Advintc can achieve this for all pk where heis able to find single signed SAML assertion A where thesignature can (could in the past) be verified with pk.

7.5 Countermeasure 1: Only-process-what-is-hashed

We can derive the first countermeasure if we assume thatRPsig acts as a filter and only forwards the hashed partsof an XML document to RPclaims. The hashed parts ofan XML document are those parts that are serialized asan input to a hash function, and where the hash value isstored in a Reference element. This excludes all partsof the document that are removed before hash calculationby applying a transformation, especially the envelopedsignature transform.

Claim 1. If RPsig only forwards the hashed parts of D toRPclaims, then Pr(WinAdv) is negligible.

It is straightforward to see that EA is only forwardedto RPclaims if a valid signature for EA is available.

Please note that although this approach is simple andeffective, it is rarely used in practice due to a number ofsubtle implementation problems. A variant of this ap-proach is implemented by SimpleSAMLphp, where theRP imposes special requirements on the SAML authen-tication response, thus limiting interoperability. We dis-cuss these problems in Section 8.

7.6 Countermeasure 2: Mark signed ele-ments

In practice, RPsig only returns a Boolean value, andthe whole document D is forwarded to RPclaims. SinceIdPhas to serve many different Relying Parties, we as-sume knowledge about the strategy of RPclaims only forRPsig. One possibility to mark signed elements is to handover the complete document D from RPsig to RPclaims,plus a description where the validly signed assertions canbe found.

A second possibility that is more appropriate forSAML is that RPsig chooses a random value r, marksthe validly signed elements with an attribute containingr, and forwards r together with the marked document.RPclaims can then check if the assertion processed con-tains r.

Let us therefore consider the second approach in moredetail. For sake of simplicity we assume that only onecomplete element (i.e. a complete subtree of the XMLdocument tree) is signed.

Claim 2. Let Dsig be the signed subtree of D, andlet r ∈ {0,1}l be the random value chosen by RPsigand attached to Dsig. Then Pr(WinAdv) is bounded bymax{breaksig,2−l}.

RPclaims (regardless of its strategy to choose an asser-tion) will only process EA if r is attached to this element.An adversary can achieve this by either generating a validsignature for EA (then r will be attached by RPsig), or byguessing r and attaching it to EA.

8 Practical Countermeasures

In Section 5.5 we analyzed message processing of Sim-pleSAMLphp. This framework was resistant against allXSW attacks. One could therefore ask a legitimate ques-tion: Why do we need further countermeasures and whyis it not appropriate to apply the security algorithm ofSimpleSAMLphp in every system?

We want to make clear that SimpleSAMLphp offersboth critical functionalities in one framework: signa-ture validation (RPsig) and SAML assertion evaluation

Response

Assertion ID=“123“

Signature URI=“#123“

RPsig RPclaims

Status

Response

Assertion ID=“123“

Figure 14: The see-what-is-signed approach applied inHTTP POST binding: After successful signature valida-tion the security module RPsig excludes all the unsignedelements and forwards the message to the module pro-cessing security claims RPclaims and the business logic.

(RPclaims). These two methods are implemented usingthe same libraries and processing modules. After pars-ing a document, the elements are stored within a docu-ment tree and can be accessed directly. This allows thesecurity developers to conveniently access the same el-ements used in signature validation and assertion evalu-ation steps. However, especially in SOA environmentsthere exist scenarios, which force the developers to sep-arate these two steps into different modules or even dif-ferent systems, e.g.:

• Using a signature validation library: Before eval-uating the incoming assertion elements, the devel-oper uses a DOM-based signature library, whichreturns true or false according to the messagevalidity. However, the developer does not exactlyknow which elements were validated. If the as-sertion evaluation uses a different parsing approach(e.g. streaming-based SAX or StAX approach)or another DOM-library, the message processingcould become error-prone.• XML Security gateways: XML Security gateways

can validate XML Signatures and are configured toforward only validated XML documents. If the de-veloper evaluates a validated document in his appli-cation, he again has no explicit information aboutthe position of the signed element. Synchronizationof signature and assertion processing components inthis scenario becomes even more complicated, if thedeveloper has no information about the implemen-tation of the security gateway (e.g. IBM XS40).

These two examples show that a convenient access tothe same XML elements is not always given. Subse-quently, we present two practical feasible countermea-sures, which can be applied in complex and distributedreal-world implementations. Both countermeasures re-sult from our formal analysis in Section 7.

8.1 See-what-is-signedThe core idea of this countermeasure is to forward onlythose elements to the business logic module (RPclaims)

that were validated by the signature verification module(RPsig). This is not trivial as extracting the unsigned el-ements from the message context could make the fur-ther message processing in some scenarios impossible.Therefore, we propose a solution that excludes only theunsigned elements which do not contain any signed de-scendants. We give an example of such a message pro-cessing in Figure 14. This way, the claims and messageprocessing logic would get the whole message context:in case of SOAP it would see the whole Envelope ele-ment, by application of HTTP POST binding it would beable to process the entire Response element. The mainadvantage of this approach is that the message process-ing logic does not have to search for validated elementsbecause all forwarded elements are validated.

We want to stress the fact that by application of this ap-proach all unsigned character nodes have to be extracted.Otherwise, the attacker could create an evil assertion EAand insert the signed original assertion into each elementof EA. If RPsig would not extract the character contentsfrom EA, RPclaims could process its claims. However, byextracting the unsigned character nodes, the attacker hasno possibility to insert his evil content, since it was ex-cluded in RPsig. Nevertheless, the subsequent XML mod-ules can still access the whole XML tree.

This idea has already been discussed by Gajek etal. [17]. However, until now no XML Signatureframework implements this countermeasure. It couldbe applied especially in the context of SAML HTTPPOST bindings because the unsigned elements withinthe SAML response do not contain any data neededin RPclaims. We consider this countermeasure in thesescenarios as appropriate because the SAML standardonly allows the usage of Id-based referencing, exclusivecanonicalization, and enveloped transformation. The au-thors explicitly state that this countermeasure would notwork if XML Signature uses specific XSLT or XPathtransformations.

8.2 Unique Identification (Tainting) ofSigned Data

The second countermeasure represents another form ofthe see-what-is-signed approach. The basic idea is touniquely identify the signed data in the RPsig moduleand forward this information to the following modules.As described in our formal analysis, this could be doneby generating a random value r, sending it to the nextprocessing module (or as an attribute in the documentroot element), and attaching it to all the signed elements.We give an example of this countermeasure applied to aSOAP message in Figure 15.

The main drawback of this countermeasure is that theSAML XML Schema does not allow the inclusion of

Envelope

Assertion

Header

ID=“123“

Signature

Signature

URI=“#123“

Body

URI=“#body“

ID=“body“

UnsignedContent

RPsig RPclaims

rg=“xy“

rg=“xy“

r=“xy“

Envelope

Assertion

Header

ID=“123“

Signature

Signature

URI=“#123“

Body

URI=“#body“

ID=“body“

UnsignedContent

r=“xy“

Figure 15: Unique identification of signed data appliedon a SOAP message including two signed elements: TheRPsig module uniquely identifies the signed elementswith a random value r and forwards this informationalong with the whole XML message.

new attributes: neither directly into the Assertion el-ement nor the Response binding element. Therefore,the XML Schema validation of the assertion processingmodule would fail. For general application of this ideathe SAML XML Schema needs to be extended.

Another possibility to implement this countermeasureis to use XML node types, which do not violate XMLSchema, but are visible to the XML processors. Forexample, processing instructions, which are intended tocarry instructions to the application belong to this group.They can be placed anywhere in the document withoutinvalidating the XML Schema. Additionally, they canbe conveniently found by processing XML trees withstreaming and DOM-based parsers. Therefore, the pres-ence of these XML nodes would help to find the vali-dated data and thus allows to mitigate XSW attacks. Wepropose this technique for further discussion in the W3CXML Security Working Group and the OASIS consor-tium.

9 Related Work

XML Signature Wrapping (XSW). XSW attackshave first been described in [28] and [7]. Several coun-termeasures have been proposed over time.

McIntosh and Austel [28] have presented several XSWattacks and discussed (informal) receiver-sided securitypolicies in order to prevent such exploits. They havehowever not given a definitive solution for this problem.

Bhargavan, Fournet and Gordon [7] have analyzed aformal approach in order to verify Web Services specifi-cations. They have proposed a policy advisor [8], a toolthat generates appropriate security policies for Web Ser-vices protocols. This approach is however not directlyapplicable to SAML.

Rahaman, Schaad and Rits [32, 30, 31] have refrainedfrom policy-driven approaches and have introduced aninline solution. The authors have proposed to embed anAccount element into the SOAP header. This element

contains partial information about the structure of theSOAP message and the neighborhood of the signed el-ement(s). The information preserves the structure of thedata to be signed. However, Gajek et al. have shownthat this approach does not prevent XSW attacks [16].Benameur, Kadir, and Fenet [6] have extended the inlineapproach, but suffer from the same vulnerabilities.

Jensen et al. [24] have analyzed the effectiveness ofXML Schema validation in terms of fending XSW at-tacks in Web Services. Thereby, they have used man-ually hardened XML Schemas. The authors have con-cluded that XML Schema validation is capable of fend-ing XSW attacks, at the expense of two important disad-vantages: for each application a specific hardened XMLSchema without extension points must be created care-fully. Moreover, validating of a hardened XML Schemaentails severe performance penalties.

XPath and XPath Filter 2 are specified as referenc-ing mechanisms in the XML Signature standard. How-ever, the WS-Security standard proposes not to use thesemechanisms, and the SAML standard mandates to useId-based referencing instead. This is due to the fact thatboth standards are very complex. Gajek et al. [15] haveevaluated the effectiveness of these mechanisms to mit-igate XSW attacks in the SOAP context, and have pro-posed a lightweight variant FastXPath, which has leadto the same performance in a PoC implementation as byadapting the Id-based referencing.

Jensen et al. [23] have however shown that this ap-proach does not completely eliminate XSW attacks: byclever manipulations of XML namespace declarationswithin a signed document, which take into account theprocessing rules for canonicalization algorithms in XMLSignature, XSW attacks could successfully be mountedeven against XPath referenced resources.

The impacts of practical XSW attacks have also beenanalyzed in [20, 33]. In these works new types ofXSW attack have been applied on SOAP Web Serviceinterfaces of Amazon and Eucalyptus clouds. The at-tacks have exploited different XML processing in dis-tinct modules.

In summary, previous work has mostly concentratedon SOAP, and the results do not directly apply to allSAML use cases.

SAML and Single Sign-On Since SAML offers veryflexible mechanisms to make claims about identities,there is a large body of research on how SAML can beused to improve identity management (e.g. [22, 39]) andother identity-related processes like payment or SIP onthe Internet [25, 35]. In all these applications, the secu-rity of all SAML standards is assumed.

In an overview paper on SAML, Maler and Reed [26]have proposed mutually authenticated TLS as the basic

security mechanism. Please note that even if mutuallyauthenticated TLS would be employed, it would not pre-vent our attacks because we only need a single signedSAML assertion from an IdP, which we can get throughdifferent means. Moreover, there exist specific sidechan-nels, which could be exploited by an adversary. Let use.g. mention chosen-plaintext attacks against SSL/TLSpredicted by [37] and refined by [5], or the Million Ques-tion attack by Bleichenbacher [9]. Other complicationsarise with the everlasting problems with SSL PKIs.

In 2003, T. Groß has initiated the security analysis ofSAML [18] from a Dolev-Yao point of view, which hasbeen formalized in [4]. He has found, together with B.Pfitzmann [19], deficiencies in the information flow be-tween the SAML entities. Their work has influenced arevision of the standard.

In 2008, Armando et al. [3] have built a formal modelof the SAML 2.0 Web Browser SSO protocol and haveanalyzed it with the model checker SATMC. By intro-ducing a malicious RP they have found a practical at-tack on the SAML implementation of Google Apps. An-other attack on the SAML-based SSO of Google Appshas been found in 2011 [2]. Again, a malicious RP hasbeen used to force a user’s web browser to access a re-source without approval. Thereby, the malicious RP hasinjected malicious content in the initial unintended re-quest to the attacked RP. After successful authenticationon the IdP this content has been executed in the contextof the user’s authenticated session.

The fact that SAML protocols consist of multiple lay-ers has been pointed out in [13]. In this paper, the Weak-est Link Attack has enabled adversaries to succeed at alllevels of authentication by breaking only at the weakestone.

Very recently, another work pointing out the impor-tance of SSO protocols has been published by Wang etal. [38]. This work has analyzed the security qualityof commercially deployed SSO solutions. It has showneight serious logic flaws in high-profile IdPs and RPs(such as OpenID, Facebook, or JanRain), which haveallowed an attacker to sign in as the victim user. TheSAML-based SSO has not been analyzed.

10 Conclusion

In this paper we systematically analyzed the applicationof XSW attacks on SAML frameworks and systems. Weshowed that the large majority of systems exhibit criti-cal security insufficiencies in their interfaces. Addition-ally, we revealed new classes of XSW attacks, whichworked even if specific countermeasures were applied.We showed that the application of XML Security heav-ily depends on the underlying XML processing system(i.e. different XML libraries and parsing types). The pro-

cessing modules involved can have inconsistent views onthe same secured XML document, which may result insuccessful XSW attacks. Generally, these heterogeneousviews can exist in all data formats beyond XML.

We proposed a formal model by analyzing the in-formation flow inside the Relying Party and presentedtwo countermeasures. The effectiveness of these coun-termeasures depends on the real information flow andthe data processing inside RPclaims. Our research isa first step towards understanding the implications ofthe information flow between cryptographic and non-cryptographic components in complex software environ-ments. Research in this direction could enhance the re-sults, and provide easy-to-apply solutions for practicalframeworks.

As another future research direction, we propose de-velopment of an enhanced penetration testing tool forXSW in arbitrary XML documents and all types of XMLSignatures. This kind of tool presents a huge challengeas it should e.g. consider more difficult transformationslike XPath or XSLT.

AcknowledgementsThe authors would like to thank all the security teams andtheir developers for their cooperation, and would like tonote that throughout the collaboration all the teams ef-fectuated a productive and highly professional commu-nication.

Moreover, we would like to thank Scott Cantor, DavidJorm, Florian Kohlar, Christian Mainka, ChristopherMeyer, Thomas Roessler, and the anonymous review-ers (of the USENIX Security Symposium and the IEEESymposium on Security and Privacy) for their valuableremarks on the developed attacks and the paper content.Finally, we thank Alexander Bieber for the Sharepoint2010 test bed.

This work was partially funded by the Sec2 project ofthe German Federal Ministry of Education and Research(BMBF, FKZ: 01BY1030).

References[1] IEEE International Conference on Web Services, ICWS 2009, Los

Angeles, CA, USA, 6-10 July 2009 (2009), IEEE.

[2] ARMANDO, A., CARBONE, R., COMPAGNA, L., CUELLAR, J.,PELLEGRINO, G., AND SORNIOTTI, A. From Multiple Creden-tials to Browser-Based Single Sign-On: Are We More Secure?In Future Challenges in Security and Privacy for Academia andIndustry, J. Camenisch, S. Fischer-Hbner, Y. Murayama, A. Port-mann, and C. Rieder, Eds., vol. 354 of IFIP Advances in Infor-mation and Communication Technology. Springer Boston, 2011.

[3] ARMANDO, A., CARBONE, R., COMPAGNA, L., CUELLAR,J., AND TOBARRA, M. L. Formal Analysis of SAML 2.0Web Browser Single Sign-On: Breaking the SAML-based SingleSign-On for Google Apps. In Proceedings of the 6th ACM Work-shop on Formal Methods in Security Engineering, FMSE 2008,V. Shmatikov, Ed. ACM, Alexandria and VA and USA, 2008.

[4] BACKES, M., AND GROSS, T. Tailoring the dolev-yao abstrac-tion to web services realities. In SWS (2005), E. Damiani andH. Maruyama, Eds., ACM, pp. 65–74.

[5] BARD, G. V. A Challenging but Feasible Blockwise-Adaptive Chosen-Plaintext Attack on SSL. In SECRYPT (2006),M. Malek, E. Fernandez-Medina, and J. Hernando, Eds., IN-STICC Press, pp. 99–109.

[6] BENAMEUR, A., KADIR, F. A., AND FENET, S. XML Rewrit-ing Attacks: Existing Solutions and their Limitations. In IADISApplied Computing 2008 (Apr. 2008), IADIS Press.

[7] BHARGAVAN, K., FOURNET, C., AND GORDON, A. D. Verify-ing policy-based security for web services. In CCS ’04: Proceed-ings of the 11th ACM conference on Computer and communica-tions security (2004), pp. 268–277.

[8] BHARGAVAN, K., FOURNET, C., GORDON, A. D., ANDO’SHEA, G. An advisor for web services security policies. InSWS ’05: Proceedings of the 2005 workshop on Secure web ser-vices (New York, NY, USA, 2005), ACM, pp. 1–9.

[9] BLEICHENBACHER, D. Chosen ciphertext attacks against proto-cols based on the rsa encryption standard pkcs #1. In CRYPTO(1998), pp. 1–12.

[10] CANTOR, S., KEMP, J., MALER, E., AND PHILPOTT,R. Profiles for the OASIS Security Assertion MarkupLanguage (SAML) V2.0. OASIS Standard, 15.03.2005,2005. http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf.

[11] CANTOR, S., KEMP, J., PHILPOTT, R., AND MALER, E.Assertions and Protocol for the OASIS Security AssertionMarkup Language (SAML) V2.0. OASIS Standard, 15.03.2005,2005. http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf.

[12] CANTOR, S., MOREH, J., PHILPOTT, R., AND MALER,E. Metadata for the OASIS Security Assertion MarkupLanguage (SAML) V2.0. OASIS Standard, 15.03.2005,2005. http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf.

[13] CHAN, Y.-Y. Weakest link attack on single sign-on and its casein saml v2.0 web sso. In Computational Science and Its Applica-tions - ICCSA 2006, M. Gavrilova, O. Gervasi, V. Kumar, C. Tan,D. Taniar, A. Lagan, Y. Mun, and H. Choo, Eds., vol. 3982 ofLecture Notes in Computer Science. Springer Berlin / Heidelberg,2006, pp. 507–516. 10.1007/11751595 54.

[14] EASTLAKE, D., REAGLE, J., SOLO, D., HIRSCH, F., ANDROESSLER, T. XML Signature Syntax and Processing (SecondEdition), 2008. http://www.w3.org/TR/xmldsig-core/.

[15] GAJEK, S., JENSEN, M., LIAO, L., AND SCHWENK, J. Analy-sis of signature wrapping attacks and countermeasures. In ICWS[1], pp. 575–582.

[16] GAJEK, S., LIAO, L., AND SCHWENK, J. Breaking and fixingthe inline approach. In SWS ’07: Proceedings of the 2007 ACMworkshop on Secure web services (New York, NY, USA, 2007),ACM, pp. 37–43.

[17] GAJEK, S., LIAO, L., AND SCHWENK, J. Towards a formalsemantic of xml signature. W3C Workshop Next Steps for XMLSignature and XML Encryption, 2007.

[18] GROSS, T. Security Analysis of the SAML SSO Browser/ArtifactProfile. In ACSAC (2003), IEEE Computer Society, pp. 298–307.

[19] GROSS, T., AND PFITZMANN, B. SAML artifact informationflow revisited. In In IEEE Workshop on Web Services Security(WSSS) (Berkeley, May 2006), IEEE, pp. 84–100.

[20] GRUSCHKA, N., AND IACONO, L. L. Vulnerable cloud: Soapmessage security validation revisited. In ICWS [1], pp. 625–631.

[21] GUDGIN, M., HADLEY, M., MENDELSOHN, N., MOREAU, J.-J., AND NIELSEN, H. F. SOAP Version 1.2 Part 1: MessagingFramework. W3C Recommendation (2003).

[22] HARDING, P., JOHANSSON, L., AND KLINGENSTEIN, N. Dy-namic security assertion markup language: Simplifying singlesign-on. Security Privacy, IEEE 6, 2 (march-april 2008), 83 –85.

[23] JENSEN, M., LIAO, L., AND SCHWENK, J. The curse of names-paces in the domain of xml signature. In SWS (2009), E. Damiani,S. Proctor, and A. Singhal, Eds., ACM, pp. 29–36.

[24] JENSEN, M., MEYER, C., SOMOROVSKY, J., AND SCHWENK,J. On the effectiveness of xml schema validation for counter-ing xml signature wrapping attacks. In Securing Services on theCloud (IWSSC), 2011 1st International Workshop on (sept. 2011),pp. 7 –13.

[25] LUTZ, D., AND STILLER, B. Combining identity federation withpayment: The saml-based payment protocol. In Network Oper-ations and Management Symposium (NOMS), 2010 IEEE (april2010), pp. 495 –502.

[26] MALER, E., AND REED, D. The venn of identity: Options andissues in federated identity management. Security Privacy, IEEE6, 2 (march-april 2008), 16 –23.

[27] MCINTOSH, M., AND AUSTEL, P. XML Signature ElementWrapping Attacks and Countermeasures. In SWS ’05: Proceed-ings of the 2005 workshop on Secure web services (New York,NY, USA, 2005), ACM Press, pp. 20–27.

[28] MCINTOSH, M., AND AUSTEL, P. XML signature elementwrapping attacks and countermeasures. In Workshop on SecureWeb Services (2005).

[29] NADALIN, A., KALER, C., MONZILLO, R., AND HALLAM-BAKER, P. Web Services Security: SOAP Message Security 1.1(WS-Security 2004). OASIS Standard (2006).

[30] RAHAMAN, M. A., MARTEN, R., AND SCHAAD, A. An inlineapproach for secure soap requests and early validation. OWASPAppSec Europe, 2006.

[31] RAHAMAN, M. A., AND SCHAAD, A. Soap-based secure con-versation and collaboration. In ICWS (2007), pp. 471–480.

[32] RAHAMAN, M. A., SCHAAD, A., AND RITS, M. Towards se-cure soap message exchange in a soa. In Workshop on SecureWeb Services (2006).

[33] SOMOROVSKY, J., HEIDERICH, M., JENSEN, M., SCHWENK,J., GRUSCHKA, N., AND IACONO, L. L. All Your Clouds areBelong to us – Security Analysis of Cloud Management Inter-faces. In The ACM Cloud Computing Security Workshop (CCSW)(Oct. 2011).

[34] THE APACHE SOFTWARE FOUNDATION. Apache Xerces.[35] TSCHOFENIG, H., FALK, R., PETERSON, J., HODGES, J.,

SICKER, D., AND POLK, J. Using saml to protect the sessioninitiation protocol (sip). Network, IEEE 20, 5 (sept.-oct. 2006),14 –17.

[36] VAN DER VLIST, E. XML Schema. O’Reilly, 2002.[37] WAGNER, D., AND SCHNEIER, B. Analysis of the SSL 3.0 pro-

tocol. In In Proceedings of the Second USENIX Workshop onElectronic Commerce (1996), USENIX Association, pp. 29–40.

[38] WANG, R., CHEN, S., AND WANG, X. Signing Me onto YourAccounts through Facebook and Google: a Traffic-Guided Secu-rity Study of Commercially Deployed Single-Sign-On Web Ser-vices. In IEEE Symposium on Security and Privacy (Oakland),IEEE Computer Society (May 2012).

[39] YONG-SHENG, Z., AND JING, Y. Research of dynamic authen-tication mechanism crossing domains for web services based onsaml. In Future Computer and Communication (ICFCC), 20102nd International Conference on (may 2010), vol. 2, pp. V2–395–V2–398.