I think the reason it is decoded is this: The Container receives a
request like "/foo/at%40test.html" which then must be decoded to serve
up a file named "/foo/at_at_test.html". '@' and many other characters not
allowed in URLs must be encoded when they're used in a file name, so the
container must decoded them *before attempting to resolve them*.
However, when doing this the '/' character may be encoded (it is not
required to be... and *should not be* when it is used as part of a path
meant for the container to interpret). During the decoding a String
such as "/foo%2Fbar.html" becomes "/foo/bar.html" which changed it from
a single path element to 2 path elements (bug in my opinion). This can
be used to send a request through a proxy server (which apparently
doesn't have the bug which translates %2F) which then later circumvents
the context security by using "%2F..%2F...".
If our container refused to translate %2F to equal '/'... problem
solved. *Instead* our server (by default) throws an exception when %2F
is used at all. :(
Before decoding the String for use in resolving the file, I think this
would solve the problem:
string = string..replaceAll("%2F", "%252F");
Ken
On 06/02/2010 10:32 AM, Bill Shannon wrote:
> Jason Lee wrote on 06/ 2/10 09:47 AM:
>> Shing Wai (and Amy) tell me that the web container suffers from the same
>> vulnerability that the Tomcat changelog warns of. Ken and I have both
>> confirmed this via testing (curl http://localhost:8080/foo%2Fbar.html
>> returns the contents of foo/bar.html when it shouldn't).
>
> And do they say why that can't, or shouldn't, be fixed?
>
> Does the servlet spec have anything to say about this behavior?
> Should it?
>
> I don't understand why it should *ever* automatically decode URLs.
>
> If I enter "http://java.sun.com%2fjavaee" in a browser, it fails
> as expected. What is depending on the decoding being done automatically?
>
> Being able to configure this per web app seems like a good compromise,
> in case there's code out there that depends on this.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>