Re: [xsl] Allowing users to upload XSLT

[Abel Braaksma <abel.online@xxxxxxxxx>]

Adding to what's already said by Bryan, consider that looping is not 
always breakable (or, easily breakable). For instance in XSLT 2.0, a 
regular expression may loop forever and, iirc, most implementations do 
not allow to nicely break out an infinitely backtracking regex.

But you use libxslt, this implies xslt 1.0 of course. Iirc, it is 
possible to enable exslt extensions for it, but I would recommend 
against it because of possible security problems, definitely with 
node-set...

Infinite loops may be breakable, but what about memory size? It is quite 
easy to create a rather small XSLT file and let it consume all memory 
quickly. Consider the following snippet:

       <xsl:for-each select="document('')//node()">
           <xsl:for-each select="document('')//node()">
               <xsl:for-each select="document('')//node()">
                   <xsl:copy-of select="document('')" />
               </xsl:for-each>               
           </xsl:for-each>           

       </xsl:for-each>


Depending on how your processor treats this, this may easily end up in 
an XML file of 200M or higher and likewise it may require a lot of 
memory to process it. I tested it with saxon, which stayed pretty cool 
about it (took quite a long time to run though), and of course, it is 
easy in Java to restrict the memory usage.

Consider the same snippet as a node-set and that it is applied again. No 
infinite loops, no too-deeply nested apply-template calls, but a 
memory-swapping system...

This is just a simple example, I reckon when somebody wants something 
bad, he/she can easily freeze up your system when you give him/her full 
control over the XSLT and/or XPath.

Cheers,
-- Abel

Andrew Mason wrote:
> I was wondering if there were  any security considerations with allowing users 
> to upload their own XSLT? 
> I'm using libxsl which seems to guard against infinite loops etc.. but i was 
> unsure if there were other things which I should consider from a security 
> pov.