You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Ulrich Stärk <ul...@spielviel.de> on 2009/08/26 15:57:52 UTC
Securing files on the classpath/webapp context (was: Re: Running
Tapestry 5.0.18 on Google App Engine)
I really like to hear what the other devs (apart from Thiago) are thinking about this, whether there
are objections against what I proposed or if you think there are better solutions. This really needs
fixing ASAP.
Cheers,
Uli
On 26.08.2009 13:41 schrieb Ulrich Stärk:
> I think that's way too complicated. Keep it simple:
>
> a) blacklist everything and let the user contribute filenames, file
> extensions or paths to some whitelisting service (already having some
> reasonable defaults like .css, .js, .png, ...) which AssetSource queries
> before returning an Asset
> b) restrict the AssetSource to only return assets referenced in a
> component/page using @Path, @IncludeJavaScriptLibrary,
> @IncludeStylesheet and the context: and asset: binding prefixes
>
> Uli
>
> On 26.08.2009 13:19 schrieb Thiago H. de Paula Figueiredo:
>> Em Wed, 26 Aug 2009 04:12:29 -0300, Onno Scheffers <on...@piraya.nl>
>> escreveu:
>>
>>> @Thiago
>>> How about allowing absolutely nothing from the classpath/WEB-INF
>>> initially?
>>> Directory listing should also be disabled.
>>
>> I agree. My suggestion to TAP-815 was:
>>
>> "I would suggest to have a chain of command, each object in it
>> receiving the requested URL and responding true (ok), false (file is
>> forbidden) or null (this object doesn't handle this URL, ask the same
>> thing to the next object. This chain of command terminator would be a
>> very restrictive one."
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Securing files on the classpath/webapp context (was: Re: Running
Tapestry 5.0.18 on Google App Engine)
Posted by Onno Scheffers <on...@piraya.nl>.
>
> The Tapestry asset feature is used even when you use files from the context
> (asset:context:something.jpg).
Yes, but does that mean js-files and css-files etc. should be whitelisted by
default? Normally if Tapestry encounters an asset:-statement, it knows the
asset should be whitelisted. In this case the asset is already on the public
context path, so whitelisting is not even required.
> And assets provided by modules should go on the classpath, otherwise you
> would have to copy files from that module and put them in predefined
> folders, killing the very nice "drop a JAR in the classpath and it works
> automatically" feature for Tapestry.
That would still work, wouldn't it? I'm not claiming Tapestry cannot access
files on the classpath, so drop-in modules should still work. I'm just
claiming Tapestry shouldn't share those files with the rest of the world
unless specifically told to do so. Therefore components inside the module
can still include assets and when they do, they automatically whitelist
those assets.
regards,
Onno
Re: Securing files on the classpath/webapp context (was: Re: Running
Tapestry 5.0.18 on Google App Engine)
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 26 Aug 2009 11:10:17 -0300, Onno Scheffers <on...@piraya.nl>
escreveu:
> I think not even css-files, js-files and png-files should be whitelisted
> by default to be honest. We already have a way of making such files
> public: put them in the public web context.
The Tapestry asset feature is used even when you use files from the
context (asset:context:something.jpg). And assets provided by modules
should go on the classpath, otherwise you would have to copy files from
that module and put them in predefined folders, killing the very nice
"drop a JAR in the classpath and it works automatically" feature for
Tapestry.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Securing files on the classpath/webapp context (was: Re: Running
Tapestry 5.0.18 on Google App Engine)
Posted by Onno Scheffers <on...@piraya.nl>.
On Wed, Aug 26, 2009 at 3:57 PM, Ulrich Stärk <ul...@spielviel.de> wrote:
> I really like to hear what the other devs (apart from Thiago) are thinking
> about this, whether there are objections against what I proposed or if you
> think there are better solutions. This really needs fixing ASAP.
I think not even css-files, js-files and png-files should be whitelisted by
default to be honest. We already have a way of making such files public: put
them in the public web context.
If a Mixin, Component or Page includes a resources from the classpath, only
then that specific asset should be whitelisted (including its localized
alternatives if required).
regards,
Onno
Re: Securing files on the classpath/webapp context (was: Re: Running
Tapestry 5.0.18 on Google App Engine)
Posted by Michael Gerzabek <mi...@gmx.net>.
I must say I was a little bit shocked when I heard about this security
hole and found an easy way within httpd (mod_rewrite) to circumvene this
problem at first.
Thinking about how it should be I would prefer the 'blacklist
everything'-approach. This way a dev never has to worry about what's
opened up by deploying a third party jar.
Of course extra documentation is needed then to pre-answer mailing list
questions like 'my packaged images don't show up' ...
Michael
Ulrich Stärk schrieb:
> I really like to hear what the other devs (apart from Thiago) are
> thinking about this, whether there are objections against what I
> proposed or if you think there are better solutions. This really needs
> fixing ASAP.
>
> Cheers,
>
> Uli
>
> On 26.08.2009 13:41 schrieb Ulrich Stärk:
> > I think that's way too complicated. Keep it simple:
> >
> > a) blacklist everything and let the user contribute filenames, file
> > extensions or paths to some whitelisting service (already having some
> > reasonable defaults like .css, .js, .png, ...) which AssetSource
> queries
> > before returning an Asset
> > b) restrict the AssetSource to only return assets referenced in a
> > component/page using @Path, @IncludeJavaScriptLibrary,
> > @IncludeStylesheet and the context: and asset: binding prefixes
> >
> > Uli
> >
> > On 26.08.2009 13:19 schrieb Thiago H. de Paula Figueiredo:
> >> Em Wed, 26 Aug 2009 04:12:29 -0300, Onno Scheffers <on...@piraya.nl>
> >> escreveu:
> >>
> >>> @Thiago
> >>> How about allowing absolutely nothing from the classpath/WEB-INF
> >>> initially?
> >>> Directory listing should also be disabled.
> >>
> >> I agree. My suggestion to TAP-815 was:
> >>
> >> "I would suggest to have a chain of command, each object in it
> >> receiving the requested URL and responding true (ok), false (file is
> >> forbidden) or null (this object doesn't handle this URL, ask the same
> >> thing to the next object. This chain of command terminator would be a
> >> very restrictive one."
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org