Hi, > -----Original Message----- > From: Hunsberger, Peter [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 30, 2003 8:18 AM > To: '[EMAIL PROTECTED]' > 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
