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
Blog http://blogs.steeplesoft.com