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 <o...@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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
