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..