File:MA3 .jpg and XSLT Attack: Difference between pages

From Single Sign-On Attacks
(Difference between pages)
Jump to navigation Jump to search
No edit summary
 
 
Line 1: Line 1:
=Introduction=
[https://en.wikipedia.org/wiki/XSLT ''Extensible Stylesheet Language Transformation (XSLT)''] is a language for transforming XML documents into other documents, for example, XML, HTML, JSON or even PDF. The XML Signature standard allows the usage of ''XSLT'' by definition, and thus, ''XSLT'' can be used in [http://www.sso-attacks.org/index.php?title=SAML SAML]. ''XSLT'' is a Turing complete language. By this means, it is possible to use XSLT, for example, to read/write files on the local filesystem and send them over the Internet. Furthermore, the ''XSLT'' transformation will be executed before the digital signature is verified. Thus, an attacker can send a ''SAML'' token including a digital signature containing the ''XSLT Attack (XSLTA)'' vector, but it is not required that the signature is valid. XSLTA allows accessing files within the context of the used web server.


=Attack subtypes=
There are no attack subtypes for this attack.
=Prerequisites=
In order to start XSLT, the attacker has to create a valid XML message. Note, that the message has to be a SAML token. However, this token does not have to be signed with a valid key nor does the signature needs to be valid.
=Target=
[[File:Target_Verificator.jpg|centre|600px]]
<br> The attacked Single Sign-On component is marked in red colour.
=Description=
[[File:XSLT.jpg|centre|650px]] <br>
The attacker prepares a SAML token ''t'' and creates an XML Signature for it. Note, that it is not important to have a correctly computed signature value – the ''XSLTA'' only requires a well-formed XML document. The attacker adds a '''Transform''' element to the XML Signature and places the '''XSLT Payload''' in it as shown in Figure. <br>
[[File:XSLT1.jpg|centre]]
The attacker reads an arbitrary file using ''XSLT'' (in this example by using the ''unparsed-text()'' function). Afterwards, he forwards the contents of the file to his own server via a ''GET'' parameter.
=Mitigation / Countermeasures=
The [https://en.wikipedia.org/wiki/Single_sign-on SSO] Verificator should mitigate the usage of ''XSLT'' within the token.
=Practical Examples=
In 2014, Mainka et al. analyzed 22 Software as a Service cloud providers and found out that one framework was vulnerable to this attack: Instructure.
[[Category:Attack_Categorisation_By_Attacker_Model:_Message_generation_attacks]]
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Confidentiality]]
[[Category:Attack_Categorisation_By_Attack_on_IdP/_SP:_Attack_on_SP]]
[[Category:Attack_Categorisation_By_Attacked_Single_Sign-On_Component:_Verificator]]
[[Category:Attack_Categorisation_By_Attack_Spreading:Application_Specific_Flaws]]
[[Category:Attack_Categorisation_By_Attack_on_SAML]]
=References=
C. Mainka, V. Mladenov, F. Feldmann, J. Krautwald, J. Schwenk (2014): Your Software at my Service: Security Analysis of SaaS Single Sign-On Solutions in the Cloud. In The ACM Cloud Computing Security Workshop (CCSW).

Revision as of 16:36, 2 February 2016

Introduction

Extensible Stylesheet Language Transformation (XSLT) is a language for transforming XML documents into other documents, for example, XML, HTML, JSON or even PDF. The XML Signature standard allows the usage of XSLT by definition, and thus, XSLT can be used in SAML. XSLT is a Turing complete language. By this means, it is possible to use XSLT, for example, to read/write files on the local filesystem and send them over the Internet. Furthermore, the XSLT transformation will be executed before the digital signature is verified. Thus, an attacker can send a SAML token including a digital signature containing the XSLT Attack (XSLTA) vector, but it is not required that the signature is valid. XSLTA allows accessing files within the context of the used web server.

Attack subtypes

There are no attack subtypes for this attack.

Prerequisites

In order to start XSLT, the attacker has to create a valid XML message. Note, that the message has to be a SAML token. However, this token does not have to be signed with a valid key nor does the signature needs to be valid.

Target


The attacked Single Sign-On component is marked in red colour.

Description

File:XSLT.jpg


The attacker prepares a SAML token t and creates an XML Signature for it. Note, that it is not important to have a correctly computed signature value – the XSLTA only requires a well-formed XML document. The attacker adds a Transform element to the XML Signature and places the XSLT Payload in it as shown in Figure.

The attacker reads an arbitrary file using XSLT (in this example by using the unparsed-text() function). Afterwards, he forwards the contents of the file to his own server via a GET parameter.

Mitigation / Countermeasures

The SSO Verificator should mitigate the usage of XSLT within the token.

Practical Examples

In 2014, Mainka et al. analyzed 22 Software as a Service cloud providers and found out that one framework was vulnerable to this attack: Instructure.

References

C. Mainka, V. Mladenov, F. Feldmann, J. Krautwald, J. Schwenk (2014): Your Software at my Service: Security Analysis of SaaS Single Sign-On Solutions in the Cloud. In The ACM Cloud Computing Security Workshop (CCSW).

File history

Click on a date/time to view the file as it appeared at that time.

Date/TimeThumbnailDimensionsUserComment
current16:27, 2 February 2016Thumbnail for version as of 16:27, 2 February 2016430 × 343 (44 KB)Anna (talk | contribs)