You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Richard Sentino <ri...@mindginative.com> on 2013/08/08 13:10:21 UTC
Re: Security Error in FirefoxOS on reading window.navigator properties
Hello
I just wanted to keep the ball rolling about this issue.
In response to "SecurityError be caught in an try{} block?", yes and it seems to do the trick. At the moment, out of the FirefoxOS-specific APIs it gets stuck in the mud at "mozTime" [1] which is only available to certified apps [2] therefore a security error will be thrown [3]. With the recently refactored cordova-js, do you guys have any intention on clobbering navigator at the platform.js level ? I made a test app [4] running on 3.0.x from master branch and tested on FirefoxOS 4.0/5.0pre simulator and on a Keon device.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=751011#c3
[2] https://developer.mozilla.org/en-US/docs/Web/API/window.navigator.mozTime
[3] https://github.com/apache/cordova-js/blob/master/lib/common/init.js#L56
[4] http://rixrix.github.io/cordova-firefoxos-patch/manifest.webapp
Thanks
--
Richard
On 25/06/2013, at 8:25 AM, Andrew Grieve <ag...@chromium.org> wrote:
We also used this to implement navigator.connection. Without this, we can't
replace the connection property. Another example is the onLine property for
Android. It needs to be overridden to hide the fact that it is toggled
on/off by our exec() bridge.
On Mon, Jun 24, 2013 at 3:59 PM, Gord Tanner <gt...@gmail.com> wrote:
> This might be a bad example since most platforms support native geolocation
> now but I know we would run into problems with:
>
> navigator.geolocation = require('cordova/plugin/geolocation')
>
> When geolocation already existed on navigator it would throw a security
> exception (or just be a noop). It is the cost of doing our shit on the
> navigator object, every platform treats this as a "secure" object
> (rightfully so) and does things a little differently. The lowest common
> denominator was to just dump our own mock object in ASAP to prevent a lot
> of that security stuff from getting in our way.
>
> Does this still need to happen? (I don't know)
> What platforms were having problems? (I can't really remember)
> Should we look into if we still need to do this? (of course)
>
> the bootstrap.js is ment to contain code for bootstrapping all of cordova
> on every platform. I am thinking we may need to rethink the navigator
> clobbering and make this a platform overridable bootstrap step.
>
>
>
> On Mon, Jun 24, 2013 at 3:50 PM, Brian LeRoux <b...@brian.io> wrote:
>
>> But wait, and I'm serious here, why even duck punch navigator to begin
>> with?
>>
>> I understand we add properties to it. Is that why it needs to be opened?
>>
>> On Mon, Jun 24, 2013 at 11:50 AM, Ian Clelland <ic...@google.com>
>> wrote:
>>> Can the SecurityError be caught in an try{} block? If so, then we could
>>> implement a general solution of "try to clobber the entire object; if
>> that
>>> doesn't work, try to clobber each of its properties instead."
>>>
>>> In the second case, a debug log line for each property that cannot be
>>> copied would give us a list of any platform-dependent quirks that we
> need
>>> to document.
>>>
>>>
>>> On Mon, Jun 24, 2013 at 2:42 PM, Gord Tanner <gt...@gmail.com>
> wrote:
>>>
>>>> This is from the bootstrap file for all platforms [1].
>>>>
>>>> This is to cover us for security issues we were having on other
>> platforms
>>>> where we are not able to replace existing navigator object methods
>>>> (geolocation, etc) or add new ones. We create this object and proxy
> to
>> the
>>>> original navigator object to have something that is a bit more
> flexible
>> for
>>>> us to work with and modify.
>>>>
>>>> Does firefox yell at us if we replace the navigator object without
>>>> iterating over the old one? We could then just hardcode the list of
>>>> functions to proxy over to the original for that platform.
>>>>
>>>> [1] -
>>>>
>>>>
>>
> https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=blob_plain;f=lib/scripts/bootstrap.js;hb=HEAD
>>>>
>>>>
>>>> On Mon, Jun 24, 2013 at 2:34 PM, Brian LeRoux <b...@brian.io> wrote:
>>>>
>>>>> I'm at a loss why that code even needs to exist.
>>>>>
>>>>> Anyone? Herm / Gord?
>>>>>
>>>>> On Thu, Jun 20, 2013 at 5:06 AM, Piotr Zalewa <pz...@mozilla.com>
>>>> wrote:
>>>>>> I came to a point where I need to use the group wisdom.
>>>>>>
>>>>>> In
>>>>>
>>>>
>>
> https://github.com/apache/cordova-firefoxos/blob/master/lib/cordova.firefoxos.js#L5929Cordovaistryingto replace window.navigator with something which looks
>>>>> like a copy of itself. window.navigator is protected in FirefoxOS -
>> even
>>>>> browsing through its properties is not allowed.
>>>>>>
>>>>>> alert('pre'); for (var key in window.navigator)
>>>> {window.navigator[key]};
>>>>> alert('post');
>>>>>>
>>>>>> Above code will work in browser, but not on the device or
>> Simulator. It
>>>>> will throw "SecurityError: The operation is insecure." and 'post'
> will
>>>> not
>>>>> get alerted. Example in JSFiddle -
>>>>> http://jsfiddle.net/zalun/VkCyH/embedded/result/ (just install in
>>>>> Simulator)
>>>>>>
>>>>>> I'm looking for a solution for that issue.
>>>>>>
>>>>>> Is the step with replacing window.navigator needed? The comment in
>> the
>>>>> code says
>>>>>> // We replace it so that properties that can't be clobbered can
>> instead
>>>>> be overridden.
>>>>>>
>>>>>>
>>>>>> Piotr
>>>>>
>>>>
>>
>
Re: Security Error in FirefoxOS on reading window.navigator properties
Posted by Richard Sentino <ri...@mindginative.com>.
Hi Andrew
Thanks for the feedback
I'm trying to spin my head right around but IMHO I'd go with option #1 and let these plugin do whatever they want with the navigator, great advantage for 3rd party plugins that interacts with certified-only APIs [1] - although others might have a better opinion and go with the other option.
[1] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/Security_model
Cheers
--
Richard
On 9/08/2013, at 3:45 AM, Andrew Grieve <ag...@chromium.org> wrote:
I think it makes sense to have this be an option since it's breaking ff.
I think it's actually only required now by the
cordova-plugin-network-information plugin.
1. Maybe we could just move it into that plugin?
2. Or, we could make it a separate plugin that others wanting to override
navigator symbols can depend on.
3. Or, we could move the logic into modulemapper such that the hack is
applied only when clobbering a symbol on navigator doesn't take hold.
On Thu, Aug 8, 2013 at 7:10 AM, Richard Sentino <ri...@mindginative.com>wrote:
> Hello
>
> I just wanted to keep the ball rolling about this issue.
>
> In response to "SecurityError be caught in an try{} block?", yes and it
> seems to do the trick. At the moment, out of the FirefoxOS-specific APIs it
> gets stuck in the mud at "mozTime" [1] which is only available to certified
> apps [2] therefore a security error will be thrown [3]. With the recently
> refactored cordova-js, do you guys have any intention on clobbering
> navigator at the platform.js level ? I made a test app [4] running on 3.0.x
> from master branch and tested on FirefoxOS 4.0/5.0pre simulator and on a
> Keon device.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=751011#c3
> [2]
> https://developer.mozilla.org/en-US/docs/Web/API/window.navigator.mozTime
> [3]
> https://github.com/apache/cordova-js/blob/master/lib/common/init.js#L56
> [4] http://rixrix.github.io/cordova-firefoxos-patch/manifest.webapp
>
> Thanks
>
> --
> Richard
>
>
> On 25/06/2013, at 8:25 AM, Andrew Grieve <ag...@chromium.org> wrote:
>
> We also used this to implement navigator.connection. Without this, we can't
> replace the connection property. Another example is the onLine property for
> Android. It needs to be overridden to hide the fact that it is toggled
> on/off by our exec() bridge.
>
>
> On Mon, Jun 24, 2013 at 3:59 PM, Gord Tanner <gt...@gmail.com> wrote:
>
>> This might be a bad example since most platforms support native
> geolocation
>> now but I know we would run into problems with:
>>
>> navigator.geolocation = require('cordova/plugin/geolocation')
>>
>> When geolocation already existed on navigator it would throw a security
>> exception (or just be a noop). It is the cost of doing our shit on the
>> navigator object, every platform treats this as a "secure" object
>> (rightfully so) and does things a little differently. The lowest common
>> denominator was to just dump our own mock object in ASAP to prevent a lot
>> of that security stuff from getting in our way.
>>
>> Does this still need to happen? (I don't know)
>> What platforms were having problems? (I can't really remember)
>> Should we look into if we still need to do this? (of course)
>>
>> the bootstrap.js is ment to contain code for bootstrapping all of cordova
>> on every platform. I am thinking we may need to rethink the navigator
>> clobbering and make this a platform overridable bootstrap step.
>>
>>
>>
>> On Mon, Jun 24, 2013 at 3:50 PM, Brian LeRoux <b...@brian.io> wrote:
>>
>>> But wait, and I'm serious here, why even duck punch navigator to begin
>>> with?
>>>
>>> I understand we add properties to it. Is that why it needs to be opened?
>>>
>>> On Mon, Jun 24, 2013 at 11:50 AM, Ian Clelland <ic...@google.com>
>>> wrote:
>>>> Can the SecurityError be caught in an try{} block? If so, then we could
>>>> implement a general solution of "try to clobber the entire object; if
>>> that
>>>> doesn't work, try to clobber each of its properties instead."
>>>>
>>>> In the second case, a debug log line for each property that cannot be
>>>> copied would give us a list of any platform-dependent quirks that we
>> need
>>>> to document.
>>>>
>>>>
>>>> On Mon, Jun 24, 2013 at 2:42 PM, Gord Tanner <gt...@gmail.com>
>> wrote:
>>>>
>>>>> This is from the bootstrap file for all platforms [1].
>>>>>
>>>>> This is to cover us for security issues we were having on other
>>> platforms
>>>>> where we are not able to replace existing navigator object methods
>>>>> (geolocation, etc) or add new ones. We create this object and proxy
>> to
>>> the
>>>>> original navigator object to have something that is a bit more
>> flexible
>>> for
>>>>> us to work with and modify.
>>>>>
>>>>> Does firefox yell at us if we replace the navigator object without
>>>>> iterating over the old one? We could then just hardcode the list of
>>>>> functions to proxy over to the original for that platform.
>>>>>
>>>>> [1] -
>>>>>
>>>>>
>>>
>>
> https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=blob_plain;f=lib/scripts/bootstrap.js;hb=HEAD
>>>>>
>>>>>
>>>>> On Mon, Jun 24, 2013 at 2:34 PM, Brian LeRoux <b...@brian.io> wrote:
>>>>>
>>>>>> I'm at a loss why that code even needs to exist.
>>>>>>
>>>>>> Anyone? Herm / Gord?
>>>>>>
>>>>>> On Thu, Jun 20, 2013 at 5:06 AM, Piotr Zalewa <pz...@mozilla.com>
>>>>> wrote:
>>>>>>> I came to a point where I need to use the group wisdom.
>>>>>>>
>>>>>>> In
>>>>>>
>>>>>
>>>
>>
> https://github.com/apache/cordova-firefoxos/blob/master/lib/cordova.firefoxos.js#L5929Cordovaistryingtoreplace window.navigator with something which looks
>>>>>> like a copy of itself. window.navigator is protected in FirefoxOS -
>>> even
>>>>>> browsing through its properties is not allowed.
>>>>>>>
>>>>>>> alert('pre'); for (var key in window.navigator)
>>>>> {window.navigator[key]};
>>>>>> alert('post');
>>>>>>>
>>>>>>> Above code will work in browser, but not on the device or
>>> Simulator. It
>>>>>> will throw "SecurityError: The operation is insecure." and 'post'
>> will
>>>>> not
>>>>>> get alerted. Example in JSFiddle -
>>>>>> http://jsfiddle.net/zalun/VkCyH/embedded/result/ (just install in
>>>>>> Simulator)
>>>>>>>
>>>>>>> I'm looking for a solution for that issue.
>>>>>>>
>>>>>>> Is the step with replacing window.navigator needed? The comment in
>>> the
>>>>>> code says
>>>>>>> // We replace it so that properties that can't be clobbered can
>>> instead
>>>>>> be overridden.
>>>>>>>
>>>>>>>
>>>>>>> Piotr
>>>>>>
>>>>>
>>>
>>
>
>
Re: Security Error in FirefoxOS on reading window.navigator properties
Posted by Andrew Grieve <ag...@chromium.org>.
I think it makes sense to have this be an option since it's breaking ff.
I think it's actually only required now by the
cordova-plugin-network-information plugin.
1. Maybe we could just move it into that plugin?
2. Or, we could make it a separate plugin that others wanting to override
navigator symbols can depend on.
3. Or, we could move the logic into modulemapper such that the hack is
applied only when clobbering a symbol on navigator doesn't take hold.
On Thu, Aug 8, 2013 at 7:10 AM, Richard Sentino <ri...@mindginative.com>wrote:
> Hello
>
> I just wanted to keep the ball rolling about this issue.
>
> In response to "SecurityError be caught in an try{} block?", yes and it
> seems to do the trick. At the moment, out of the FirefoxOS-specific APIs it
> gets stuck in the mud at "mozTime" [1] which is only available to certified
> apps [2] therefore a security error will be thrown [3]. With the recently
> refactored cordova-js, do you guys have any intention on clobbering
> navigator at the platform.js level ? I made a test app [4] running on 3.0.x
> from master branch and tested on FirefoxOS 4.0/5.0pre simulator and on a
> Keon device.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=751011#c3
> [2]
> https://developer.mozilla.org/en-US/docs/Web/API/window.navigator.mozTime
> [3]
> https://github.com/apache/cordova-js/blob/master/lib/common/init.js#L56
> [4] http://rixrix.github.io/cordova-firefoxos-patch/manifest.webapp
>
> Thanks
>
> --
> Richard
>
>
> On 25/06/2013, at 8:25 AM, Andrew Grieve <ag...@chromium.org> wrote:
>
> We also used this to implement navigator.connection. Without this, we can't
> replace the connection property. Another example is the onLine property for
> Android. It needs to be overridden to hide the fact that it is toggled
> on/off by our exec() bridge.
>
>
> On Mon, Jun 24, 2013 at 3:59 PM, Gord Tanner <gt...@gmail.com> wrote:
>
> > This might be a bad example since most platforms support native
> geolocation
> > now but I know we would run into problems with:
> >
> > navigator.geolocation = require('cordova/plugin/geolocation')
> >
> > When geolocation already existed on navigator it would throw a security
> > exception (or just be a noop). It is the cost of doing our shit on the
> > navigator object, every platform treats this as a "secure" object
> > (rightfully so) and does things a little differently. The lowest common
> > denominator was to just dump our own mock object in ASAP to prevent a lot
> > of that security stuff from getting in our way.
> >
> > Does this still need to happen? (I don't know)
> > What platforms were having problems? (I can't really remember)
> > Should we look into if we still need to do this? (of course)
> >
> > the bootstrap.js is ment to contain code for bootstrapping all of cordova
> > on every platform. I am thinking we may need to rethink the navigator
> > clobbering and make this a platform overridable bootstrap step.
> >
> >
> >
> > On Mon, Jun 24, 2013 at 3:50 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> >> But wait, and I'm serious here, why even duck punch navigator to begin
> >> with?
> >>
> >> I understand we add properties to it. Is that why it needs to be opened?
> >>
> >> On Mon, Jun 24, 2013 at 11:50 AM, Ian Clelland <ic...@google.com>
> >> wrote:
> >>> Can the SecurityError be caught in an try{} block? If so, then we could
> >>> implement a general solution of "try to clobber the entire object; if
> >> that
> >>> doesn't work, try to clobber each of its properties instead."
> >>>
> >>> In the second case, a debug log line for each property that cannot be
> >>> copied would give us a list of any platform-dependent quirks that we
> > need
> >>> to document.
> >>>
> >>>
> >>> On Mon, Jun 24, 2013 at 2:42 PM, Gord Tanner <gt...@gmail.com>
> > wrote:
> >>>
> >>>> This is from the bootstrap file for all platforms [1].
> >>>>
> >>>> This is to cover us for security issues we were having on other
> >> platforms
> >>>> where we are not able to replace existing navigator object methods
> >>>> (geolocation, etc) or add new ones. We create this object and proxy
> > to
> >> the
> >>>> original navigator object to have something that is a bit more
> > flexible
> >> for
> >>>> us to work with and modify.
> >>>>
> >>>> Does firefox yell at us if we replace the navigator object without
> >>>> iterating over the old one? We could then just hardcode the list of
> >>>> functions to proxy over to the original for that platform.
> >>>>
> >>>> [1] -
> >>>>
> >>>>
> >>
> >
> https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=blob_plain;f=lib/scripts/bootstrap.js;hb=HEAD
> >>>>
> >>>>
> >>>> On Mon, Jun 24, 2013 at 2:34 PM, Brian LeRoux <b...@brian.io> wrote:
> >>>>
> >>>>> I'm at a loss why that code even needs to exist.
> >>>>>
> >>>>> Anyone? Herm / Gord?
> >>>>>
> >>>>> On Thu, Jun 20, 2013 at 5:06 AM, Piotr Zalewa <pz...@mozilla.com>
> >>>> wrote:
> >>>>>> I came to a point where I need to use the group wisdom.
> >>>>>>
> >>>>>> In
> >>>>>
> >>>>
> >>
> >
> https://github.com/apache/cordova-firefoxos/blob/master/lib/cordova.firefoxos.js#L5929Cordovaistryingtoreplace window.navigator with something which looks
> >>>>> like a copy of itself. window.navigator is protected in FirefoxOS -
> >> even
> >>>>> browsing through its properties is not allowed.
> >>>>>>
> >>>>>> alert('pre'); for (var key in window.navigator)
> >>>> {window.navigator[key]};
> >>>>> alert('post');
> >>>>>>
> >>>>>> Above code will work in browser, but not on the device or
> >> Simulator. It
> >>>>> will throw "SecurityError: The operation is insecure." and 'post'
> > will
> >>>> not
> >>>>> get alerted. Example in JSFiddle -
> >>>>> http://jsfiddle.net/zalun/VkCyH/embedded/result/ (just install in
> >>>>> Simulator)
> >>>>>>
> >>>>>> I'm looking for a solution for that issue.
> >>>>>>
> >>>>>> Is the step with replacing window.navigator needed? The comment in
> >> the
> >>>>> code says
> >>>>>> // We replace it so that properties that can't be clobbered can
> >> instead
> >>>>> be overridden.
> >>>>>>
> >>>>>>
> >>>>>> Piotr
> >>>>>
> >>>>
> >>
> >
>
>