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? If global, this might
introduce other side effects on GlassFish behavior as well, including
user deployed apps...
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.
Ludo