Shouldn't this be addressed by using URL-encoding of the resource
name? %5c for backslash.
Tom
On 11/11/2010 11:26 AM, Jason Lee wrote:
> A couple of weeks ago, I asked about backslashes in URLs. For
> reference, this issue is driving the question:
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=13348
>
> The possible solutions were: modify Grizzly to allow the backslash, or
> disallow the use of the backslash in resource names.
>
> I opened an issue against Grizzly
> (https://glassfish.dev.java.net/issues/show_bug.cgi?id=14441) to track
> the discussion on the Grizzly side. Oleksiy and I discussed the issue
> this morning. His assessment (and correct me if I get this wrong,
> Oleksiy) is that we can make Grizzly allow the character, but the
> security implications are unclear. He gave this example (copied from IM):
>
> we allow users to access folder a/b/c, but don't want them see a/b/c/d
> and if someone will try a/b/c\d - our policy may not catch this
> request
> and create let's say a File("a/b/c\d")
> which will be interpreted by Windows as "a\b\c\d" and user will
> get access to folder d
> which wasn't allowed
>
> The code that disallows the character (which he pasted on #14441) has
> been in place "for ages." We're just now hitting this issue, it
> seems, due to our migration to REST. We can change it of course, but
> the implications are unclear.
>
> Oleksiy and I would both me more comfortable with disallowing the
> character altogether. Today, it's \, but tomorrow it could be yet
> another exception for some as-of-yet unexpected "special" character.
> That decision, of course, isn't ours to make, so I bring it up here.
>
> What's the group's opinion, then? If we feel we need to allow the
> character and others feel there are no security concerns, we can
> certainly do that. Disallowing the character is probably easier and
> safer, but may not be the best for users, so I'm open to guidance here. :)
>
> --
> Jason Lee
> Senior Member of Technical Staff
> GlassFish Administration Console
>
> Oracle Corporation
> Phone +1 405-216-3193
> Bloghttp://blogs.steeplesoft.com