On May 28, 2010, at 8:18 AM, Ludovic Champenois wrote:
> On 5/27/10 10:31 PM, Paul Sandoz wrote:
>>
>>
>> On May 27, 2010, at 11:02 PM, Jason Lee wrote:
>>
>>> OK. While that may solve that issue, it's caused another. When I
>>> request a URL like the one below, I get a stack trace like this:
>>>
>>> Internal Server error: /management/domain/resources/admin-object-
>>> resource/jndi%2Ffoo
>>> java.io.CharConversionException: noSlash
>>> at com.sun.grizzly.util.buf.UDecoder.convert(UDecoder.java:152)
>>> at com.sun.grizzly.util.buf.UDecoder.convert(UDecoder.java:257)
>>> at com.sun.grizzly.util.buf.UDecoder.convert(UDecoder.java:235)
>>> at
>>> com
>>> .sun
>>> .grizzly
>>> .util.http.HttpRequestURIDecoder.decode(HttpRequestURIDecoder.java:
>>> 80)
>>> at
>>> com
>>> .sun
>>> .enterprise
>>> .v3.services.impl.ContainerMapper.service(ContainerMapper.java:194)
>>> at
>>> com
>>> .sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:
>>> 803)
>>> at
>>> com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:706)
>>> at
>>> com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:987)
>>> at
>>> com
>>> .sun
>>> .grizzly
>>> .http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:178)
>>> at
>>> com
>>> .sun
>>> .grizzly
>>> .DefaultProtocolChain
>>> .executeProtocolFilter(DefaultProtocolChain.java:135)
>>> at
>>> com
>>> .sun
>>> .grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
>>> at
>>> com
>>> .sun
>>> .grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
>>> at
>>> com
>>> .sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:
>>> 76)
>>> at
>>> com
>>> .sun
>>> .grizzly
>>> .ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
>>> at
>>> com
>>> .sun
>>> .grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:
>>> 57)
>>> at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
>>> at com.sun.grizzly.util.AbstractThreadPool
>>> $Worker.doWork(AbstractThreadPool.java:526)
>>> at com.sun.grizzly.util.AbstractThreadPool
>>> $Worker.run(AbstractThreadPool.java:507)
>>> at java.lang.Thread.run(Thread.java:637)
>>>
>>> Grizzly has a config option,
>>> com.sun.grizzly.util.buf.UDecoder.ALLOW_ENCODED_SLASH, false by
>>> default, that controls whether or not to allow a slash to be
>>> encoded. This change, I'm told, was ported to Grizzly from Tomcat
>>> (http://tomcat.apache.org/security-6.html):
>>> Tomcat permits '\', '%2F' and '%5C' as path delimiters. When
>>> Tomcat is used behind a proxy (including, but not limited to,
>>> Apache HTTP server with mod_proxy and mod_jk) configured to only
>>> proxy some contexts, a HTTP request containing strings like "/
>>> \../" may allow attackers to work around the context restriction
>>> of the proxy, and access the non-proxied contexts.
>>> It seems, then, that allowing this type of encoding may pose
>>> security issues. Without it, however, it doesn't seem I can
>>> correctly (i.e., RESTfully) identify certain types of resources.
>>>
>>
>> This sounds odd and may be a work around for limitations in some
>> proxy servers in the way they handle URLs. It also says:
>>
>> "Due to the impossibility to guarantee that all URLs are handled
>> by Tomcat as they are in proxy servers, Tomcat should
>> always be secured as if no proxy restricting context access was
>> used."
>>
>> So basically Tomcat/Grizzly/Glassfish is restricted because some
>> proxy servers (and which versions?) may also be restricted.
>>
>> Can we get some more info on such proxy servers and the potential
>> security issue?
>>
>> It also might be worth checking if other app servers have such a
>> restriction.
>>
>> Paul..
> Is it a global flag for Grizzly of per adapter?
Not sure.
> If global, this might introduce other side effects on GlassFish
> behavior as well, including user deployed apps...
Right.
> I recall trying to use this flag, and I ran into other issues at
> that time, for either monitoring urls (using
> "@Path("domain{path:.*}") dynamic path) or child resources of
> encoded resources...Not sure anymore. Anyway I will try again.
> Seems to be a generic REST topic, so we need to find the right set
> of guidelines there if none if fully specified.
>
Yes, quite a few styles of service would rely on this. One style is
embedding a URI in another URI.
This seems to be a security issue when files are served from a poorly
designed Web server and the server decodes the URL path and because
the path contains ".." and "/" it could be directed to serve files
from locations that were not intended to be served (e.g. a UNIX
password file or other users files). I presume this is not an issue
for the admin service.
Paul.