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, Germany 2Adolf Wurth¨ GmbH & Co. KG, Kunzelsau-Gaisbach,¨ Germany {Juraj.Somorovsky, Joerg.Schwenk, Marco.Kampmann, Meiko.Jensen}@rub.de, [email protected]
Abstract dard, this shall be achieved by using XML Signatures, which should either cover the complete SAML assertion, The Security Assertion Markup Language (SAML) is a or an XML document containing it (e.g. a SAML Au- widely adopted language for making security statements thentication response). about subjects. It is a critical component for the develop- However, roughly 80% of the SAML frameworks that ment of federated identity deployments and Single Sign- we evaluated could be broken by circumventing integrity On scenarios. In order to protect integrity and authentic- protection with novel XML Signature wrapping (XSW) ity of the exchanged SAML assertions, the XML Signa- attacks. This surprising result is mainly due to two facts: ture standard is applied. However, the signature verifica- tion algorithm is much more complex than in traditional • Complex Signing Algorithm: Previous digital sig- signature formats like PKCS#7. The integrity protection nature data formats like PKCS#7 and OpenPGP can thus be successfully circumvented by application of compute a single hash of the whole document, and different XML Signature specific attacks, under a weak signatures are simply appended to the document. adversarial model. The XML Signature standard is much more com- In this paper we describe an in-depth analysis of 14 plex. Especially, the position of the signature and major SAML frameworks and show that 11 of them, the signed content is variable. Therefore, many per- including Salesforce, Shibboleth, and IBM XS40, have mutations of the same XML document exist. critical XML Signature wrapping (XSW) vulnerabilities. • Unspecified internal interface: Most SAML Based on our analysis, we developed an automated pen- frameworks treat the Relying Party (i.e. the Web etration testing tool for XSW in SAML frameworks. Its Service or website consuming SAML assertions) as feasibility was proven by additional discovery of a new a single block, assuming a joint common state for XSW variant. We propose the first framework to an- all tasks. However, logically this block must be sub- alyze such attacks, which is based on the information divided into the signature verification module (later flow between two components of the Relying Party. Sur- called RPsig) which performs a cryptographic opera- prisingly, this analysis also yields efficient and practical tion, and the SAML processing module (later called countermeasures. RPclaims) which processes the claims contained in the SAML assertion. Both modules have different 1 Introduction views on the assertion, and they typically only ex- change a Boolean value about the validity of the sig- The Security Assertion Markup Language (SAML) is an nature. XML based language designed for making security state- ments about subjects. SAML assertions are used as se- CONTRIBUTION. In this paper, we present an in- curity tokens in WS-Security, and in REST based Single depth analysis of 14 SAML frameworks and systems. Sign-On (SSO) scenarios. SAML is supported by major During this analysis, we found critical XSW vulnerabili- software vendors and open source projects, and is widely ties in 11 of these frameworks. This result is alarming deployed. Due to its flexibility and broad support, new given the importance of SAML in practice, especially application scenarios are defined constantly. since SSO frameworks may become a single point of at- SAMLASSERTIONS. Since SAML assertions con- tack. It clearly indicates that the security implications tain security critical claims about a subject, the validity behind SAML and XML Signature are not understood of these claims must be certified. According to the stan- yet. Second, these vulnerabilities are exploitable by an at- Relying Party Client Identity Provider (RP) Login (IdP) tacker with far fewer resources than the classical network Request SAML Request 1 Token based attacker from cryptography: Our adversary may 2 Issuing Token Token succeed even if he does not control the network. He does Request 3 Redirect not need realtime eavesdropping capabilities, but can 4 SAML Response Token 5 Issuing and work with SAML assertions whose lifetime has expired. Signing Token A single signed SAML assertion is sufficient to com- Token Response Signature Redirect 6 pletely compromise a SAML issuer/Identity Provider. validation 7 Token 8 Using SSL/TLS to encrypt SAML assertions, and thus to evaluation User prevent adversaries from learning assertions by intercept- authorization [SSL/TLS] [SSL/TLS] ing network traffic, does not help either: The adversary may e.g. register as a regular customer at the SAML is- Figure 1: A typical Single Sign-On scenario: The user suer, and may use his own assertion to impersonate other visits the RP, which generates a request token. He redi- customers. rects this token to the IdP. The issued token is sent to the user and forwarded to the RP. Even though the channel Third, we give the first model for SAML frameworks is secured by SSL/TLS, the user still can see the token. that takes into account the interface between RPsig and RPclaims. This model gives a clear definition of successful attacks on SAML. Besides its theoretical interest, it also 2 Motivation enables us to prove several positive results. These results are new and help to explain why some of the frameworks In this section we introduce two typical SAML scenarios were not vulnerable to our attacks, and to give advice on and some widely used SAML frameworks. how to improve the security of the other 11 frameworks. SAML-BASED SINGLE SIGN-ON. Typical Internet users have to manage many identities for different web Last, we show that XSW vulnerabilities constitute an applications. To overcome this problem, Single Sign-On important and broad class of attack vectors. There is no was developed. In this approach the users authenticate easy defense against XSW attacks: Contrary to common only once to a trustworthy Identity Provider (IdP). After belief, even signing the whole document does not neces- a successful login of a user, the IdP issues security to- sarily protect against them. To set up working defenses, kens on demand. These tokens are used to authenticate a better understanding of this versatile attack class is re- to Relying Parties (RP). quired. A specialized XSW pentesting tool developed A simplified Single Sign-On scenario is depicted in during our research will be released as open source to aid Figure 1. In this setting, a user logged-in by the IdP first this understanding. Its practicability was proven by dis- visits the desired RP (1). The RP issues a token request covering a new attack vector on Salesforce SAML inter- (2). This token is sent to the user (3) who forwards it face despite the fact that specific countermeasures have to the IdP (4). The IdP issues a token response for the been applied. user including several claims (e.g. his access rights or expiration time). In order to protect the authenticity and RESPONSIBLE DISCLOSURE. All vulnerabilities integrity of the claims, the token is signed (5). Subse- found during our analysis were reported to the respon- quently, the token is sent to the user (6), who forwards it sible security teams. Accordingly, in many cases, we to the RP (7). The RP validates the signature and after- closely collaborated with them in order to patch the wards grants access to the protected service or resource, found issues. if the user is authorized (8). This access control decision is based on the claims in the validated token. OUTLINE. The rest of the paper is organized as fol- SECURING WEB SERVICESWITH SAML. Another lows. Section 2 gives a highlevel overview on SAML, typical application scenario is the use of SAML together and Section 3 adds details. The methodology of the in- with WS-Security [29] in SOAP [21] to provide authen- vestigation is explained in Section 4, and the detailed re- tication and authorization mechanisms to Web Services. sults are described in Section 5. In Section 6 we present SAML assertions are included as security tokens in the the first fully automated XSW penetration test tool for Security header. SAML. Section 7 gives a formal analysis and derives two SAMLPROVIDERSAND FRAMEWORKS. The countermeasures. In Section 8 we discuss their practi- evaluation presented in this paper was made through- cal feasibility. Section 9 presents an overview on related out the last 18 months and includes prominent and well- work. In the last section we conclude and propose future used SAML frameworks, which are summarized in Ta- research directions. ble 1. Our analysis included the IBM hardware appliance Framework/Provider Type Language Reference Application1 Apache Axis 2 WS Java http://axis.apache.org WSO2 Web Services Guanxi Web SSO Java http://guanxi.sourceforge.net Sakai Project (www.sakaiproject.org) Higgins 1.x Web SSO Java www.eclipse.org/higgins Identity project IBM XS40 WS XSLT www.ibm.com Enterprise XML Security Gateway JOSSO Web SSO Java www.josso.org Motorola, NEC, Redhat 2 WIF Web SSO .NET http://msdn.microsoft.com Microsoft Sharepoint 2010 OIOSAML 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 SSO OneLogin Web SSO Java, PHP, Ruby, Python www.onelogin.com Joomla, Wordpress, SugarCRM, Drupal OpenAthens Web SSO Java, C++ www.openathens.net UK Federation (www.eduserv.org.uk) OpenSAML Web SSO Java, C++ http://opensaml.org Shibboleth, SuisseID Salesforce Web SSO — www.salesforce.com Cloud Computing and CRM SimpleSAMLphp Web SSO PHP http://simplesamlphp.org Danish e-ID Federation (www.wayf.dk) WSO2 Web SSO Java www.wso2.com WSO2 products (Carbon, ESB, . . . )
Table 1: Analyzed SAML frameworks and providers: The columns give information about type (Web Service or Browser-based SSO), programming language (if known), website, and application in concrete products or frameworks.
Figure 3: SAML assertion structure. Figure 4: SAML message examples (SOAP and REST): The SAML assertion is put into a root element R and signed using an enveloped signature. When signing the 3.2 XML Schema SOAP body, an additional detached signature is used. The W3C recommendation XML Schema [36] is a lan- guage to describe the layout, semantics, and content of Signature standard. Therefore, the SAML specifica- an XML document. A document is deemed to be valid, tion [11] requires that either the saml:Assertion ele- when it conforms to a specific schema. A schema con- ment or an ancestor element must be referenced by the sists of a content model, a vocabulary, and the used data Signature element, with an enveloped XML Signature types. The content model describes the document struc- ([11], Section 5.4.1). Furthermore, Id-based referencing ture and the relationship of the items. The standard pro- must be used ([11], Section 5.4.2), which opens the way vides 19 primitive data types to define the allowed con- for XSW attacks. tent of the elements and attributes. Regarding to our evaluation of SAML based XML In REST based frameworks, the SAML assertion is Signature Wrapping attacks there is one important el- typically put into an enveloping Response element. ement definition in XML Schema. The any element Frameworks applying SOAP insert the SAML assertions allows the usage of any well-formed XML document into the SOAP header (or the Security element in- in a declared content type. When an XML processor side of the SOAP header). For clarification purposes, validates an element defined by an any element, the consider that the SAML assertions are signed using en- processContents attribute specifies the level of flex- veloped XML Signatures and are put into some binding ibility. The value lax instructs the schema validator to root element R (see Figure 4). check against the given namespace. If no schema infor- mation is available, the content is considered valid. In the 3.4 XML Signature Wrapping Attacks case of processContents="skip" the XML processor does not validate the element at all. XML documents containing XML Signatures are typi- cally processed in two independent steps: signature val- 3.3 SAML idation and function invocation (business logic). If both modules have different views on the data, a new class of SAML is an XML standard for exchanging authentica- vulnerabilities named XML Signature Wrapping attacks tion and authorization statements about Subjects [11]. (XSW) [27, 23] exists. In these attacks the adversary Several profiles are defined in [10]. The most important modifies the message structure by injecting forged ele- profile is the Browser SSO profile, which defines how to ments which do not invalidate the XML Signature. The use SAML with a web browser. goal of this alteration is to change the message in such A SAML assertion has the structure described in Fig- a way that the application logic and the signature verifi- ure 3. The issuing time of the assertion is specified in cation module use different parts of the message. Con- saml:IssueInstant. All attributes are required. sequently, the receiver verifies the XML Signature suc- The saml:Issuer element specifies the SAML au- cessfully but the application logic processes the bogus thority (the IdP) that is making the claim(s) in the asser- element. The attacker thus circumvents the integrity pro- tion. The assertion’s saml:Subject defines the princi- tection and the origin authentication of the XML Signa- pal about whom all statements within the assertion are ture and can inject arbitrary content. Figure 5 shows a made. The saml:*Statement elements are used to simple XSW attack on a SOAP message. specify user-defined statements relevant for the context XSW attacks resemble other classes of injection at- of the SAML assertion. tacks like XSS or SQLi: in all cases, the attacker tries to To protect the integrity of the security claims made force different views on the data in security modules (e.g. by the Issuer, the whole saml:Assertion element must Web Application Firewalls) and data processing modules be protected with a digital signature following the XML (HTML parser, SQL engine). Envelope Signed Legitimate content Injected evil content Header Signed Processed Signing Type 1) Signature Processed A1 S1 EA SignedInfo Reference URI=“#123“
Wrapper Signing Type 2)
Body ID=“123“ R A1 S1 ER EA MonitorInstances Signing Type 3) Body ID=“attack“ CreateKeyPair R A1 S1 S ER EA
Figure 5: A simple XML Signature wrapping attack: The attacker moves the original signed content to a newly cre- Figure 6: Types of signature applications on SAML as- ated Wrapper element. Afterwards, he creates an arbi- sertions on the left. The new malicious content needed trary content with a different Id, which is invoked by the to execute the attacks depicted on the right, accordingly. business logic.
in technical discussion boards, where Advintcmay 4 XSW Attacks on SAML access them.
In this section we first characterize the assumed threat model. Second, we describe the basic attack principle 4.2 Basic Attack Principle 3 that underlies our analysis of the 14 frameworks. As described in the previous section, XML Signatures can be applied to SAML assertions in different ways and 4.1 Threat Model placed in different elements. The only prerequisite is that the Assertion element or the protocol binding element As a prerequisite the attacker requires an arbitrary signed (ancestor of Assertion) is signed using an enveloped A SAML message. This could be a single assertion or a signature with Id-based referencing. In this section we D whole document with an embedded assertion, and its analyze the usage of SAML assertions in different frame- lifetime can be expired. After obtaining such a message, works and the possibilities of inserting malicious con- the attacker modifies it by injecting evil content, e.g. an tent. Generally, SAML assertions and their signatures EA evil assertion . In our model we assume two differ- are implemented as depicted in Figure 6: ent types of adversaries, which are both weaker than the classical network based attacker: 1. The first possible usage of signatures in SAML as- sertions is to insert the XML Signature S1 as a 1. Advacc. To obtain an assertion, this attacker regis- child of the SAML assertion A1 and sign only the ters as a user of an Identity Provider IdP. Advacc then receives, through normal interaction with IdP, Assertion element A1. This type can be used in- a valid signed SAML assertion A (probably as a dependently of the underlying protocol (SOAP or part of a larger document D) making claims about REST). Advacc. The attacker now adds additional claims EA 2. The second type of signature application in SAML about any other subject S, and submits the modified signs the whole protocol binding element R. The document D0 (A0) to RP. XML Signature can be placed into the SAML asser- tion A1 or directly into the protocol binding root ele- 2. Advintc. This adversary retrieves SAML assertions from the Internet, but he does not have the abil- ment R. This kind of signature application is used in ity to read encrypted network traffic. This can different SAML HTTP bindings, where the whole be done either by accessing transmitted data di- Response element is signed. rectly from unprotected networks (sniffing), or in 3. It is also possible to use more than one XML Sig- an ”offline” manner by analyzing proxy or browser nature. The third example shows this kind of signa- caches. Since SAML assertions should be worthless ture application: the inner signature S1 protects the once their lifetime expired, they may even be posted SAML assertion and the outer signature S addition- ally secures the whole protocol message. This kind 3 Please note that from now on we distinguish between the document of signature application is e.g. used by the Simple- D and the root element R. This is to make clear the distinction between the element referenced by the XML signature, and the document root: SAMLphp framework. Even if the root element R of the original document D is signed, we may transform this into a new document D0 with a new evil root ER, In order to apply XSW attacks to SAML assertions, without invalidating the signature. the basic attack idea stays the same: The attacker has to create new malicious elements and force the assertion 1) One Level (6 Permutations) Signed logic to process them, whereas the signature verification R R Processed logic verifies the integrity and authenticity of the original SAML-conform EA A1 S1 A1 EA S1 content. In applications of the first signature type, the not SAML-conform
attacker only has to create a new evil assertion EA. In the Signature Invalid second and third signing types, he also has to create the 2) Three Levels (6 Permutations) whole evil root ER element including the evil assertion. a) b) c) d) R R R R
4.3 Attack Permutations A1 EA EA S1 S1 S1 A1 The attacker has many different possibilities where to in- A1 sert the malicious and the original content. To this end, EA S1 A1 EA he has to deal with these questions: 3) Two Levels (12 Permutations) • At which level in the XML message tree should the a) b) c) d) malicious content and the original signed data be R R R R included? EA A1 EA A1 A1 EA A1 EA • Which Assertion element is processed by the as- sertion logic? S1 S1 S1 S1 • Which element is used for signature verification? Figure 7: Possible variants for XSW attacks applied on By answering these questions we can define different messages with one signed SAML assertion divided ac- attack patterns, where the original and the malicious el- cording to the insertion depth of the evil assertion EA, ements can be permuted (Figure 7). We thus get a com- the original assertion A1 and the signature S1. The var- plete list of attack vectors, which served as a guideline ious permutations are labeled according to their validity for our investigations. and SAML-conformance. For the following explanations we only consider sign- ing type 1) defined in Figure 6. In this signing type only the Assertion element is referenced. child of the root element, the message would also be The attack permutations are depicted in Figure 7. In either invalid or not SAML standard compliant. addition, we analyze their SAML standard conformance 3. For the insertion of these three elements we use two and the signature validity: message levels: Message 3-a shows an example of a valid and SAML compliant document. By con- 1. Malicious assertion, original assertion, and signa- structing message 3-b, the signature element was ture are left on the same message level: This kind of moved to the new malicious assertion. Since it ref- XML message can have six permutations. None of erences the original element, it is still valid, but does them is SAML standard compliant, since the XML not conform to the SAML standard. Signature does not sign its parent element. The di- gest value over the signed elements in all the mes- The analysis shown above can similarly be applied to sages can be correctly validated. We can use this messages with different signing types (see Figure 6). type of attack messages if the server does not check the SAML conformance. 5 Practical Evaluation 2. All the three elements are inserted at different mes- sage levels, as child elements of each other, which We evaluated the above defined attacks on real-world again results in six permutations: Messages 2-a and systems and frameworks introduced in Section 2. In this 2-b show examples of SAML standard conform- section we present the results. ing and cryptographically valid messages. In both cases the signature element references its parent – 5.1 Signature Exclusion Attacks the original assertion A1. Message 2-c illustrates a message which is not SAML standard conform as We start the presentation of our results with the simplest the signature signs its child element. Nevertheless, attack type called Signature exclusion attack. This at- the message is cryptographically valid. Lastly, mes- tack relies on poor implementation of a server’s security sage 2-d shows an example of an invalid message logic, which checks the signature validity only if the sig- since the signature would be verified over both as- nature is included. If the security logic does not find the sertions. Generally, if the signature is inserted as the Signature element, it simply skips the validation step. Higgins, Apache Axis2, IBM XS 40 Security Gateway OIOSAML OpenAM, Salesforce Signed
Root Root Root Root Processed
Assertion ID=“evil“ Assertion ID=“evil“ Assertion ID=“evil“ Assertion ID=“evil“
Assertion ID=“123“ Assertion ID=“123“ Signature Signature
SignedInfo SignedInfo Signature Signature Reference URI=“#123“ Reference URI=“#123“ SignedInfo SignedInfo Assertion ID=“123“ Assertion ID=“123“ Reference URI=“#123“ Reference URI=“#123“
Figure 8: XML tree-based illustration of refined XSW attacks found in Type 1 signature applications.
The evaluation showed that three SAML-based frame- Guanxi, JOSSO WSO2 works were vulnerable to these attacks: Apache Axis2 Root ID=“evil“ Root ID=“evil“ Web Services Framework, JOSSO, and the Java-based Signature Root ID=“123“ SignedInfo Assertion implementation of SAML 2.0 in Eduserv (other versions Reference URI=“#123“ Signature
of SAML and the C-implementation in Eduserv were not Root ID=“123“ SignedInfo
affected). Assertion Reference URI=“#123“
By applying this attack on JOSSO and Eduserv the at- Assertion Assertion tacker had to remove the Signature element from the message, since if it was found, the framework tried to validate it. On the other hand, the Apache Axis2 frame- Figure 9: XML tree-based illustration of refined XSW work did not validate the Signature element over the attacks found in Type 2 signature applications. SAML assertion at all, even if it was included in the mes- sage. Apache Axis2 validated only the signature over the SOAP body and the Timestamp element. The signature and the OpenAM framework. At this, the genuine asser- protecting the SAML assertion, which is included sep- tion was placed into the original Signature element. As arately in the Assertion element, was completely ig- both implementations apply XML Schema for validating nored. the schema conformance of a SAML message, this was done by injecting them into the Object element, which allows arbitrary content. Again, this is not compliant 5.2 Refined Signature Wrapping to the SAML standard because this mutation transforms Ten out of 14 systems were prone to refined XSW at- the enveloped to an enveloping signature. Finally, the tacks. OneLogin Toolkits were prone to all shown attack vari- Classified on the three different signature application ants as they did not apply XML Schema, validated the types given in Figure 6, five SAML-based systems failed XML Signature independent of it’s semantic occurrence in validating Type 1 messages, where only the asser- and used a fixed reference to the processed SAML claims tion is protected by an XML Signature. Figure 8 depicts (/samlp:Response/saml:Assertion[1]). the XML tree-based illustration of the found XSW vari- We found three susceptible implementations, which ants. Starting from left to right, Higgins, Apache Axis2, applied Type 2 messages, where the whole message is and the IBM XS 40 Security Gateway were outfoxed protected by an XML Signature. We depict the attacks by the two depicted permutations. In the first variant on these implementations in Figure 9. In the Guanxi it was sufficient to inject an evil assertion with a dif- and JOSSO implementations the legitimate root element ferent Id attribute in front of the original assertion. As was inserted into the Object element in the original the SAML standard allows to have multiple assertions in Signature. The Signature node was moved into the one protocol element, the XML Schema validation still ER element which also included the new evil assertion. succeeded. The second attack type embedded the orig- In the case of WSO2, it was sufficient to place the orig- inal assertion as a child element into the evil assertion inal root element into the ER object. Naturally, some- EA. In both cases the XML Signature was still standard one would expect that enforcing full document signing conform, as enveloped signatures were applied. This would eliminate XSW completely. The both given ex- was broken in the case of OIOSAML by using detached amples demonstrate that this does not hold in practice. signatures. In this variant the original Signature ele- Again, this highlights the vigilance required when im- ment was moved into the EA, which was inserted be- plementing complex standards such as SAML. fore the legitimate assertion. The last shown permuta- Finally, we did not find vulnerable frameworks that tion was applicable to the cloud services of Salesforce applied Type 3 messages, where both the root and the as- C++ Java sertion are protected by different signatures. Indeed, one Signed Response Response legitimate reason is, that most SAML implementations Processed Extensions do not use Type 3 messages. In our practical evaluation, Assertion ID=“123“ Assertion ID=“123“ only SimpleSAMLphp applied them by default. Never- Signature theless, this does not mean that XSW is not applicable to Assertion ID=“123“ SignedInfo Reference URI=“#123“ Signature this message type in practice. Object SignedInfo Assertion ID=“123“ Reference URI=“#123“ 5.3 OpenSAML Vulnerability Figure 10: XSW attack on OpenSAML library. The attack vectors described above did not work against the prevalently deployed OpenSAML library. The reason
pleSAMLphp, which applied Type 3 messages, we ob- Frameworks / Providers Signing type Signature exclusion Refined XSW Sophisticated XSW Not vulnerable Apache Axis 2 1) X X served that an attacker could forge the outer signature of Guanxi 2) X the response message with any arbitrary key. In short, Higgins 1.x 1) X IBM XS40 1) X the SimpleSAMLphp RP did not verify if the included JOSSO 2) X X certificate in the KeyInfo element is trustworthy at all. WIF 1) X OIOSAML 1) X The key evaluation for the signed assertion was correctly OpenAM 1) X handled. OneLogin 1) X OpenAthens 1) X OpenSAML 1) X Salesforce 1) X 5.5 Secure Frameworks SimpleSAMLphp 3) X WSO2 2) X In our evaluation of real-world SAML implementations we observed that Microsoft Sharepoint 2010 and Simple- Table 2: Results of our practical evaluation show that a SAMLphp were resistant to all applied test cases. Based majority of the analyzed frameworks were vulnerable to on these findings the following questions arise: How the refined wrapping techniques. do these systems implement signature validation? In which way do signature validation and assertion process- ing work together? Due to the fact that the source code of 5.6 Summary Sharepoint 2010 is not publicly available, we were only We evaluated 14 different SAML-based systems. We able to analyze SimpleSAMLphp. found 11 of them susceptible to XSW attacks, while the According to this investigation the main signature majority were prone to refined XSW. One prevalently validation and claims processing algorithm of Simple- used framework (OpenSAML) was receptive to a new, SAMLphp performs the following five steps to counter- more subtle, variant of this attack vector. In addition, act XSW attacks: three out of the tested frameworks were vulnerable to 1. XML Schema validation: First, the whole re- Signature Exclusion attacks. We found two implemen- sponse message is validated against the applied tations, which were resistant against all test cases. The SAML schemas. results obtained from our analysis are summarized in Ta- 2. Extract assertions: All included assertions are ex- ble 2. tracted. Each assertion is saved as a DOM tree in a separate variable. The following steps are only 6 XSW Penetration Test Tool for SAML applied on these segregated assertions. 3. Verify what is signed: SimpleSAMLphp checks, if Motivated on our crucial findings from the extensive each assertion is protected by an enveloped signa- frameworks’ analysis and the vast amount of possible ture. In short, the XML node addressed by the URI attack permutations, we implemented the first fully au- attribute of the Reference element is compared to tomated penetration test tool for XSW attacks in SAML- the root element of the same assertion. The XML based frameworks. In this section we briefly describe Signature in the assertion is an enveloped signature the basic design decisions for our tool. Afterwards, we if and only if both objects are identical. motivate its usage by revisiting the Salesforce SAML in- 4. Validate signature: The verification of every en- terface. This interface yielded a new possibility for an veloped signature is exclusively done on the DOM interesting XSW attack even after a deep investigation tree of each corresponding assertion. with different handcrafted messages. 5. Assertion processing: The subsequent assertion Our tool will be integrated into the WS-Attacker processing is solely done with the extracted and suc- framework5 and offered as open source to support the cessfully validated assertions. huge Web Services and SSO developers’ community. When not considering the signature exclusion bug found in the OpenAthens implementation and its Java- 6.1 Penetration Test Tool based assertions’ processing, this framework was also resistant to all the described attacks. The analysis of its According to the theoretical and practical analysis of dif- implementation showed that it processes SAML asser- ferent SAML frameworks (see Section 4, 5), we gained tions similarly to the above described SimpleSAMLphp the following general knowledge about XSW attacks: framework. 5http://ws-attacker.sourceforge.net • XML Schema validation: Some of the SAML Response Signed frameworks check message conformance to the un- Assertion ID=“123“ Processed
derlying XML schema. Therefore, it is necessary to Signature use XML schema extension points for placing the SignedInfo wrapped content. If the extension elements are not Reference URI=“#123“ provided in the message, they have to be explicitly Audience included. saml.salesforce.com • Order and position: The order and position of Assertion ID=“123“ signed and executed elements in the message tree can force the different processing modules to have Figure 12: A successful XSW attack performed against inconsistent data views. the patched Salesforce SAML interface. • Processing of the Ids: Several SAML frameworks explicitly check, if the Id in the handled assertion is also used in the Reference of the XML Signa- ers can systematically test the security of their (newly) ture. Application of this countermeasure alone does developed SAML libraries. not work, as there is still the option to use more el- ements with equal Ids. 6.2 Salesforce SAML Interface Revisited • Placement of the Signature element: The Signature element can be placed in the newly cre- After reporting the XSW vulnerability to Salesforce, the ated evil assertion or stay in the original assertion security response team developed a simple and promis- (cf. the attacks on Higgins, Apache Axis2 and IBM ing countermeasure: the SAML interface solely accepted XS40 in Figure 8). Both cases must be considered. messages containing one Assertion element6. On re- • Signature exclusion: In three out of 14 frameworks quest of the Salesforce security team, we investigated implementation bugs caused that the signature vali- the fixed SAML interface with handcrafted messages dation step was omitted. containing wrapped contents in different elements. Our • Untrusted signatures: It is essential to check that manual analysis did not reveal any new attack vectors. the signature was created with a trustworthy key. Every message containing more than one Assertion el- Otherwise, the attacker can forge a signature with ement was automatically rejected. Therefore, we first any arbitrary key and embed the corresponding cer- considered this interface to be secure. tificate in the KeyInfo element. A few months later, after finishing the development of our penetration test tool, we decided to retest the Sales- Based on this knowledge, we developed a library, force SAML interface and prove the feasibility of our ap- which allows the systematic creation of a vast amount proach. Surprisingly, the automated penetration test tool of different SAML attack vectors. Its processing can revealed a new successful attack variant by inserting the be summarized in the following steps. First, the library wrapped content into the Audience element – a descen- takes a signed XML document containing a SAML as- dant of the Conditions element. This element typically sertion and analyzes the usage of XML Signature. The contains a URI constraining the parties that can consume element referenced by the signature is stored as a string. the issued assertion. The wrapped message is depicted in Subsequently, it creates a new malicious message includ- Figure 12. As can be seen in the figure, both Assertion ing an evil assertion with modified content (e.g. the elements needed to contain the same Id attribute. NameID and/or Timestamp element). Then, it searches This scientifically interesting attack vector stayed un- dynamically for extension points in the XML Schema analyzed as the Salesforce security team did not expose documents (e.g. XML Schemas for SAML, HTTP bind- any concrete information about their SAML interface. ing, XML Signature, or SOAP). It places the extension However, this finding shows how complex the develop- elements into the malicious message (e.g. a new Object ment of secure signature wrapping countermeasures is. element is created and placed into the given Signature This motivates for further development of automatic pen- element). Afterwards, the library embeds the stored orig- etration test tools for XSW. inal referenced element into each of the possible mali- Salesforce security team afterwards implemented a cious message elements. For each position, a combina- countermeasure, which could successfully mitigate all tion of different attack vectors – considering changes in our attack types. Its details were not revealed. the Ids of the newly created elements and the positions of the Signature elements – are created. For complete- 6This countermeasure is not standard-conform as one message can ness, test cases for signature exclusion and untrusted sig- generally contain several assertions. Therefore, we do not consider this natures are provided. With these attack vectors, develop- remedy in our countermeasure analysis in Section 7. 7.3 Relying Party Model IdP1 Advacc We assume that processing of documents containing IdP RP RP RP 2 sig claims work SAML assertions is split into two parts: (1) XML Sig- RP IdP3 nature verification sig, and (2) SAML security claims processing RP (see Figure 13). This assumption is Advintc claims justified since both parts differ in their algorithmic base, and because this separation was found in all frameworks. Figure 13: Overview of the components in our formal If RPclaims accepts, then the application logic RPwork of model. the Relying Party will deliver the requested resource to the requestor. The XML Signature verification module RPsig is con- 7 Analysis and Countermeasures figured to trust several Identity Provider public keys {pk1,..., pkr}. Each public key defines a trusted do- In order to define what a successful attack on a SAML main within RP. After receiving a signed XML document implementation is, we have to define the possibilities of D, RPsig searches for a Signature element. It applies the adversary, and the event that characterizes a success- the referencing method described in Reference to re- ful attack. We do this in form of a game played between trieve the signed parts of the document, applies the trans- the adversary on one side, and IdP and RP on the other forms described in Transforms to these parts, and com- side. Additionally, we derive two different countermea- pares the computed hash values with the values stored in sures. Their practical application is described in Sec- DigestValue. If all these values match, signature ver- tion 8. 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- 7.1 Data Model fication (eventually alongside D) to RPclaims. The SAML security claims processing module A SAML assertion A can be sent to a Relying Party RP RPclaims may operate a customer database dbRP, and may either as a stand-alone XML document, or as part of a validate SAML assertions against this database. In this larger document D.(D may be a complete SOAP mes- case if the claimed identity is contained in dbRP, the asso- sage, or a SAML Authentication response.) To process ciated rights are granted to the requestor. As an alterna- the SAML assertion(s), the Relying Party (more specifi- tive, RPclaims may rely on authorization data contained in db . In this case, the associated rights will be contained cally, RPclaims) searches for the Assertion element and IdP parses it. We assume that A is signed, either stand-alone, in the SAML assertion, and RPclaims will grant these. or as part of D. Please note that the definition of the winning event given 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 all 7.2 Identity Provider Model cases described in this paper, signature verification was done correctly (as is always the case with XML Signa- We define an Identity Provider IdP to be an entity that is- ture wrapping). Therefore, to be able to formulate mean- sues signed SAML assertions, and that has control over ingful statements about the security of a SAML frame- a single private key for signing. Thus, companies like work, we must make some assumptions on the behavior Salesforce may operate several IdPs, one for each do- of RPclaims. main of customers. There are many possible strategies for RPclaims to pro- An Identity Provider IdP operates a customer database cess SAML assertions: E.g. use the claims from the first dbIdP and is able to perform a secure authentication assertion which is opened during parsing, from the first protocol with any customer contained in this database. that is closed during parsing (analogously for the last as- Furthermore, he has control over a private signing key, sertion opened or closed), or issue an error message if where the corresponding public key is trusted by a set of more than one Assertion element is read. Relying Parties RP := {RP1,...,RPn}, either directly, or through means of a Public Key Infrastructure. After 7.4 Adversarial Model receiving a request from one of the customers registered in dbIdP, and after successful authentication, he may is- Please recall the two different types of adversaries sue a signed XML document D, where the signed part we have mentioned in our threat model in Section 4. contains the requested SAML assertion A. Advintc is the stronger of the two: He has the ability to partially intercept network traffic, e.g. by sniffing HTTP It is straightforward to see that EA is only forwarded traffic on an unprotected WLAN, by reading past mes- to RPclaims if a valid signature for EA is available. sages from an unprotected log file, or by a chosen ci- Please note that although this approach is simple and phertext attack on TLS 1.0 along the lines of [5]. Please effective, it is rarely used in practice due to a number of note that already this adversary is strictly weaker than the subtle implementation problems. A variant of this ap- classical network based attacker known from cryptogra- proach is implemented by SimpleSAMLphp, where the phy. Advacc, our weaker adversary, only has access to RP imposes special requirements on the SAML authen- the IdP and RP, i.e. he may register as a customer with tication response, thus limiting interoperability. We dis- IdP and receive SAML assertions issued about himself, cuss these problems in Section 8. and he may send requests to RP. We define preconditions and success conditions of an 7.6 Countermeasure 2: Mark signed ele- attacker in the form of a game G. If Adv mounts a suc- cessful attack under these conditions, we say that Adv ments wins the game. This facilitates some definitions. In practice, RPsig only returns a Boolean value, and During the game G, the adversary has access to a the whole document D is forwarded to RPclaims. Since validly signed document D containing a SAML assertion IdPhas to serve many different Relying Parties, we as- A issued by IdP. He then generates his own (evil) asser- sume knowledge about the strategy of RPclaims only for tion EA, and combines it arbitrarily with D into an XML RPsig. One possibility to mark signed elements is to hand 0 document D . This document is then sent to RP. over the complete document D from RPsig to RPclaims, plus a description where the validly signed assertions can Definition 1. We say that the adversary (either Advintc or be found. 0 Advacc) wins game G if RP, after receiving document D , A second possibility that is more appropriate for with non-negligible probability Pr(WinAdv) bases its au- SAML is that RPsig chooses a random value r, marks thentication and authorization decisions on the security the validly signed elements with an attribute containing claims contained in EA. r, and forwards r together with the marked document. RP can then check if the assertion processed con- Remark: For all researched frameworks, the winning claims tains r. probability was either negligible or equal to 1. Within the Let us therefore consider the second approach in more term ”negligible” we include the possibility that Adv is- detail. For sake of simplicity we assume that only one sues a forged cryptographic signature, which we assume complete element (i.e. a complete subtree of the XML to be impossible in practice. If an adversary wins the document tree) is signed. game against a specific Relying Party RP, he takes over the trust domain for a specific public key pk within RP. Claim 2. Let Dsig be the signed subtree of D, and l Advacc may do this for all pk where he is allowed to reg- let r ∈ {0,1} be the random value chosen by RPsig IdP ister as a customer with the corresponding who con- and attached to Dsig. Then Pr(WinAdv) is bounded by −l trols (sk, pk). Advintc can achieve this for all pk where he max{breaksig,2 }. is able to find single signed SAML assertion A where the signature can (could in the past) be verified with pk. 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 valid 7.5 Countermeasure 1: Only-process- signature for EA (then r will be attached by RPsig), or by what-is-hashed guessing r and attaching it to EA. We can derive the first countermeasure if we assume that RPsig acts as a filter and only forwards the hashed parts 8 Practical Countermeasures of an XML document to RPclaims. The hashed parts of an XML document are those parts that are serialized as In Section 5.5 we analyzed message processing of Sim- an input to a hash function, and where the hash value is pleSAMLphp. This framework was resistant against all stored in a Reference element. This excludes all parts XSW attacks. One could therefore ask a legitimate ques- of the document that are removed before hash calculation tion: Why do we need further countermeasures and why by applying a transformation, especially the enveloped is it not appropriate to apply the security algorithm of signature transform. SimpleSAMLphp in every system? We want to make clear that SimpleSAMLphp offers Claim 1. If RPsig only forwards the hashed parts of D to both critical functionalities in one framework: signa- RPclaims, then Pr(WinAdv) is negligible. ture validation (RPsig) and SAML assertion evaluation RP sig RPclaims that were validated by the signature verification module Response Response (RPsig). This is not trivial as extracting the unsigned el- Status ements from the message context could make the fur- Assertion ID=“123“ Assertion ID=“123“ ther message processing in some scenarios impossible.
Signature URI=“#123“ Therefore, we propose a solution that excludes only the unsigned elements which do not contain any signed de- Figure 14: The see-what-is-signed approach applied in scendants. We give an example of such a message pro- HTTP POST binding: After successful signature valida- cessing in Figure 14. This way, the claims and message tion the security module RPsig excludes all the unsigned processing logic would get the whole message context: elements and forwards the message to the module pro- in case of SOAP it would see the whole Envelope ele- ment, by application of HTTP POST binding it would be cessing security claims RPclaims and the business logic. able to process the entire Response element. The main advantage of this approach is that the message process- (RPclaims). These two methods are implemented using ing logic does not have to search for validated elements the same libraries and processing modules. After pars- because all forwarded elements are validated. ing a document, the elements are stored within a docu- We want to stress the fact that by application of this ap- ment tree and can be accessed directly. This allows the proach all unsigned character nodes have to be extracted. security developers to conveniently access the same el- Otherwise, the attacker could create an evil assertion EA ements used in signature validation and assertion evalu- and insert the signed original assertion into each element ation steps. However, especially in SOA environments of EA. If RPsig would not extract the character contents there exist scenarios, which force the developers to sep- from EA, RPclaims could process its claims. However, by arate these two steps into different modules or even dif- extracting the unsigned character nodes, the attacker has ferent systems, e.g.: no possibility to insert his evil content, since it was ex- • Using a signature validation library: Before eval- cluded in RPsig. Nevertheless, the subsequent XML mod- uating the incoming assertion elements, the devel- ules can still access the whole XML tree. oper uses a DOM-based signature library, which This idea has already been discussed by Gajek et returns true or false according to the message al. [17]. However, until now no XML Signature validity. However, the developer does not exactly framework implements this countermeasure. It could know which elements were validated. If the as- be applied especially in the context of SAML HTTP sertion evaluation uses a different parsing approach POST bindings because the unsigned elements within (e.g. streaming-based SAX or StAX approach) the SAML response do not contain any data needed or another DOM-library, the message processing in RPclaims. We consider this countermeasure in these could become error-prone. scenarios as appropriate because the SAML standard • XML Security gateways: XML Security gateways only allows the usage of Id-based referencing, exclusive can validate XML Signatures and are configured to canonicalization, and enveloped transformation. The au- forward only validated XML documents. If the de- thors explicitly state that this countermeasure would not veloper evaluates a validated document in his appli- work if XML Signature uses specific XSLT or XPath cation, he again has no explicit information about transformations. the position of the signed element. Synchronization of signature and assertion processing components in 8.2 Unique Identification (Tainting) of this scenario becomes even more complicated, if the developer has no information about the implemen- Signed Data tation of the security gateway (e.g. IBM XS40). The second countermeasure represents another form of These two examples show that a convenient access to the see-what-is-signed approach. The basic idea is to the same XML elements is not always given. Subse- uniquely identify the signed data in the RPsig module quently, we present two practical feasible countermea- and forward this information to the following modules. sures, which can be applied in complex and distributed As described in our formal analysis, this could be done real-world implementations. Both countermeasures re- by generating a random value r, sending it to the next sult from our formal analysis in Section 7. processing module (or as an attribute in the document root element), and attaching it to all the signed elements. 8.1 See-what-is-signed We give an example of this countermeasure applied to a SOAP message in Figure 15. The core idea of this countermeasure is to forward only The main drawback of this countermeasure is that the those elements to the business logic module (RPclaims) SAML XML Schema does not allow the inclusion of Envelope RP Envelope rg=“xy“ RP sig claims contains partial information about the structure of the Header Header SOAP message and the neighborhood of the signed el- Assertion ID=“123“ Assertion ID=“123“ r=“xy“ ement(s). The information preserves the structure of the rg=“xy“ Signature URI=“#123“ Signature URI=“#123“ data to be signed. However, Gajek et al. have shown Signature URI=“#body“ Signature URI=“#body“ that this approach does not prevent XSW attacks [16]. UnsignedContent UnsignedContent Benameur, Kadir, and Fenet [6] have extended the inline Body ID=“body“ Body ID=“body“ r=“xy“ approach, but suffer from the same vulnerabilities. Jensen et al. [24] have analyzed the effectiveness of Figure 15: Unique identification of signed data applied XML Schema validation in terms of fending XSW at- on a SOAP message including two signed elements: The tacks in Web Services. Thereby, they have used man- ually hardened XML Schemas. The authors have con- RPsig module uniquely identifies the signed elements with a random value r and forwards this information cluded that XML Schema validation is capable of fend- along with the whole XML message. ing XSW attacks, at the expense of two important disad- vantages: for each application a specific hardened XML Schema without extension points must be created care- new attributes: neither directly into the Assertion el- fully. Moreover, validating of a hardened XML Schema ement nor the Response binding element. Therefore, entails severe performance penalties. the XML Schema validation of the assertion processing XPath and XPath Filter 2 are specified as referenc- module would fail. For general application of this idea ing mechanisms in the XML Signature standard. How- the SAML XML Schema needs to be extended. ever, the WS-Security standard proposes not to use these Another possibility to implement this countermeasure mechanisms, and the SAML standard mandates to use is to use XML node types, which do not violate XML Id-based referencing instead. This is due to the fact that Schema, but are visible to the XML processors. For both standards are very complex. Gajek et al. [15] have example, processing instructions, which are intended to evaluated the effectiveness of these mechanisms to mit- carry instructions to the application belong to this group. igate XSW attacks in the SOAP context, and have pro- They can be placed anywhere in the document without posed a lightweight variant FastXPath, which has lead invalidating the XML Schema. Additionally, they can to the same performance in a PoC implementation as by be conveniently found by processing XML trees with adapting the Id-based referencing. streaming and DOM-based parsers. Therefore, the pres- Jensen et al. [23] have however shown that this ap- ence of these XML nodes would help to find the vali- proach does not completely eliminate XSW attacks: by dated data and thus allows to mitigate XSW attacks. We clever manipulations of XML namespace declarations propose this technique for further discussion in the W3C within a signed document, which take into account the XML Security Working Group and the OASIS consor- processing rules for canonicalization algorithms in XML tium. Signature, XSW attacks could successfully be mounted even against XPath referenced resources. 9 Related Work The impacts of practical XSW attacks have also been analyzed in [20, 33]. In these works new types of XML Signature Wrapping (XSW). XSW attacks XSW attack have been applied on SOAP Web Service have first been described in [28] and [7]. Several coun- interfaces of Amazon and Eucalyptus clouds. The at- termeasures have been proposed over time. tacks have exploited different XML processing in dis- McIntosh and Austel [28] have presented several XSW tinct modules. attacks and discussed (informal) receiver-sided security In summary, previous work has mostly concentrated policies in order to prevent such exploits. They have on SOAP, and the results do not directly apply to all however not given a definitive solution for this problem. SAML use cases. Bhargavan, Fournet and Gordon [7] have analyzed a formal approach in order to verify Web Services specifi- SAML and Single Sign-On Since SAML offers very cations. They have proposed a policy advisor [8], a tool flexible mechanisms to make claims about identities, that generates appropriate security policies for Web Ser- there is a large body of research on how SAML can be vices protocols. This approach is however not directly used to improve identity management (e.g. [22, 39]) and applicable to SAML. other identity-related processes like payment or SIP on Rahaman, Schaad and Rits [32, 30, 31] have refrained the Internet [25, 35]. In all these applications, the secu- from policy-driven approaches and have introduced an rity of all SAML standards is assumed. inline solution. The authors have proposed to embed an In an overview paper on SAML, Maler and Reed [26] Account element into the SOAP header. This element have proposed mutually authenticated TLS as the basic security mechanism. Please note that even if mutually cessing modules involved can have inconsistent views on authenticated TLS would be employed, it would not pre- the same secured XML document, which may result in vent our attacks because we only need a single signed successful XSW attacks. Generally, these heterogeneous SAML assertion from an IdP, which we can get through views can exist in all data formats beyond XML. different means. Moreover, there exist specific sidechan- We proposed a formal model by analyzing the in- nels, which could be exploited by an adversary. Let us formation flow inside the Relying Party and presented e.g. mention chosen-plaintext attacks against SSL/TLS two countermeasures. The effectiveness of these coun- predicted by [37] and refined by [5], or the Million Ques- termeasures depends on the real information flow and tion attack by Bleichenbacher [9]. Other complications the data processing inside RPclaims. Our research is arise with the everlasting problems with SSL PKIs. a first step towards understanding the implications of In 2003, T. Groß has initiated the security analysis of the information flow between cryptographic and non- SAML [18] from a Dolev-Yao point of view, which has cryptographic components in complex software environ- been formalized in [4]. He has found, together with B. ments. Research in this direction could enhance the re- Pfitzmann [19], deficiencies in the information flow be- sults, and provide easy-to-apply solutions for practical tween the SAML entities. Their work has influenced a frameworks. revision of the standard. As another future research direction, we propose de- In 2008, Armando et al. [3] have built a formal model velopment of an enhanced penetration testing tool for of the SAML 2.0 Web Browser SSO protocol and have XSW in arbitrary XML documents and all types of XML analyzed it with the model checker SATMC. By intro- Signatures. This kind of tool presents a huge challenge ducing a malicious RP they have found a practical at- as it should e.g. consider more difficult transformations tack on the SAML implementation of Google Apps. An- like XPath or XSLT. other attack on the SAML-based SSO of Google Apps has been found in 2011 [2]. Again, a malicious RP has Acknowledgements been used to force a user’s web browser to access a re- The authors would like to thank all the security teams and source without approval. Thereby, the malicious RP has their developers for their cooperation, and would like to injected malicious content in the initial unintended re- note that throughout the collaboration all the teams ef- quest to the attacked RP. After successful authentication fectuated a productive and highly professional commu- on the IdP this content has been executed in the context nication. of the user’s authenticated session. Moreover, we would like to thank Scott Cantor, David The fact that SAML protocols consist of multiple lay- Jorm, Florian Kohlar, Christian Mainka, Christopher ers has been pointed out in [13]. In this paper, the Weak- Meyer, Thomas Roessler, and the anonymous review- est Link Attack has enabled adversaries to succeed at all ers (of the USENIX Security Symposium and the IEEE levels of authentication by breaking only at the weakest Symposium on Security and Privacy) for their valuable one. remarks on the developed attacks and the paper content. Very recently, another work pointing out the impor- Finally, we thank Alexander Bieber for the Sharepoint tance of SSO protocols has been published by Wang et 2010 test bed. al. [38]. This work has analyzed the security quality This work was partially funded by the Sec2 project of of commercially deployed SSO solutions. It has shown the German Federal Ministry of Education and Research eight serious logic flaws in high-profile IdPs and RPs (BMBF, FKZ: 01BY1030). (such as OpenID, Facebook, or JanRain), which have allowed an attacker to sign in as the victim user. The References SAML-based SSO has not been analyzed. [1] IEEE International Conference on Web Services, ICWS 2009, Los Angeles, CA, USA, 6-10 July 2009 (2009), IEEE. 10 Conclusion [2]A RMANDO,A.,CARBONE,R.,COMPAGNA,L.,CUELLAR´ ,J., PELLEGRINO,G., AND SORNIOTTI, A. From Multiple Creden- In this paper we systematically analyzed the application tials to Browser-Based Single Sign-On: Are We More Secure? of XSW attacks on SAML frameworks and systems. We In Future Challenges in Security and Privacy for Academia and Industry, J. Camenisch, S. Fischer-Hbner, Y. Murayama, A. Port- showed that the large majority of systems exhibit criti- mann, and C. Rieder, Eds., vol. 354 of IFIP Advances in Infor- cal security insufficiencies in their interfaces. Addition- mation and Communication Technology. Springer Boston, 2011. ally, we revealed new classes of XSW attacks, which [3]A RMANDO,A.,CARBONE,R.,COMPAGNA,L.,CUELLAR´ , worked even if specific countermeasures were applied. J., AND TOBARRA, M. L. Formal Analysis of SAML 2.0 We showed that the application of XML Security heav- Web Browser Single Sign-On: Breaking the SAML-based Single Sign-On for Google Apps. In Proceedings of the 6th ACM Work- ily depends on the underlying XML processing system shop on Formal Methods in Security Engineering, FMSE 2008, (i.e. different XML libraries and parsing types). The pro- V. Shmatikov, Ed. ACM, Alexandria and VA and USA, 2008. [4]B ACKES,M., AND GROSS, T. Tailoring the dolev-yao abstrac- [21]G UDGIN,M.,HADLEY,M.,MENDELSOHN,N.,MOREAU,J.- tion to web services realities. In SWS (2005), E. Damiani and J., AND NIELSEN, H. F. SOAP Version 1.2 Part 1: Messaging H. Maruyama, Eds., ACM, pp. 65–74. Framework. W3C Recommendation (2003). [5]B ARD, G. V. A Challenging but Feasible Blockwise- [22]H ARDING, P., JOHANSSON,L., AND KLINGENSTEIN, N. Dy- Adaptive Chosen-Plaintext Attack on SSL. In SECRYPT (2006), namic security assertion markup language: Simplifying single M. Malek, E. Fernandez-Medina,´ and J. Hernando, Eds., IN- sign-on. Security Privacy, IEEE 6, 2 (march-april 2008), 83 – STICC Press, pp. 99–109. 85. ENSEN IAO AND CHWENK [6]B ENAMEUR,A.,KADIR, F. A., AND FENET, S. XML Rewrit- [23]J ,M.,L ,L., S , J. The curse of names- ing Attacks: Existing Solutions and their Limitations. In IADIS paces in the domain of xml signature. In SWS (2009), E. Damiani, Applied Computing 2008 (Apr. 2008), IADIS Press. S. Proctor, and A. Singhal, Eds., ACM, pp. 29–36. [24]J ENSEN,M.,MEYER,C.,SOMOROVSKY,J., AND SCHWENK, [7]B HARGAVAN,K.,FOURNET,C., AND GORDON, A. D. Verify- J. On the effectiveness of xml schema validation for counter- ing policy-based security for web services. In CCS ’04: Proceed- ing xml signature wrapping attacks. In Securing Services on the ings of the 11th ACM conference on Computer and communica- Cloud (IWSSC), 2011 1st International Workshop on (sept. 2011), tions security (2004), pp. 268–277. pp. 7 –13. [8]B HARGAVAN,K.,FOURNET,C.,GORDON,A.D., AND [25]L UTZ,D., AND STILLER, B. Combining identity federation with O’SHEA, G. An advisor for web services security policies. In payment: The saml-based payment protocol. In Network Oper- SWS ’05: Proceedings of the 2005 workshop on Secure web ser- ations and Management Symposium (NOMS), 2010 IEEE (april vices (New York, NY, USA, 2005), ACM, pp. 1–9. 2010), pp. 495 –502. [9]B LEICHENBACHER, D. Chosen ciphertext attacks against proto- [26]M ALER,E., AND REED, D. The venn of identity: Options and cols based on the rsa encryption standard pkcs #1. In CRYPTO issues in federated identity management. Security Privacy, IEEE (1998), pp. 1–12. 6, 2 (march-april 2008), 16 –23. [10]C ANTOR,S.,KEMP,J.,MALER,E., AND PHILPOTT, [27]M CINTOSH,M., AND AUSTEL, P. XML Signature Element R. Profiles for the OASIS Security Assertion Markup Wrapping Attacks and Countermeasures. In SWS ’05: Proceed- Language (SAML) V2.0. OASIS Standard, 15.03.2005, ings of the 2005 workshop on Secure web services (New York, 2005. http://docs.oasis-open.org/security/saml/v2. NY, USA, 2005), ACM Press, pp. 20–27. 0/saml-profiles-2.0-os.pdf. [28]M CINTOSH,M., AND AUSTEL, P. XML signature element [11]C ANTOR,S.,KEMP,J.,PHILPOTT,R., AND MALER,E. wrapping attacks and countermeasures. In Workshop on Secure Assertions and Protocol for the OASIS Security Assertion Web Services (2005). Markup Language (SAML) V2.0. OASIS Standard, 15.03.2005, [29]N ADALIN,A.,KALER,C.,MONZILLO,R., AND HALLAM- 2005. http://docs.oasis-open.org/security/saml/v2. BAKER, P. Web Services Security: SOAP Message Security 1.1 0/saml-core-2.0-os.pdf. (WS-Security 2004). OASIS Standard (2006). [12]C ANTOR,S.,MOREH,J.,PHILPOTT,R., AND MALER, [30]R AHAMAN,M.A.,MARTEN,R., AND SCHAAD, A. An inline E. Metadata for the OASIS Security Assertion Markup approach for secure soap requests and early validation. OWASP Language (SAML) V2.0. OASIS Standard, 15.03.2005, AppSec Europe, 2006. 2005. http://docs.oasis-open.org/security/saml/v2. [31]R AHAMAN,M.A., AND SCHAAD, A. Soap-based secure con- 0/saml-metadata-2.0-os.pdf. versation and collaboration. In ICWS (2007), pp. 471–480. [13]C HAN, Y.-Y. Weakest link attack on single sign-on and its case [32]R AHAMAN,M.A.,SCHAAD,A., AND RITS, M. Towards se- in saml v2.0 web sso. In Computational Science and Its Applica- cure soap message exchange in a soa. In Workshop on Secure tions - ICCSA 2006, M. Gavrilova, O. Gervasi, V. Kumar, C. Tan, Web Services (2006). D. Taniar, A. Lagan, Y. Mun, and H. Choo, Eds., vol. 3982 of [33]S OMOROVSKY,J.,HEIDERICH,M.,JENSEN,M.,SCHWENK, Lecture Notes in Computer Science. Springer Berlin / Heidelberg, J.,GRUSCHKA,N., AND IACONO, L. L. All Your Clouds are 2006, pp. 507–516. 10.1007/11751595 54. Belong to us – Security Analysis of Cloud Management Inter- [14]E ASTLAKE,D.,REAGLE,J.,SOLO,D.,HIRSCH, F., AND faces. In The ACM Cloud Computing Security Workshop (CCSW) ROESSLER, T. XML Signature Syntax and Processing (Second (Oct. 2011). Edition), 2008. http://www.w3.org/TR/xmldsig-core/. [34]T HE APACHE SOFTWARE FOUNDATION. Apache Xerces. [15]G AJEK,S.,JENSEN,M.,LIAO,L., AND SCHWENK, J. Analy- [35]T SCHOFENIG,H.,FALK,R.,PETERSON,J.,HODGES,J., sis of signature wrapping attacks and countermeasures. In ICWS SICKER,D., AND POLK, J. Using saml to protect the session [1], pp. 575–582. initiation protocol (sip). Network, IEEE 20, 5 (sept.-oct. 2006), 14 –17. [16]G AJEK,S.,LIAO,L., AND SCHWENK, J. Breaking and fixing [36] VAN DER VLIST,E. XML Schema. O’Reilly, 2002. the inline approach. In SWS ’07: Proceedings of the 2007 ACM workshop on Secure web services (New York, NY, USA, 2007), [37]W AGNER,D., AND SCHNEIER, B. Analysis of the SSL 3.0 pro- ACM, pp. 37–43. tocol. In In Proceedings of the Second USENIX Workshop on Electronic Commerce (1996), USENIX Association, pp. 29–40. [17]G AJEK,S.,LIAO,L., AND SCHWENK, J. Towards a formal semantic of xml signature. W3C Workshop Next Steps for XML [38]W ANG,R.,CHEN,S., AND WANG, X. Signing Me onto Your Signature and XML Encryption, 2007. Accounts through Facebook and Google: a Traffic-Guided Secu- rity Study of Commercially Deployed Single-Sign-On Web Ser- [18]G ROSS, T. Security Analysis of the SAML SSO Browser/Artifact vices. In IEEE Symposium on Security and Privacy (Oakland), Profile. In ACSAC (2003), IEEE Computer Society, pp. 298–307. IEEE Computer Society (May 2012). [19]G ROSS, T., AND PFITZMANN, B. SAML artifact information [39]Y ONG-SHENG,Z., AND JING, Y. Research of dynamic authen- flow revisited. In In IEEE Workshop on Web Services Security tication mechanism crossing domains for web services based on (WSSS) (Berkeley, May 2006), IEEE, pp. 84–100. saml. In Future Computer and Communication (ICFCC), 2010 2nd International Conference on [20]G RUSCHKA,N., AND IACONO, L. L. Vulnerable cloud: Soap (may 2010), vol. 2, pp. V2–395 message security validation revisited. In ICWS [1], pp. 625–631. –V2–398.