You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Andrew Timberlake <an...@timberlake.co.za> on 2003/01/29 11:11:02 UTC
XSL Security question
I don't know all the capabilities of XSL and would like to know if there
is a security risk in allowing users to upload any XSL files to be used
in a 'skins' type of application?
My one concern would be using the document('') methods to load and
display other files from the system?
If this is not a good idea, can we sandbox an xsl transformer somehow?
Any thoughts are most welcome.
Andrew
I have never let my schooling interfere with my education
--Mark Twain
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Using the results of an aggregate part - order of execution.
Posted by Tony Culshaw <to...@cultech.com.au>.
I've been through this a million times (well er maybe not QUITE that many,
but near enough ) and I can't figure out how to do it without something
like an action pipeline as I suggested. The session action won't work in
this case because I need pipeline processing.
What I'm actually doing is roughly....
1) In APPLICATION, A within the AUTHENTICATION framework, click on a
button to 'do Task B in APPLICATION C.
2) In order to do task B in C I have to (i) call a remote system to
prefill an xmlform and then (ii) call up the xmlform action to actually
start off task B in C.
In addition the xmlform is the cocoon xmlform modified to bind to xml data
within the session rather than a bean (ie. the model is xml within a
session context rather than a compiled series of java beans).
No matter how much I juggle around with the components I still always come
up with the fact that the best place to implement the 2i step above is in
a pipeline, but I can't run the pipeline prior to step 2ii because step
2ii is an action that will be executed before the pipeline transforms I
need to achieve 2i. Ugh!
Can anyone suggest a better way because my pipeline action component seems
to be doing the job (ugly as it is)?
Maybe I should get into the Cocoon Servlet and start playing around with
servlet chaining??
> Tony Culshaw wrote:
>
>>What's interesting here is that an aggregate still does the cocoon
>> thing whereby MATCHERS ACTORS and SELECTORS are executed FIRST even
>> down through the aggregate parts (ie. internal pipelines) and then and
>> only then is the pipeline processor assembled with GENERATORS (inc
>> aggregators),
>>TRANSFORMERS and SERIALIZERS. The processor is then executed. This is
>> one of the biggest hurdles to overcome for anyone starting out with
>> this framework in terms of understanding.
>>
>>This ultimately means that (in this example) any attempt to modify
>> session contexts in a part1 TRANSFORM of an aggregate will not be
>> visible by a part2 ACTION because the part2 ACTION is excecuted BEFORE
>> the part1 TRANSFORMER.
>>
>>
>
> I have not seen start of this thread... But I guess you are talking
> about session-fw here and its session transformer.
>
> You want to first invoke session transformer and then some action and
> then something else, but it rightly does not work this way.
>
>
>>To summarise in pseudo sitemap code...
>>
>><aggregate>
>> <part1 src="cocoon:/part1/>
>> <part2 src="cocoon:/part2/>
>></aggregate>
>>
>><part1>
>> <action1/>
>> <transform1/>
>></part1>
>>
>><part2>
>> <action2/>
>> <transform2/>
>></part2>
>>
>>The order of execution of components above will be action1, action2,
>> transform1, transform2.
>>
>>
>>Maybe the forthcoming flow stuff will help here, but I'm not sure.
>>
>>However, there is another solution, but it involves a writing an
>>additional component and may be viewed by cocoon purists as a hack:)
>>
>>
>
> It's a hack not only by purists's views! Correct solution here is to not
> use session-fw transformer but session-fw action. Thus, everything you
> want to do before invoking the pipeline will be done ... well ... before
> invoking the pipeline, and no hacks like this will be required.
>
> Another IMHO brought to you by... :)
>
> Vadim
>
>
>
>>We (the company I'm currently contracting to) intend to release as a
>> block a number of utility components, one of which is a Pipeline
>> Action. This may upset some Cocoon purists but it is an action which
>> calls a pipeline (effectively a new http request back into the
>> framework).
>>
>>This allows the called pipeline to FULLY execute (including transfomers
>> which may update session contexts), prior to whatever follows in the
>> rest of the caller's pipeline.
>>
>>The only issue (if it is an issue) is that the result of the called
>> pipeline , ie. the serialized output, is discarded. This doesn't matter
>> if the only desire is to upadet th econtents of a session context.
>>
>>I'll try and get a sample out in the next few nights if anyone's
>> interested.
>>
>>Also, if anyone thinks this is really bad cocoon please let me know - I
>> guess it could be open to abuse.
>>
>>
>
>
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Using the results of an aggregate part - order of execution.
Posted by Vadim Gritsenko <va...@verizon.net>.
Tony Culshaw wrote:
>What's interesting here is that an aggregate still does the cocoon thing
>whereby MATCHERS ACTORS and SELECTORS are executed FIRST even down through
>the aggregate parts (ie. internal pipelines) and then and only then is the
>pipeline processor assembled with GENERATORS (inc aggregators),
>TRANSFORMERS and SERIALIZERS. The processor is then executed. This is one
>of the biggest hurdles to overcome for anyone starting out with this
>framework in terms of understanding.
>
>This ultimately means that (in this example) any attempt to modify session
>contexts in a part1 TRANSFORM of an aggregate will not be visible by a
>part2 ACTION because the part2 ACTION is excecuted BEFORE the part1
>TRANSFORMER.
>
>
I have not seen start of this thread... But I guess you are talking
about session-fw here and its session transformer.
You want to first invoke session transformer and then some action and
then something else, but it rightly does not work this way.
>To summarise in pseudo sitemap code...
>
><aggregate>
> <part1 src="cocoon:/part1/>
> <part2 src="cocoon:/part2/>
></aggregate>
>
><part1>
> <action1/>
> <transform1/>
></part1>
>
><part2>
> <action2/>
> <transform2/>
></part2>
>
>The order of execution of components above will be action1, action2,
>transform1, transform2.
>
>
>Maybe the forthcoming flow stuff will help here, but I'm not sure.
>
>However, there is another solution, but it involves a writing an
>additional component and may be viewed by cocoon purists as a hack:)
>
>
It's a hack not only by purists's views! Correct solution here is to not
use session-fw transformer but session-fw action. Thus, everything you
want to do before invoking the pipeline will be done ... well ... before
invoking the pipeline, and no hacks like this will be required.
Another IMHO brought to you by... :)
Vadim
>We (the company I'm currently contracting to) intend to release as a block
>a number of utility components, one of which is a Pipeline Action. This
>may upset some Cocoon purists but it is an action which calls a pipeline
>(effectively a new http request back into the framework).
>
>This allows the called pipeline to FULLY execute (including transfomers
>which may update session contexts), prior to whatever follows in the rest
>of the caller's pipeline.
>
>The only issue (if it is an issue) is that the result of the called
>pipeline , ie. the serialized output, is discarded. This doesn't matter if
>the only desire is to upadet th econtents of a session context.
>
>I'll try and get a sample out in the next few nights if anyone's interested.
>
>Also, if anyone thinks this is really bad cocoon please let me know - I
>guess it could be open to abuse.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Using the results of an aggregate part - order of execution.
Posted by Tony Culshaw <to...@cultech.com.au>.
What's interesting here is that an aggregate still does the cocoon thing
whereby MATCHERS ACTORS and SELECTORS are executed FIRST even down through
the aggregate parts (ie. internal pipelines) and then and only then is the
pipeline processor assembled with GENERATORS (inc aggregators),
TRANSFORMERS and SERIALIZERS. The processor is then executed. This is one
of the biggest hurdles to overcome for anyone starting out with this
framework in terms of understanding.
This ultimately means that (in this example) any attempt to modify session
contexts in a part1 TRANSFORM of an aggregate will not be visible by a
part2 ACTION because the part2 ACTION is excecuted BEFORE the part1
TRANSFORMER.
To summarise in pseudo sitemap code...
<aggregate>
<part1 src="cocoon:/part1/>
<part2 src="cocoon:/part2/>
</aggregate>
<part1>
<action1/>
<transform1/>
</part1>
<part2>
<action2/>
<transform2/>
</part2>
The order of execution of components above will be action1, action2,
transform1, transform2.
Maybe the forthcoming flow stuff will help here, but I'm not sure.
However, there is another solution, but it involves a writing an
additional component and may be viewed by cocoon purists as a hack:)
We (the company I'm currently contracting to) intend to release as a block
a number of utility components, one of which is a Pipeline Action. This
may upset some Cocoon purists but it is an action which calls a pipeline
(effectively a new http request back into the framework).
This allows the called pipeline to FULLY execute (including transfomers
which may update session contexts), prior to whatever follows in the rest
of the caller's pipeline.
The only issue (if it is an issue) is that the result of the called
pipeline , ie. the serialized output, is discarded. This doesn't matter if
the only desire is to upadet th econtents of a session context.
I'll try and get a sample out in the next few nights if anyone's interested.
Also, if anyone thinks this is really bad cocoon please let me know - I
guess it could be open to abuse.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XSL Security question
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Niclas Hedhman wrote:
>>What kind of DoS attacks would you expect?
>
>
> If I can upload an XSL, I can have an infinite loop in the XSL, and then issue
> continous HTTP requests invoking that XSL, effectively eating up both RAM and
> CPU time.
Also eating up bandwidth, and if the server is hot iron hooked
to a fat pipe, you can bring down the target end of the URL by
swamping it with requests. Actually, this was the main idea.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XSL Security question
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 30 January 2003 14:30, Andrew Timberlake wrote:
> What kind of DoS attacks would you expect?
If I can upload an XSL, I can have an infinite loop in the XSL, and then issue
continous HTTP requests invoking that XSL, effectively eating up both RAM and
CPU time.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XSL Security question
Posted by Andrew Timberlake <an...@timberlake.co.za>.
On Thu, 2003-01-30 at 15:53, Stefano Mazzocchi wrote:
> > 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?
>
> I think this is asking for troubles.
I agree.
>
> Moreover, I don't picture users really writing their own stylesheets
> directly anyway, but I don't know what kind of users you are targetting.
The user's will be developers. Those able to write stylesheets will have
to submit them for review and testing first.
I was just exporing an idea, be it a bad one.
Thank you for the input.
--
Andrew Timberlake <an...@timberlake.co.za>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XSL Security question
Posted by Andrew Timberlake <an...@timberlake.co.za>.
On Thu, 2003-01-30 at 15:53, Stefano Mazzocchi wrote:
> > 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?
>
> I think this is asking for troubles.
I agree.
>
> Moreover, I don't picture users really writing their own stylesheets
> directly anyway, but I don't know what kind of users you are targetting.
The user's will be developers. Those able to write stylesheets will have
to submit them for review and testing first.
I was just exporing an idea, be it a bad one.
Thank you for the input.
--
Andrew Timberlake <an...@timberlake.co.za>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XSL Security question
Posted by Stefano Mazzocchi <st...@apache.org>.
Andrew Timberlake wrote:
> 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?
I think this is asking for troubles.
Moreover, I don't picture users really writing their own stylesheets
directly anyway, but I don't know what kind of users you are targetting.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XSL Security question
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Andrew Timberlake wrote:
> Could I turn the handle the URIResolver specificaly for certain
> Transformers or would any changes effect the entire cocoon application?
In Cocoon the transformer's URIResolver is already used by
Cocoon's own resolver, and AFAIK there is no easy way to
hook in there.
>>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.
This can be handled by a slightly hacked XSLTTransformer
which can be used side-by-side with unmodified transformers,
the same way you can use multiple serializers and parsers
in your application.
But who needs XSLT extensions anyway? :-)
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XSL Security question
Posted by Andrew Timberlake <an...@timberlake.co.za>.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XSL Security question
Posted by "J.Pietschmann" <j3...@yahoo.de>.
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.
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.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XSL Security question
Posted by Stefano Mazzocchi <st...@apache.org>.
copying xalan-dev:
Andrew Timberlake wrote:
> I don't know all the capabilities of XSL and would like to know if there
> is a security risk in allowing users to upload any XSL files to be used
> in a 'skins' type of application?
> My one concern would be using the document('') methods to load and
> display other files from the system?
> If this is not a good idea, can we sandbox an xsl transformer somehow?
Yes, there is a security concern in terms of reading stuff accessible
from the user executing the virtual machine. If you can also find a way
to upload classes and/or scripts, you could execute them from those
stylesheets using extensions or BSF.
Some servlet engines allow you to setup a security sandbox around the
entire servlet (cocoon in this case, or your own code), so that would
limit somehow your vulnerability.
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?
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XSL Security question
Posted by Stefano Mazzocchi <st...@apache.org>.
copying xalan-dev:
Andrew Timberlake wrote:
> I don't know all the capabilities of XSL and would like to know if there
> is a security risk in allowing users to upload any XSL files to be used
> in a 'skins' type of application?
> My one concern would be using the document('') methods to load and
> display other files from the system?
> If this is not a good idea, can we sandbox an xsl transformer somehow?
Yes, there is a security concern in terms of reading stuff accessible
from the user executing the virtual machine. If you can also find a way
to upload classes and/or scripts, you could execute them from those
stylesheets using extensions or BSF.
Some servlet engines allow you to setup a security sandbox around the
entire servlet (cocoon in this case, or your own code), so that would
limit somehow your vulnerability.
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?
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
RE: XSL Security question
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Xalan, at least, allows access to the Bean Scripting Framework
as well => access any class.
> From: Andrew Timberlake [mailto:andrew@timberlake.co.za]
>
> I don't know all the capabilities of XSL and would like to
> know if there is a security risk in allowing users to upload
> any XSL files to be used in a 'skins' type of application? My
> one concern would be using the document('') methods to load
> and display other files from the system? If this is not a
> good idea, can we sandbox an xsl transformer somehow? Any
> thoughts are most welcome.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org