On Breaking SAML: Be Whoever You Want to Be

Juraj Somorovsky1 , Andreas Mayer2 , Jörg Schwenk1 , Marco Kampmann1 , and Meiko Jensen1
1 Horst
Görtz Institute for IT-Security, Ruhr-University Bochum, Germany
2 Adolf
Würth GmbH & Co. KG, Künzelsau-Gaisbach, Germany
{[Link], [Link], [Link], [Link]}@[Link],
[Link]@[Link]

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- C ONTRIBUTION . 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-
SAML A SSERTIONS . 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
based attacker from cryptography: Our adversary may Token
2
Issuing Token
Token
succeed even if he does not control the network. He does 3
Request
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 S INGLE S IGN -O N . 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
R ESPONSIBLE D ISCLOSURE . 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.
O UTLINE . The rest of the paper is organized as fol- S ECURING W EB S ERVICES WITH 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 SAML P ROVIDERS AND F RAMEWORKS . 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 Application
Apache Axis 2 WS Java [Link] WSO2 Web Services
Guanxi Web SSO Java [Link] Sakai Project ([Link])
Higgins 1.x Web SSO Java [Link]/higgins Identity project
IBM XS40 WS XSLT [Link] Enterprise XML Security Gateway
JOSSO Web SSO Java [Link] Motorola, NEC, Redhat
WIF Web SSO .NET [Link] Microsoft Sharepoint 2010
OIOSAML Web SSO Java, .NET [Link] Danish eGovernment (e.g. [Link])
OpenAM Web SSO Java [Link] Enterprise-Class Open Source SSO
OneLogin Web SSO Java, PHP, Ruby, Python [Link] Joomla, Wordpress, SugarCRM, Drupal
OpenAthens Web SSO Java, C++ [Link] UK Federation ([Link])
OpenSAML Web SSO Java, C++ [Link] Shibboleth, SuisseID
Salesforce Web SSO — [Link] Cloud Computing and CRM
SimpleSAMLphp Web SSO PHP [Link] Danish e-ID Federation ([Link])
WSO2 Web SSO Java [Link] eBay, Deutsche Bank, HP

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

<Signature ID?>
XS40, which is applied as an XML Security Gateway. <SignedInfo>
Other examples of closed source frameworks are the <CanonicalizationMethod/>
<SignatureMethod/>
Windows Identity Foundation (WIF) used in Microsoft (<Reference URI? >
Sharepoint and the Salesforce cloud platform. Important (<Transforms>)?
<DigestMethod>
open source frameworks include OpenSAML, OpenAM, <DigestValue>
OIOSAML, OneLogin, and Apache Axis 2. OpenSAML </Reference>)+
</SignedInfo>
is for example used in Shibboleth and the SDK of the <SignatureValue>
electronic identity card from Switzerland (SuisseID). (<KeyInfo>)?
(<Object ID?>)*
OpenAM, formerly known as SUN OpenSSO, is an iden- </Signature>
tity and access management middleware, used in major
enterprises. The OIOSAML framework is e.g. used in
Danish public sector federations (e.g. eGovernment busi- Figure 2: XML Signature data structure (”?”: zero or one
ness and citizen portals). The OneLogin Toolkits inte- occurrence; ”+”: one or more occurrences; ”*”: zero or
grate SAML into various popular open source web appli- more occurrences).
cations like Wordpress, Joomla, Drupal, and SugarCRM.
Moreover, these Toolkits are used by many OneLogin
customers (e.g. Zendesk, Riskonnect, Zoho, Knowl-
edgeTree, and Yammer) to enable SAML-based SSO.
Apache Axis2 is the standard framework for generating
and deploying Web Service applications. An XML Signature is represented by the Signature
element. Figure 2 provides its basic structure. XML
Signatures are two-pass signatures: the hash value of
3 Technical Foundations the resource (DigestValue) along with the used hash
algorithm (DigestMethod) and the URI reference to
In this section we briefly introduce the SAML standard the resource are stored in a Reference element. Ad-
and XML Signature wrapping attacks. Additionally, for ditionally, the Transforms element specifies the pro-
readers unfamiliar with the relevant W3C standards, we cessing steps which are applied prior to digesting of
present XML Signature [14] and XML Schema [36]. the resource. Each signed resource is represented by
a Reference element in the SignedInfo element.
3.1 XML Signature Therefore, SignedInfo is a collection of hash val-
ues and URIs. The SignedInfo itself is protected
The XML Signature standard [14] defines the syntax and by the signature. The CanonicalizationMethod and
processing rules for creating, representing, and verifying the SignatureMethod element specify the algorithms
XML-based digital signatures. It is possible to sign a used for canonicalization and signature creation, and are
whole XML tree or only specific elements. One XML also embedded in SignedInfo. The Base64-encoded
Signature can cover several local or global resources. value of the computed signature is deposited in the
A signature placed within the signed content is called SignatureValue element. In addition, the KeyInfo el-
an enveloped signature. If the signature surrounds the ement facilitates the transport of signature relevant key
signed parts, it is an enveloping signature. A detached management information. The Object is an optional el-
signature is neither inside nor a parent of the signed data. ement that may contain any data.
<saml:Assertion Version ID IssueInstant> Binding root element R
Envelope Signed
<saml:Issuer>
<ds:Signature>? Header Processed
Response
<saml:Subject>?
<saml:Conditions>? Assertion ID=“123“
Assertion ID=“123“
<saml:Advice>?
Signature
<saml:AuthnStatement>* Signature
<saml:AuthzDecisionStatement>* SignedInfo
SignedInfo
<saml:AttributeStatement>* Reference URI=“#123“
</saml:Assertion> Reference URI=“#123“
Body

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
SignedInfo
A1 S1 EA
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 Advintc may
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
that underlies our analysis of the 14 frameworks.1 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
SAML message. This could be a single assertion A or a signature with Id-based referencing. In this section we
whole document D 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
evil assertion EA. 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-
1. Advacc . To obtain an assertion, this attacker regis- sertions is to insert the XML Signature S1 as a
ters as a user of an Identity Provider IdP. Advacc child of the SAML assertion A1 and sign only the
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-
2. Advintc . This adversary retrieves SAML assertions tion A1 or directly into the protocol binding root ele-
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
1 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

A1 EA EA S1
4.3 Attack Permutations
S1 S1 A1
A1
The attacker has many different possibilities where to in-
EA S1 A1 EA
sert the malicious and the original content. To this end,
he has to deal with these questions:
3) Two Levels (12 Permutations)
a) b) c) d)
• At which level in the XML message tree should the
R R R R
malicious content and the original signed data be
included? EA A1 EA A1 A1 EA A1 EA
• Which Assertion element is processed by the as-
S1 S1 S1 S1
sertion logic?
• 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
Root ID=“evil“ Root ID=“evil“
works were vulnerable to these attacks: Apache Axis2
Signature Root ID=“123“
Web Services Framework, JOSSO, and the Java-based 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 Extensions
Processed

Assertion ID=“123“
do not use Type 3 messages. In our practical evaluation, Assertion ID=“123“
Signature
only SimpleSAMLphp applied them by default. Never-
Assertion ID=“123“ SignedInfo
theless, this does not mean that XSW is not applicable to Reference URI=“#123“
Signature
this message type in practice. SignedInfo
Object

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 <element name="Extensions" type="samlp:ExtensionsType"/>
was that OpenSAML compared the Id used by the signa- <complexType name="ExtensionsType">
<sequence>
ture validation with the Id of the processed assertion. If <any namespace="##other" processContents="lax"
these identifiers were different (based on a string compar- maxOccurs="unbounded"/>
</sequence>
ison), the signature validation failed. Additionally, XML </complexType>
messages including more than one element with the same
Id were also rejected. Both mechanisms are handled in
OpenSAML by using the Apache Xerces library and its Figure 11: XML Schema definition of the Extensions
XML Schema validation method [34]. Nevertheless, it element.
was possible to overcome these countermeasures with a
more sophisticated XSW attack. e.g. the Extensions element for the C++ library, whose
As mentioned before, in OpenSAML the Apache XML Schema is defined in Figure 11. However, the
Xerces library performs a schema validation of every in- Extensions element is not the only possible position for
coming XML message. Therefore, the Id of each el- our wrapped content. The schemas of SAML and XML
ement can be defined by using the appropriate XML Signature allow more locations (e.g. the Object element
Schema file. This allows the Xerces library to iden- of the Signature, or the SubjectConfirmationData
tify all included Ids and to reject messages with Id and Advice elements of the Assertion).
values which are not unique (e.g. duplicated). How- The previously described behavior of the XML
ever, a bug in this library caused that XML elements schema validation forced OpenSAML to use the wrapped
defined with xsd:any content were not processed cor- original assertion for signature validation. In contrast,
rectly. More concretely, the content of the elements the application logic processed the claims of the evil as-
defined as <xsd:any processContents="lax"> were sertion. In Figure 10, we present the concrete attack mes-
not checked using the defined XML Schema. Therefore, sages of this novel XSW variant.
it was possible to insert elements with arbitrary – also
The successful attack on OpenSAML shows that coun-
duplicated – Ids inside an XML message. This created a
tering the XSW attack can become more complicated
good position for our wrapped content.
than expected. Even when applying several countermea-
It is still the question which of the extensible elements
sures, the developer should still consider vulnerabilities
could be used for the execution of our attacks. This de-
in the underlying libraries. Namely, one vulnerability in
pends on two processing properties:
the XML Schema validating library can lead to the exe-
1. Which element is used for assertion processing? cution of a successful XSW attack.
2. Which element is validated by the security module,
if there are two elements with the same Id?
5.4 Various Implementation Flaws
Interestingly, the two existing implementations of
Apache Xerces (Java and C++) handled element deref- While reviewing the OneLogin Toolkit, we discovered
erencing differently. another interesting flaw: the implementation did not care
For C++, the attacker had to ensure that the original about what data was actually signed. Therefore, any con-
signed assertion was copied before the evil assertion. In tent signed by the IdP was sufficient to launch a XSW
the Java case, the legitimate assertion had to be placed attack. In our case we used the metadata of the IdP 2 and
within or after the evil assertion. In summary, if two created our own self-made response message to success-
elements with the same Id values occurred in an XML fully attack OneLogin.
message, the XML security library detected only the first 2 The SAML Metadata [12] describes properties of SAML entities
(for C++) or the last (for Java) element in the message. in XML to allow the easy establishment of federations. Typically, the
This property gave the attacker an opportunity to use metadata is signed by the issuer and publicly available.
 Not vulnerable
Besides the fact that a SAML system has to check

Refined XSW

Sophisticated
Signing type
what data is signed, it is also essential to verify by whom

Signature
exclusion
the signature was created. In an early version of Sim-

XSW
pleSAMLphp, which applied Type 3 messages, we ob- Frameworks / Providers
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- framework3 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. 3 [Link]
 • 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

[Link]
included.
Assertion
• Order and position: The order and position of 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 element4 . 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- 4 This 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.
 IdP1 Advacc 7.3 Relying Party Model
IdP2 RPsig RPclaims RPwork
We assume that processing of documents containing
SAML assertions is split into two parts: (1) XML Sig-
IdP3 nature verification RPsig , and (2) SAML security claims
Advintc processing RPclaims (see Figure 13). This assumption is
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
cally, RPclaims ) searches for the Assertion element and dbIdP . In this case, the associated rights will be contained
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
document D0 . 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.
Advacc ) wins game G if RP, after receiving document D0 , 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.
RPclaims can then check if the assertion processed con-
Remark: For all researched frameworks, the winning
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
Advacc may do this for all pk where he is allowed to reg- let r ∈ {0, 1}l be the random value chosen by RPsig
ister as a customer with the corresponding IdP who con- and attached to Dsig . Then Pr(WinAdv ) is bounded by
trols (sk, pk). Advintc can achieve this for all pk where he max{breaksig , 2−l }.
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
 RPsig 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-
cessing security claims RPclaims and the business logic. ment, by application of HTTP POST binding it would be
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.
We give an example of this countermeasure applied to a
8.1 See-what-is-signed
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 RPsig Envelope rg=“xy“ RPclaims 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
Signature URI=“#123“
rg=“xy“
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-
RPsig module uniquely identifies the signed elements ually hardened XML Schemas. The authors have con-
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.
The impacts of practical XSW attacks have also been
9 Related Work
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., C ARBONE , R., C OMPAGNA , L., C U ÉLLAR , J.,
P ELLEGRINO , G., AND S ORNIOTTI , A. From Multiple Creden-
In this paper we systematically analyzed the application tials to Browser-Based Single Sign-On: Are We More Secure?
In Future Challenges in Security and Privacy for Academia and
of XSW attacks on SAML frameworks and systems. We
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., C ARBONE , R., C OMPAGNA , L., C U ÉLLAR ,
worked even if specific countermeasures were applied. J., AND T OBARRA , M. L. Formal Analysis of SAML 2.0
Web Browser Single Sign-On: Breaking the SAML-based Single
We showed that the application of XML Security heav- 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] BACKES , M., AND G ROSS , T. Tailoring the dolev-yao abstrac- [21] G UDGIN , M., H ADLEY, M., M ENDELSOHN , N., M OREAU , J.-
tion to web services realities. In SWS (2005), E. Damiani and J., AND N IELSEN , H. F. SOAP Version 1.2 Part 1: Messaging
H. Maruyama, Eds., ACM, pp. 65–74. Framework. W3C Recommendation (2003).
[5] BARD , G. V. A Challenging but Feasible Blockwise- [22] H ARDING , P., J OHANSSON , L., AND K LINGENSTEIN , N. Dy-
Adaptive Chosen-Plaintext Attack on SSL. In SECRYPT (2006), namic security assertion markup language: Simplifying single
M. Malek, E. Fernández-Medina, and J. Hernando, Eds., IN- sign-on. Security Privacy, IEEE 6, 2 (march-april 2008), 83 –
STICC Press, pp. 99–109. 85.
[6] B ENAMEUR , A., K ADIR , F. A., AND F ENET, S. XML Rewrit- [23] J ENSEN , M., L IAO , L., AND S CHWENK , 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., M EYER , C., S OMOROVSKY, J., AND S CHWENK ,
[7] B HARGAVAN , K., F OURNET, C., AND G ORDON , 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., F OURNET, C., G ORDON , A. D., AND [25] L UTZ , D., AND S TILLER , B. Combining identity federation with
O’S HEA , 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 R EED , 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., K EMP, J., M ALER , E., AND P HILPOTT, [27] M C I NTOSH , 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. [Link] NY, USA, 2005), ACM Press, pp. 20–27.
0/[Link]. [28] M C I NTOSH , M., AND AUSTEL , P. XML signature element
[11] C ANTOR , S., K EMP, J., P HILPOTT, R., AND M ALER , 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] NADALIN , A., K ALER , C., M ONZILLO , R., AND H ALLAM -
2005. [Link] BAKER , P. Web Services Security: SOAP Message Security 1.1
0/[Link]. (WS-Security 2004). OASIS Standard (2006).
[12] C ANTOR , S., M OREH , J., P HILPOTT, R., AND M ALER , [30] R AHAMAN , M. A., M ARTEN , R., AND S CHAAD , 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. [Link] [31] R AHAMAN , M. A., AND S CHAAD , A. Soap-based secure con-
0/[Link]. 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., S CHAAD , A., AND R ITS , 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., H EIDERICH , M., J ENSEN , M., S CHWENK ,
Lecture Notes in Computer Science. Springer Berlin / Heidelberg, J., G RUSCHKA , N., AND I ACONO , 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., R EAGLE , J., S OLO , D., H IRSCH , F., AND faces. In The ACM Cloud Computing Security Workshop (CCSW)
ROESSLER , T. XML Signature Syntax and Processing (Second (Oct. 2011).
Edition), 2008. [Link] [34] T HE A PACHE S OFTWARE F OUNDATION. Apache Xerces.
[15] G AJEK , S., J ENSEN , M., L IAO , L., AND S CHWENK , J. Analy- [35] T SCHOFENIG , H., FALK , R., P ETERSON , J., H ODGES , J.,
sis of signature wrapping attacks and countermeasures. In ICWS S ICKER , D., AND P OLK , 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., L IAO , L., AND S CHWENK , J. Breaking and fixing
[36] VAN DER V LIST , 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] WAGNER , D., AND S CHNEIER , 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., L IAO , L., AND S CHWENK , J. Towards a formal
semantic of xml signature. W3C Workshop Next Steps for XML [38] WANG , R., C HEN , 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 P FITZMANN , B. SAML artifact information [39] YONG - SHENG , Z., AND J ING , 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
[20] G RUSCHKA , N., AND I ACONO , L. L. Vulnerable cloud: Soap 2nd International Conference on (may 2010), vol. 2, pp. V2–395
message security validation revisited. In ICWS [1], pp. 625–631. –V2–398.