cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Koberg" <...@koberg.com>
Subject RE: XSL Security question
Date Thu, 30 Jan 2003 17:15:05 GMT
Hi,

> -----Original Message-----
> From: Hunsberger, Peter [mailto:Peter.Hunsberger@stjude.org]
> Sent: Thursday, January 30, 2003 8:18 AM
> To: 'cocoon-dev@xml.apache.org'
> Subject: RE: XSL Security question
>
>
> > There are definitely situations where you need to have project defined
> XSLT.
>
> Possibly so, but "skins" shouldn't be one of them?  Just out of interest can
> you give a concrete example?

What is a "skin" to you? Some sites need dramatically different XSLT to produce
their final result.

Site 1 needs to use an HTML 4.01 table based layout with pixel precision to sew
together images to produce a flashy kind of site.

Site 2 wants to use XHTML 1.0 CSS layout and does not require pixel precision.

The skinning of the site is done in two completely different layouts (and output
types).

How would you do this without different skins?

>
> > We use a comination of chroot jails (if shell access) and URIResolvers to
> keep the
> > dev-user where they should be. Also, since we use Saxon, we turn off
> extensions
> > with:
>
> <snip>
>
> > What am I missing? :-o
>
> Got me, but I'd guess an infinitely looping XSLT DOS attack is a potential
> problem?

The infinte recursion:

<xsl:template match="page">
  <xsl:apply-templates select="parent::folder"/>
</xsl:template>

<xsl:template match="folder">
  <xsl:apply-templates select="page"/>
</xsl:template>

is a problem. The Resin servlet container gives up after too many recursive
calls and sends a stack trace to the client.

In our setup, developers work on their XSLT on their local machine. They can see
the result of their changes from a simple, standard XSL command line invocation.
Or they can use a simple LSB app to generate the site locally. When they
(hopefully...) work out the bugs they upload the files to the server. Since they
are using their own XSLT, only their project will have the bug.

That being said, we have been very selective as to who we take on as a client
(we are a pretty small company). I have turned away potential clients that I
found suspicious. And we have been doing most the XSL(T)...

> Other than that, if Saxon (or the underlying Java engine) has any
> potential buffer overflow problems, or other Sandbox leaks then you've given
> people a nice Worm building environment (since XSLT is Turing complete)...

Wouldn't this be a problem with anything?

-Rob


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message