On Wed, 2003-01-29 at 22:35, J.Pietschmann wrote:
> Stefano Mazzocchi wrote:
> > Another possibility would be to have the XSLT transformer being 'locked'
> > and avoid accessing anything that is not included in the stylesheet
> > (that means: forbidding document() and extensions, maybe imports too)
> >
> > maybe the xalan team has something ready for this already?
>
> There is already the URIResolver where you can hook in your
> URL access policy. DoS atttacks could still be a nuisance
> though.
Could I turn the handle the URIResolver specificaly for certain
Transformers or would any changes effect the entire cocoon application?
What kind of DoS attacks would you expect?
>
> Certain extension elements and functions already provided by
> the XSLT processor are also a concern, in Saxon you can turn
> them off summarily by a configuration setting.
Again, would this end up being application wide or could you deal with
this for on Transformer only.
>
> J.Pietschmann
>
I would want to implement a pipeline as follows:
<map:match pattern="*/x.html">
<map:generate src="x.xml"/>
<map:transform src="files/{1}/x.xsl/>
<map:serialize type="html"/>
</map:match>
Where the files directory would contain a user's directory which user's could upload
there own versions of the stylesheets, ie. skins
I would want to define a specific transformer that would not affect the
transformations in the rest of the application but would limit the user to using basic
xsl transformations or to limit the user to his xsl file and that alone. I wouldn't
want the user to have access to any external resources like Java classes or other
documents.
Having just written that sentance, I realise that a user would be able to insert an
endless recursive template which would kill the application. Could this be resolved by
monitoring the stylesheet from another thread, killing it if it takes too long and
then removing that user's stylesheets? I would then probably use an input mondule
chain to resolve to a default set of stylesheets.
Does anyone have any ideas on how to implement this safely or is it just a bad idea?
TIA
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
