—
Tadeas Kriz
On 25 Jul 2014, at 03:33 pm, Bruno Oliveira <bruno(a)abstractj.org> wrote:
> Hi Tadeas, you are correct. Apache web server disallow %2F or %5C
> due to security concerns. There are several alternatives, most of them
> workarouds, some people double encode it, others replace / by _ back and
> forth or some people disable it like:
>
> <VirtualHost *:80>
> AllowEncodedSlashes On
> </VirtualHost>
>
> I hope it helps, otherwise let me know how I can help.
>
Thanks, this is what I’ve found yesterday while researching this. The
“allowencodedslashes” just opens the security hole, doesn’t it? Anyway, what I meant was
if it would be a possible security issue, if we could get it working without the encoded
URL at all. Like Daniel propsed, to use the `.*` regex to match everything beneath the
`/installation/` so the actual request would look like that?
```
DELETE /rest/registry/installation/http://localhost:8321/asdasdasdasd
```
Thanks.
> On 2014-07-25, Tadeas Kriz wrote:
>>
>> —
>> Tadeas Kriz
>>
>> On 25 Jul 2014, at 01:09 pm, Daniel Bevenius <daniel.bevenius(a)gmail.com>
wrote:
>>
>>>> it might work, although I’m not sure if this is the best solution “on
the market”.
>>> It may not be the best solution and feel free to ignore it.
>>>
>>
>> I’d love to test it first. My only concern is whether or not might it be a
security issue. I think that’s something that Bruno might know.
>>
>>>
>>>
>>>
>>> On 25 July 2014 12:55, Tadeas Kriz <tkriz(a)redhat.com> wrote:
>>>
>>> —
>>> Tadeas Kriz
>>>
>>> On 25 Jul 2014, at 12:38 pm, Daniel Bevenius
<daniel.bevenius(a)gmail.com> wrote:
>>>
>>>>> What do you mean by that regex?
>>>> That the JAXRS implementation should not disallow as '/' in the
path.
>>>
>>> Well, if it was like:
>>>
>>> ```
>>> DELETE /rest/registry/installation/http://localhost:8321/asdasd
>>> ```
>>>
>>> and the token you showed would match all the characters (which means that
the `String token` would become `http://localhost:8321/asdasd` in the endpoint method), it
might work, although I’m not sure if this is the best solution “on the market”.
>>>
>>>>
>>>>> The problem is simply the “%2F” in the token (which is an URLencoded
simplepush url) and it’s being revoked long before it hits the RestEasy (which does the
routing according to what’s in the @Path).
>>>> I guess I don't understand why this would be revoked by anything
before it hits the JAXRS implementation, but if that is the case you are right and adding
this would not help.
>>>>
>>>
>>> This was a solution for a security hole. As I understand it, on linux,
scripts cannot tell difference between “/“ and “%2F” and because of that, it’s forbidden
to use as a path parameter (at least on Tomcat).
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 25 July 2014 12:25, Tadeas Kriz <tkriz(a)redhat.com> wrote:
>>>>
>>>> —
>>>> Tadeas Kriz
>>>>
>>>> On 25 Jul 2014, at 11:04 am, Daniel Bevenius
<daniel.bevenius(a)gmail.com> wrote:
>>>>
>>>>>> 5. don’t use the url as a deviceToken (might not comply with
Mozzila’s SimplePush specs)
>>>>> The deviceToken is an UPS concept and there is nothing in the
SimplePush spec which is violated in this case.
>>>>>
>>>>
>>>> I thought that deviceTokens were changed from a generated value to the
URL just to comply with Mozzila’s SimplePush specs. Matzew, why was the generated token
removed then?
>>>>
>>>>> I'm not sure about what the best option is for UPS thought.
Would a regex in for the @Path annotation work perhaps, something like:
>>>>>
>>>>> @DELETE
>>>>> @Path("{token, .+}")
>>>>> public Response unregisterInstallations(
>>>>>
>>>>
>>>> What do you mean by that regex? The problem is simply the “%2F” in the
token (which is an URLencoded simplepush url) and it’s being revoked long before it hits
the RestEasy (which does the routing according to what’s in the @Path).
>>>>
>>>>>
>>>>> On 25 July 2014 10:32, Tadeas Kriz <tkriz(a)redhat.com> wrote:
>>>>>
>>>>> —
>>>>> Tadeas Kriz
>>>>>
>>>>> On 24 Jul 2014, at 05:44 pm, Karel Piwko <kpiwko(a)redhat.com>
wrote:
>>>>>
>>>>>> On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz
<tkriz(a)redhat.com> wrote:
>>>>>>>
>>>>>>> It should not. For hibernate, it’s just a string like any
other.
>>>>>>> The problem might be in the configuration of
JAX.RS/RestEasy. If
>>>>>>> I’ll have some time today evening, I’ll try to fix it, it
should
>>>>>>> be an easy fix.
>>>>>>
>>>>>> Last famous words? ;-)
>>>>>>
>>>>>
>>>>> I shall never say “an easy fix” again.
>>>>>
>>>>>> But I agree. Everything is string and URL encode should happen
on
>>>>>> client while server should automatically decode and work always
with
>>>>>> just decoded string. If we need to encode twice, something is
wrong.
>>>>>>
>>>>>
>>>>> Anyway, the 400 Bad request response is made by the tomcat itself,
disallowing the use of %2F as a path parameter. This will probably apply on other web
containers.
>>>>>
>>>>> Possible solutions with their disadvantages:
>>>>>
>>>>> 1. well-documented double-encoding of the URL (might be confusing)
>>>>> 2. use @QueryParam instead of @PathParam (breaks the api
consistence, as every other call would still use @PathParam)
>>>>> 3. allow @QueryParam (again, breaks the api consistence, but only
for the SimplePush)
>>>>> 4. find another encoding (Base64 for URL = URLEncode then Base64
encode)
>>>>> 5. don’t use the url as a deviceToken (might not comply with
Mozzila’s SimplePush specs)
>>>>>
>>>>> What do you think guys?
>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
> --
>
> abstractj
> PGP: 0x84DC9914