Reconfiguration of user-provided XSLT

Question

We have an application that uses XSLT to format XML data for display as XHTML.

The system is able to handle arbitrary XML schemas, so users and users need to download Schemas and XSLT. It is clear that this is a task that is allowed only to users of the administrator level, however it is also a rather large bullish look, so I tried to make it more secure.

I must mention that we use Saxon 9.0 B

Is there any standard way to sanitize a user-provided XSLT? So far I have identified three possible questions, although I understand that there may be more that I simply did not think about:

• xsl: the import and document () functions can get into the server file system. It's pretty easy to block with a custom URI resolver, so I'm sure I have this

• output may contain javascript. I am thinking of using something like OWASP Anti-Samy to whitelist valid output tags.

• XSLT can call java functions. This is the one that is currently causing me a headache. I don’t want to completely disable this ability (although at the moment I don’t even see how to do it), because we use it. My preferred solution would be to block valid Java namespaces so that only known safe functions can be executed. However, I am open to other suggestions.

The Gold Standard will be a standard library that will handle all known XSLT-based vulnerabilities, but will not accept any suggestions to solve the above problems (especially 3).

Thank you in advance

Answer 1

Saxon has a configuration option to disable the use of "reflective" (dynamically loaded) extension functions. This does not preclude the use of "integrated" extension functions that have been explicitly registered in the configuration through the API. This seems to fit your requirements, allowing the service provider to register extension functions, but not allowing the style author to do so.

You can be even more selective if you want by defining your own JavaExtensionFunctionFactory to control how the calls to the extension functions are related. This is a fairly low-level system programming, and you probably need to study the source code to find out what methods you need to override to meet your needs.

Like document (), you need to consider the collection () method, unparsed-text (), xsl: result-document. In all cases, there are Saxon hooks that allow you to control behavior.

Answer 2

I do not think that downloading and executing any XSLT on the server is something reasonable to do .

There are things that cannot be prevented or detected, for example, Denial Of Service attack, for example:

• Infinite recursion, which swallows all available memory and issues a server with stack overflow.

• A conversion that takes many minutes or hours — because the stopping problem is unsolvable, we don’t know if this is a deliberate continuous cycle or an accidental programmer error, or a calculation that may or may not converge.

There are, of course, many other exploits, such as references to a recursively defined object ...