[aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter

Fri Jul 25 13:02:13 EDT 2014

On 2014-07-25, Tadeas Kriz wrote:
>
> —
> Tadeas Kriz
>
> On 25 Jul 2014, at 03:33 pm, Bruno Oliveira <bruno at 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?

+1

>
> ```
> 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 at 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 at redhat.com> wrote:
> >>>
> >>> —
> >>> Tadeas Kriz
> >>>
> >>> On 25 Jul 2014, at 12:38 pm, Daniel Bevenius <daniel.bevenius at 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 at redhat.com> wrote:
> >>>>
> >>>> —
> >>>> Tadeas Kriz
> >>>>
> >>>> On 25 Jul 2014, at 11:04 am, Daniel Bevenius <daniel.bevenius at 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 at redhat.com> wrote:
> >>>>>
> >>>>> —
> >>>>> Tadeas Kriz
> >>>>>
> >>>>> On 24 Jul 2014, at 05:44 pm, Karel Piwko <kpiwko at redhat.com> wrote:
> >>>>>
> >>>>>> On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz <tkriz at 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 at lists.jboss.org
> >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> aerogear-dev mailing list
> >>>>> aerogear-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>>
> >>>>> _______________________________________________
> >>>>> aerogear-dev mailing list
> >>>>> aerogear-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> aerogear-dev mailing list
> >>>> aerogear-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>
> >>>> _______________________________________________
> >>>> aerogear-dev mailing list
> >>>> aerogear-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>
> >>>
> >>> _______________________________________________
> >>> aerogear-dev mailing list
> >>> aerogear-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>
> >>> _______________________________________________
> >>> aerogear-dev mailing list
> >>> aerogear-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
>

--

abstractj
PGP: 0x84DC9914