It sucks having to invent another encoding scheme; URL encoding seems
like the obvious answer. Are we sure we can't address the potential
security issues another way?
If we have to use a different encoding, we should at least use an
existing reversible encoding, rather than invent a new one,
especially a non-reversible one.
We could encode it all in base64, but that's ugly.
Possibly we could use html encoding?
Or even modified UTF-7 from RFC 3501?
Jason Lee wrote on 05/27/2010 02:26 PM:
> Right now, it seems to be encoding the / as -:
>
> <childResources>
>
> <childResource>http://localhost:4848/management/domain/resources/admin-object-resource/jndi-foo</childResource>
>
> <childResource>http://localhost:4848/management/domain/resources/admin-object-resource/jndi-my-resource</childResource>
> </childResources>
>
> Should we change that for GETs, then add code to undo it in POST,
> DELETE, and PUT?
>
> On 5/27/10 4:16 PM, Ludovic Champenois wrote:
>>
>>
>> Yes, tried that for 3.0 and did not work.
>> For now, I think iirc we code/ in gf resouces with __
>> not sure, just navigate to a jdc resource via HTML access...
>> Ludo
>>
>> On May 27, 2010, at 2:02 PM, Jason Lee <jason.d.lee_at_oracle.com
>> <mailto:jason.d.lee_at_oracle.com>> 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.
>>>
>>> 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
>
>
> --
> Jason Lee
> Senior Member of Technical Staff
> GlassFish Administration Console
>
> Oracle Corporation
> Phone x31197/+1 405-343-1964
> Blog http://blogs.steeplesoft.com
>