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.
Thoughts?
On 5/27/10 3:07 PM, Jason Lee wrote:
> On 5/27/10 2:55 PM, Tim Quinn wrote:
>> If the resource name contains a slash, then would it work to encode
>> the slash in the path?
>>
>> http://localhost:4848/management/domain/resources/admin-object-resource/jndi%2Ffoo
>>
>>
>> Just a thought.
> Tom, Tim, great point. One I should have seen. :) Thanks! :P
>
--
Jason Lee
Senior Member of Technical Staff
GlassFish Administration Console
Oracle Corporation
Phone x31197/+1 405-343-1964
Blog http://blogs.steeplesoft.com