Re: REST API and slashes in resource names
>>>
>>>> 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?
It's global.
WBR,
Alexey.
>
> 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.