In this case it's about requests to
http://my.site/somecontext/assets/ctx/something/WEB-INF/ and similar.
since accessing those via the asset dispatcher is forbidden, regardless
whether the request is for an existing asset or not, I guess returning
403 is ok.
Uli
Andreas Andreou schrieb:
ok, well, all i'm saying is it should return 404 in all those cases
Last time i checked that's what jetty/tomcat are doing for requests such as
http://my.site/WEB-INF/ (but i'm not sure if that's in the servlet
specs or not)
On Tue, Nov 10, 2009 at 8:03 PM, Ulrich Stärk <[email protected]> wrote:
That's because the AssetProtectionDispatcher doesn't know whether the
resource actually exists. It just checks the requested url against a
whitelist consisting of allowed patterns.
Uli
Andreas Andreou schrieb:
Interesting... So, why then is it returning 403-forbidden for
something that doesn't exist?
Anyone knows/remembers the reasoning?
On Tue, Nov 10, 2009 at 6:43 PM, Ulrich Stärk <[email protected]> wrote:
since it returns 403 also on non-existent resources, an attacker wouldn't
know whether the resource he requested actually exists.
Am 10.11.2009 17:23 schrieb Andreas Andreou:
hmm, i'd argue it needs to return a 404 error though, so as not to give
attackers a way to know which libraries/jars/resources exist...
On Tue, Nov 10, 2009 at 2:52 PM, Ulrich Stärk <[email protected]> wrote:
ust tested it in trunk, works as expected: Trying to access templates
and
other stuff, as well as directory listings result in a 403. An
integration
test making sure that the protection isn't accidentally removed again
would
be nice though.
Uli
Am 10.11.2009 11:28 schrieb Massimo Lusetti:
On Mon, Nov 9, 2009 at 6:23 PM, <[email protected]> wrote:
Author: robertdzeigler
Date: Mon Nov 9 17:23:10 2009
New Revision: 834151
URL: http://svn.apache.org/viewvc?rev=834151&view=rev
Log:
TAP5-815: Asset dispatcher allows any file inside the webapp visible
and
downloadable (5.2 branch)
Looking for testing this one soon but thanks for the work! Especially
for (back)porting to the other two dev branch.
Cheers
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
