[Android] SecureToken/NoFrak feature addition

[Joe Bowser <bo...@gmail.com>]

Hey

So, to those of you in security circles, this isn't going to come as
any surprise, but it's time we opened up this can of worms:

We got this security advisory over the break, and because it was over
the holiday break, we didn't respond to it before it made it to
BugTraq!  As you probably already know, the whitelist doesn't actually
work on Android 2.3.x for any inline assets, including iFrames.  So,
those of you who are using HTML-based ads in your app need to stop
doing that ASAP! (I'm not kidding, the certificate pinning should have
been your first hint.)

Anyway, I propose we do the following:

* Drop support for Android 2.3.x - I don't care if it's 20% of the
market, if an insecure 20% and people need to stop targeting it
because of how insecure it is.  We can't fix it, and Google and
handset makers have no interest in fixing it either.  It's the IE6 of
Mobile, and Android 2.3.x needs to die.  (In hindsight, I feel bad for
giving a friend of mine my old HTC Desire HD. :( )
* Drop support for Cordova 2.9 - I think we're at the six month window
for this already, and we've only issued one point release after 2.9.0.
* Implement NoFrak as a configurable option for people who aren't
scared of the lack of certificate pinning
* Remove support for addJavascriptInterface for any platform that uses
NoFrak below Jellybean and force them to use prompt

Now, I started work on moving NoFrak to 3.x on my own personal fork
once the PoC author signed the ICLA, and you can find the branches on
my GitHub:

https://github.com/infil00p/cordova-android/tree/SecureToken
https://github.com/infil00p/cordova-js/tree/SecureToken

If we decide to do this, I'll copy the branch over to the official
cordova-android and cordova-js repos and we can work on that fork
there.  Right now it builds, but that's about it.  I haven't
re-written the exec method yet.  Since we're moving this from a 2.9.x
based version of Cordova to the current tree, there's probably a lot
of code that can be refactored and removed.  It also needs a lot of
cleanup, so any help with that would be awesome.

Also, we're going to need tests if we're going to add this as a
feature.  This is a lot of code, but it's probably a good idea to add
this.

Joe

RE: [Android] SecureToken/NoFrak feature addition

[Jonathan Bond-Caron <jb...@gdesolutions.com>]

> > https://labs.mwrinfosecurity.com/blog/2013/09/24/webview-addjavascript
> > interface-remote-code-execution/
> >
> > > I don't know enough about the reasons for the different bridges to
> > > know whether this is a good idea or not.
> > >
> >
> > This is why we can't have nice things!
> >
> 
> Ouch... that's a good reason to disable that bridge completely for APIs < 17; never
> mind whether noFrak is enabled or not. If it's likely that addJavascriptInterface
> has other holes like this, then we should talk about removing it entirely.
> 

Seems harsh to disable that bridge completely: "The following JavaScript, *if injected into a WebView*"

This is nothing new, third party <script> tags or content are always a security concern.

Making a "safer" bridge the default seems best, it still does mean the bridge is free from third -party injection attacks.

Re: [Android] SecureToken/NoFrak feature addition

[Ian Clelland <ic...@chromium.org>]

On Fri, Jan 31, 2014 at 8:57 AM, Joe Bowser <bo...@gmail.com> wrote:

> On Fri, Jan 31, 2014 at 5:14 AM, Ian Clelland <ic...@chromium.org>
> wrote:
> > On Thu, Jan 30, 2014 at 6:16 PM, Joe Bowser <bo...@gmail.com> wrote:
> >
> >> Anyway, I propose we do the following:
> >>
> >> * Drop support for Android 2.3.x - I don't care if it's 20% of the
> >> market, if an insecure 20% and people need to stop targeting it
> >> because of how insecure it is.  We can't fix it, and Google and
> >> handset makers have no interest in fixing it either.  It's the IE6 of
> >> Mobile, and Android 2.3.x needs to die.  (In hindsight, I feel bad for
> >> giving a friend of mine my old HTC Desire HD. :( )
> >>
> >
> > +1
> >
> >
> >> * Drop support for Cordova 2.9 - I think we're at the six month window
> >> for this already, and we've only issued one point release after 2.9.0.
> >>
> >
> > +0
> >
> > If we do this, we'll need to be very clear to the community that it's
> > unsupported, and specifically that it isn't receiving any security
> updates
> > at all from this point on.
> >
> >
>
> I think we've been pretty bad about supporting 2.x branch in general.
> At least on Android, our last commit is November 1 for 2.9.1.  We
> really made a promise that we couldn't keep in saying that we were
> going to keep supporting the 2.9.x branch, and I would like to just
> come clean about this.
>

Completely agreed. In the interest of honesty, though, we need to say
"We're not releasing any more updates, and by the way, if you don't want to
be exposed to these security issues, you need to upgrade now." 2.9 vs 3.x
used to be primarily about plugins, and giving people the option of
sticking with the old everything-bundled-together architecture. Now it's
also about security, and people need to know that.


> >> * Implement NoFrak as a configurable option for people who aren't
> >> scared of the lack of certificate pinning
> >>
> >
> > We should be clear about exactly what this means -- I'm uncomfortable
> with
> > just "implement NoFrak" as a goal; it's not a phrase that means anything.
> > I'd split this into a couple of proposals:
> >
> >   1. Remove the Cordova Whitelist (not really cool with that, especially
> on
> > other platforms -- if an app wants to do it, that's what origin="*" is
> for)
>
> NoFrak still uses the Whitelist XML and still implements *, and I'm
> glad that you're not cool with removing the whitelist.  Neither am I,
> and you'll see why very quickly.
>
> >   2. Use a shared secret to authenticate communication across the bridge
> > (this is a good idea, probably on all platforms -- I think there may be
> > better ways of doing this though)
>
> I like how NoFrak hijacks localStorage to do it.  If I didn't, I
> wouldn't recommend we use it. :P
>
> >   3. Use the <access> tags in config.xml to determine what domains get to
> > use the bridge (??? That's not what they're for)
>
> That kinda is what the access tags are for.  When you whitelist
> something, you allow it in the WebView, and it gets to use the bridge.
>  I'd like to see this be configurable, where we have classic mode
> which offers strict blocking, and "NoFrak" mode, which allows for
> untrusted code to appear in iFrames, but not have access to the
> bridge.
>
> >   4. Remove the ability for the client to choose the bridge interface
> (also
> > a good idea)
> >
> > I'm +1 on 2&4 here, -1 on 1&3.
> >
>
> Can we choose? I thought it was all about feature detection.
>

I'm thinking that we can keep the whitelist to restrict network access to
external resources -- as far as I know, that's what it's for. The issue of
what domains should be allowed to fire off cordova.exec calls should be
separate.

Maybe we just need an attribute on <access> tags to allow bridge access.
I'd be much more comfortable if the CapabilityManager were to filter all of
the access tags that have some attribute, like allow-cordova-apis="yes",
and only set up tokens for those.


> >
> >> * Remove support for addJavascriptInterface for any platform that uses
> >> NoFrak below Jellybean and force them to use prompt
> >>
> >
> > So this covers APIs 11-14 (Honeycomb 3.0 to ICS 4.0.4). Do you mean that
> we
> > remove addJavascriptInterface for all of those versions? I'm not sure
> what
> > "any platform that uses NoFrak below Jellybean" means.
> >
>
> Yes, because if someone right now does something stupid and whitelists
> everything, they could run untrusted Javascript, use Java reflection
> through JS and totally pwn your phone.  I didn't think anyone was
> stupid enough to release with this code, but after reading the report,
> people are that dumb (BTW: If you did this, you should unpublish your
> app.):
>
>
> https://labs.mwrinfosecurity.com/blog/2013/09/24/webview-addjavascriptinterface-remote-code-execution/
>
> > I don't know enough about the reasons for the different bridges to know
> > whether this is a good idea or not.
> >
>
> This is why we can't have nice things!
>

Ouch... that's a good reason to disable that bridge completely for APIs <
17; never mind whether noFrak is enabled or not. If it's likely that
addJavascriptInterface has other holes like this, then we should talk about
removing it entirely.


>
> >
> >> Now, I started work on moving NoFrak to 3.x on my own personal fork
> >> once the PoC author signed the ICLA, and you can find the branches on
> >> my GitHub:
> >>
> >> https://github.com/infil00p/cordova-android/tree/SecureToken
> >> https://github.com/infil00p/cordova-js/tree/SecureToken
> >>
> >> If we decide to do this, I'll copy the branch over to the official
> >> cordova-android and cordova-js repos and we can work on that fork
> >> there.  Right now it builds, but that's about it.  I haven't
> >> re-written the exec method yet.  Since we're moving this from a 2.9.x
> >> based version of Cordova to the current tree, there's probably a lot
> >> of code that can be refactored and removed.  It also needs a lot of
> >> cleanup, so any help with that would be awesome.
> >>
> >> Also, we're going to need tests if we're going to add this as a
> >> feature.  This is a lot of code, but it's probably a good idea to add
> >> this.
> >>
> >> Joe
> >>
> >
> > Sorry to complicate things :)
> >
> > If we're doing this, I'm more than willing to help out; security is
> > important. Let me know what I can help you with.
> >
>
> Awesome! Thanks for responding so quickly.
>
> Joe
>

Re: [Android] SecureToken/NoFrak feature addition

[Jesse <pu...@gmail.com>]

It doesn't look like cordova.js is in the head ...
https://git-wip-us.apache.org/repos/asf?p=cordova-app-hello-world.git;a=blob;f=www/index.html;h=bde5741f43476e4d0c8d0c537c4c5a65f21afb8e;hb=HEAD#l37

@purplecabbage
risingj.com


On Fri, Jan 31, 2014 at 12:26 PM, Andrew Grieve <ag...@chromium.org>wrote:

> On Fri, Jan 31, 2014 at 3:17 PM, Martin Georgiev <mgeorgiev@utexas.edu
> >wrote:
>
> > On Fri, Jan 31, 2014 at 2:14 PM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> > > On Fri, Jan 31, 2014 at 3:05 PM, Martin Georgiev <mgeorgiev@utexas.edu
> > >wrote:
> > >
> > >> On Fri, Jan 31, 2014 at 1:22 PM, Andrew Grieve <ag...@chromium.org>
> > >> wrote:
> > >> > cordova.js goes in you <head>. I don't see how an iframe could get
> > loaded
> > >> > before it.
> > >>
> > >> An iframe can load an independent modified cordova.js into its own
> > origin.
> > >>
> > >
> > > Right, but it's the order that matters, no? I'm arguing that an iframe
> > > couldn't do that *before* the main frame does.
> >
> > Sure, but what I'm saying is that if JavaScript can hand a SecureToken
> > to native side, then there's nothing to prevent an attacker from
> > exploiting the bridge. Moreover, before you start protecting the
> > bridge it will be unprotected. So, the act of handing a SecureToken to
> > native side would be over an unprotected bridge.
> >
>
> What prevents it is that the attackers code doesn't get a chance to run
> until after the bridge gets "secured".
>
> Maybe you could explain a scenario where malicious code could gain access
> to the bridge? So long as cordova.js is in the <head>, I don't see how it
> can be done.
>

Re: [Android] SecureToken/NoFrak feature addition

[Andrew Grieve <ag...@chromium.org>]

On Fri, Jan 31, 2014 at 3:17 PM, Martin Georgiev <mg...@utexas.edu>wrote:

> On Fri, Jan 31, 2014 at 2:14 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > On Fri, Jan 31, 2014 at 3:05 PM, Martin Georgiev <mgeorgiev@utexas.edu
> >wrote:
> >
> >> On Fri, Jan 31, 2014 at 1:22 PM, Andrew Grieve <ag...@chromium.org>
> >> wrote:
> >> > cordova.js goes in you <head>. I don't see how an iframe could get
> loaded
> >> > before it.
> >>
> >> An iframe can load an independent modified cordova.js into its own
> origin.
> >>
> >
> > Right, but it's the order that matters, no? I'm arguing that an iframe
> > couldn't do that *before* the main frame does.
>
> Sure, but what I'm saying is that if JavaScript can hand a SecureToken
> to native side, then there's nothing to prevent an attacker from
> exploiting the bridge. Moreover, before you start protecting the
> bridge it will be unprotected. So, the act of handing a SecureToken to
> native side would be over an unprotected bridge.
>

What prevents it is that the attackers code doesn't get a chance to run
until after the bridge gets "secured".

Maybe you could explain a scenario where malicious code could gain access
to the bridge? So long as cordova.js is in the <head>, I don't see how it
can be done.

Re: [Android] SecureToken/NoFrak feature addition

[Martin Georgiev <mg...@utexas.edu>]

On Fri, Jan 31, 2014 at 2:14 PM, Andrew Grieve <ag...@chromium.org> wrote:
> On Fri, Jan 31, 2014 at 3:05 PM, Martin Georgiev <mg...@utexas.edu>wrote:
>
>> On Fri, Jan 31, 2014 at 1:22 PM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>> > cordova.js goes in you <head>. I don't see how an iframe could get loaded
>> > before it.
>>
>> An iframe can load an independent modified cordova.js into its own origin.
>>
>
> Right, but it's the order that matters, no? I'm arguing that an iframe
> couldn't do that *before* the main frame does.

Sure, but what I'm saying is that if JavaScript can hand a SecureToken
to native side, then there's nothing to prevent an attacker from
exploiting the bridge. Moreover, before you start protecting the
bridge it will be unprotected. So, the act of handing a SecureToken to
native side would be over an unprotected bridge.

Re: [Android] SecureToken/NoFrak feature addition

[Andrew Grieve <ag...@chromium.org>]

On Fri, Jan 31, 2014 at 3:05 PM, Martin Georgiev <mg...@utexas.edu>wrote:

> On Fri, Jan 31, 2014 at 1:22 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > cordova.js goes in you <head>. I don't see how an iframe could get loaded
> > before it.
>
> An iframe can load an independent modified cordova.js into its own origin.
>

Right, but it's the order that matters, no? I'm arguing that an iframe
couldn't do that *before* the main frame does.

Re: [Android] SecureToken/NoFrak feature addition

[Martin Georgiev <mg...@utexas.edu>]

On Fri, Jan 31, 2014 at 1:22 PM, Andrew Grieve <ag...@chromium.org> wrote:
> cordova.js goes in you <head>. I don't see how an iframe could get loaded
> before it.

An iframe can load an independent modified cordova.js into its own origin.

Re: [Android] SecureToken/NoFrak feature addition

[Andrew Grieve <ag...@chromium.org>]

Finally got around to this. Might be nice if someone wanted to do a code
review of the changes. Commits are linked off of the JIRA issue.


On Fri, Feb 7, 2014 at 10:22 AM, Andrew Grieve <ag...@chromium.org> wrote:

> Created a bug: https://issues.apache.org/jira/browse/CB-5988
> Won't get to it today, but hopefully next week.
>
>
>
> On Wed, Feb 5, 2014 at 4:30 PM, Joe Bowser <bo...@gmail.com> wrote:
>
>> On Fri, Jan 31, 2014 at 5:50 PM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>> > After thinking a bit more, I think it is not completely crazy for the
>> > top-level frame to be navigated to a malicious host. Quite easy
>> actually,
>> > "frame busting" is a thing.
>> >
>> > So... idea the third:
>> > Instead of using the whitelist, we use the domain of the <content> tag
>> as
>> > the only one the native side will provide a token to. Both Android and
>> iOS
>> > can know the URL of the main frame, and choose not to provide a token if
>> > the domain doesn't match that of content (with file:/// always being
>> > allowed).
>> >
>> > Alternatively, we could block navigations of the top-level frame to
>> other
>> > domains.
>> >
>> > wdyt?
>>
>> Sounds good.  Can you do a PoC of this?
>>
>> >
>> >
>> > On Fri, Jan 31, 2014 at 4:43 PM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>> >
>> >>
>> >>
>> >>
>> >> On Fri, Jan 31, 2014 at 4:34 PM, Martin Georgiev <mgeorgiev@utexas.edu
>> >wrote:
>> >>
>> >>> On Fri, Jan 31, 2014 at 3:27 PM, Andrew Grieve <ag...@chromium.org>
>> >>> wrote:
>> >>> > Why is loadUrl insecure? (hopefully something less horrible than
>> >>> > addJsInterface pre JB... :P)
>> >>>
>> >>> Think about the usecase where a benign website is framed by a
>> >>> malicious one. Again, this is server side. The app developer can't
>> >>> prevent it from happening. The framework developer must make sure that
>> >>> all usecases are handled properly.
>> >>>
>> >>
>> >>
>> >> Ah, I hadn't considered that the main frame might be malicious.
>> >>
>> >> I don't see how this would happen with a Cordova app though. We
>> strongly
>> >> encourage users to use file:/// URLs for their app. For those that use
>> >> HTTP, that's insecure anyways and would be whitelisted by this scheme.
>> If
>> >> you use HTTPS, then you should be fine, no?
>> >>
>>
>
>

Re: [Android] SecureToken/NoFrak feature addition

[Andrew Grieve <ag...@chromium.org>]

Created a bug: https://issues.apache.org/jira/browse/CB-5988
Won't get to it today, but hopefully next week.



On Wed, Feb 5, 2014 at 4:30 PM, Joe Bowser <bo...@gmail.com> wrote:

> On Fri, Jan 31, 2014 at 5:50 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > After thinking a bit more, I think it is not completely crazy for the
> > top-level frame to be navigated to a malicious host. Quite easy actually,
> > "frame busting" is a thing.
> >
> > So... idea the third:
> > Instead of using the whitelist, we use the domain of the <content> tag as
> > the only one the native side will provide a token to. Both Android and
> iOS
> > can know the URL of the main frame, and choose not to provide a token if
> > the domain doesn't match that of content (with file:/// always being
> > allowed).
> >
> > Alternatively, we could block navigations of the top-level frame to other
> > domains.
> >
> > wdyt?
>
> Sounds good.  Can you do a PoC of this?
>
> >
> >
> > On Fri, Jan 31, 2014 at 4:43 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> >
> >>
> >>
> >>
> >> On Fri, Jan 31, 2014 at 4:34 PM, Martin Georgiev <mgeorgiev@utexas.edu
> >wrote:
> >>
> >>> On Fri, Jan 31, 2014 at 3:27 PM, Andrew Grieve <ag...@chromium.org>
> >>> wrote:
> >>> > Why is loadUrl insecure? (hopefully something less horrible than
> >>> > addJsInterface pre JB... :P)
> >>>
> >>> Think about the usecase where a benign website is framed by a
> >>> malicious one. Again, this is server side. The app developer can't
> >>> prevent it from happening. The framework developer must make sure that
> >>> all usecases are handled properly.
> >>>
> >>
> >>
> >> Ah, I hadn't considered that the main frame might be malicious.
> >>
> >> I don't see how this would happen with a Cordova app though. We strongly
> >> encourage users to use file:/// URLs for their app. For those that use
> >> HTTP, that's insecure anyways and would be whitelisted by this scheme.
> If
> >> you use HTTPS, then you should be fine, no?
> >>
>

Re: [Android] SecureToken/NoFrak feature addition

[Joe Bowser <bo...@gmail.com>]

On Fri, Jan 31, 2014 at 5:50 PM, Andrew Grieve <ag...@chromium.org> wrote:
> After thinking a bit more, I think it is not completely crazy for the
> top-level frame to be navigated to a malicious host. Quite easy actually,
> "frame busting" is a thing.
>
> So... idea the third:
> Instead of using the whitelist, we use the domain of the <content> tag as
> the only one the native side will provide a token to. Both Android and iOS
> can know the URL of the main frame, and choose not to provide a token if
> the domain doesn't match that of content (with file:/// always being
> allowed).
>
> Alternatively, we could block navigations of the top-level frame to other
> domains.
>
> wdyt?

Sounds good.  Can you do a PoC of this?

>
>
> On Fri, Jan 31, 2014 at 4:43 PM, Andrew Grieve <ag...@chromium.org> wrote:
>
>>
>>
>>
>> On Fri, Jan 31, 2014 at 4:34 PM, Martin Georgiev <mg...@utexas.edu>wrote:
>>
>>> On Fri, Jan 31, 2014 at 3:27 PM, Andrew Grieve <ag...@chromium.org>
>>> wrote:
>>> > Why is loadUrl insecure? (hopefully something less horrible than
>>> > addJsInterface pre JB... :P)
>>>
>>> Think about the usecase where a benign website is framed by a
>>> malicious one. Again, this is server side. The app developer can't
>>> prevent it from happening. The framework developer must make sure that
>>> all usecases are handled properly.
>>>
>>
>>
>> Ah, I hadn't considered that the main frame might be malicious.
>>
>> I don't see how this would happen with a Cordova app though. We strongly
>> encourage users to use file:/// URLs for their app. For those that use
>> HTTP, that's insecure anyways and would be whitelisted by this scheme. If
>> you use HTTPS, then you should be fine, no?
>>

Re: [Android] SecureToken/NoFrak feature addition

[Andrew Grieve <ag...@chromium.org>]

After thinking a bit more, I think it is not completely crazy for the
top-level frame to be navigated to a malicious host. Quite easy actually,
"frame busting" is a thing.

So... idea the third:
Instead of using the whitelist, we use the domain of the <content> tag as
the only one the native side will provide a token to. Both Android and iOS
can know the URL of the main frame, and choose not to provide a token if
the domain doesn't match that of content (with file:/// always being
allowed).

Alternatively, we could block navigations of the top-level frame to other
domains.

wdyt?






On Fri, Jan 31, 2014 at 4:43 PM, Andrew Grieve <ag...@chromium.org> wrote:

>
>
>
> On Fri, Jan 31, 2014 at 4:34 PM, Martin Georgiev <mg...@utexas.edu>wrote:
>
>> On Fri, Jan 31, 2014 at 3:27 PM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>> > Why is loadUrl insecure? (hopefully something less horrible than
>> > addJsInterface pre JB... :P)
>>
>> Think about the usecase where a benign website is framed by a
>> malicious one. Again, this is server side. The app developer can't
>> prevent it from happening. The framework developer must make sure that
>> all usecases are handled properly.
>>
>
>
> Ah, I hadn't considered that the main frame might be malicious.
>
> I don't see how this would happen with a Cordova app though. We strongly
> encourage users to use file:/// URLs for their app. For those that use
> HTTP, that's insecure anyways and would be whitelisted by this scheme. If
> you use HTTPS, then you should be fine, no?
>

Re: [Android] SecureToken/NoFrak feature addition

[Andrew Grieve <ag...@chromium.org>]

On Fri, Jan 31, 2014 at 5:46 PM, Joe Bowser <bo...@gmail.com> wrote:

> OK, in the interest of moving things along, I think we agreed to the
> following:
>
> 1. Adding a SecureToken is a good idea and we should implement this somehow
> 2. We should stop supporting the 2.9.x branch of Cordova like we said we
> would
> 3. We should disable addJavascriptInterface for any level below API level
> 17
>
Yep, these all sound good! Just need to hash out how to do #1, (2 and #3
don't depend on it).


>
> I'd like to preserve our old behaviour of blocking anything not
> explicitly whitelisted, and have the ability to turn on mixed content
> in iFrames with a configuration setting.  How can we move forward with
> this?
>
Not sure what you mean about turning on mixed content.



>
> On Fri, Jan 31, 2014 at 1:45 PM, Joe Bowser <bo...@gmail.com> wrote:
> > Not if your certificate is compromised.  Remember our Certificate
> > Pinning discussion!
> >
> > On Fri, Jan 31, 2014 at 1:43 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> >> On Fri, Jan 31, 2014 at 4:34 PM, Martin Georgiev <mgeorgiev@utexas.edu
> >wrote:
> >>
> >>> On Fri, Jan 31, 2014 at 3:27 PM, Andrew Grieve <ag...@chromium.org>
> >>> wrote:
> >>> > Why is loadUrl insecure? (hopefully something less horrible than
> >>> > addJsInterface pre JB... :P)
> >>>
> >>> Think about the usecase where a benign website is framed by a
> >>> malicious one. Again, this is server side. The app developer can't
> >>> prevent it from happening. The framework developer must make sure that
> >>> all usecases are handled properly.
> >>>
> >>
> >>
> >> Ah, I hadn't considered that the main frame might be malicious.
> >>
> >> I don't see how this would happen with a Cordova app though. We strongly
> >> encourage users to use file:/// URLs for their app. For those that use
> >> HTTP, that's insecure anyways and would be whitelisted by this scheme.
> If
> >> you use HTTPS, then you should be fine, no?
>

Re: [Android] SecureToken/NoFrak feature addition

[Joe Bowser <bo...@gmail.com>]

OK, in the interest of moving things along, I think we agreed to the following:

1. Adding a SecureToken is a good idea and we should implement this somehow
2. We should stop supporting the 2.9.x branch of Cordova like we said we would
3. We should disable addJavascriptInterface for any level below API level 17

I'd like to preserve our old behaviour of blocking anything not
explicitly whitelisted, and have the ability to turn on mixed content
in iFrames with a configuration setting.  How can we move forward with
this?

On Fri, Jan 31, 2014 at 1:45 PM, Joe Bowser <bo...@gmail.com> wrote:
> Not if your certificate is compromised.  Remember our Certificate
> Pinning discussion!
>
> On Fri, Jan 31, 2014 at 1:43 PM, Andrew Grieve <ag...@chromium.org> wrote:
>> On Fri, Jan 31, 2014 at 4:34 PM, Martin Georgiev <mg...@utexas.edu>wrote:
>>
>>> On Fri, Jan 31, 2014 at 3:27 PM, Andrew Grieve <ag...@chromium.org>
>>> wrote:
>>> > Why is loadUrl insecure? (hopefully something less horrible than
>>> > addJsInterface pre JB... :P)
>>>
>>> Think about the usecase where a benign website is framed by a
>>> malicious one. Again, this is server side. The app developer can't
>>> prevent it from happening. The framework developer must make sure that
>>> all usecases are handled properly.
>>>
>>
>>
>> Ah, I hadn't considered that the main frame might be malicious.
>>
>> I don't see how this would happen with a Cordova app though. We strongly
>> encourage users to use file:/// URLs for their app. For those that use
>> HTTP, that's insecure anyways and would be whitelisted by this scheme. If
>> you use HTTPS, then you should be fine, no?

Re: [Android] SecureToken/NoFrak feature addition

[Joe Bowser <bo...@gmail.com>]

Not if your certificate is compromised.  Remember our Certificate
Pinning discussion!

On Fri, Jan 31, 2014 at 1:43 PM, Andrew Grieve <ag...@chromium.org> wrote:
> On Fri, Jan 31, 2014 at 4:34 PM, Martin Georgiev <mg...@utexas.edu>wrote:
>
>> On Fri, Jan 31, 2014 at 3:27 PM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>> > Why is loadUrl insecure? (hopefully something less horrible than
>> > addJsInterface pre JB... :P)
>>
>> Think about the usecase where a benign website is framed by a
>> malicious one. Again, this is server side. The app developer can't
>> prevent it from happening. The framework developer must make sure that
>> all usecases are handled properly.
>>
>
>
> Ah, I hadn't considered that the main frame might be malicious.
>
> I don't see how this would happen with a Cordova app though. We strongly
> encourage users to use file:/// URLs for their app. For those that use
> HTTP, that's insecure anyways and would be whitelisted by this scheme. If
> you use HTTPS, then you should be fine, no?

Re: [Android] SecureToken/NoFrak feature addition

[Andrew Grieve <ag...@chromium.org>]

On Fri, Jan 31, 2014 at 4:34 PM, Martin Georgiev <mg...@utexas.edu>wrote:

> On Fri, Jan 31, 2014 at 3:27 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > Why is loadUrl insecure? (hopefully something less horrible than
> > addJsInterface pre JB... :P)
>
> Think about the usecase where a benign website is framed by a
> malicious one. Again, this is server side. The app developer can't
> prevent it from happening. The framework developer must make sure that
> all usecases are handled properly.
>


Ah, I hadn't considered that the main frame might be malicious.

I don't see how this would happen with a Cordova app though. We strongly
encourage users to use file:/// URLs for their app. For those that use
HTTP, that's insecure anyways and would be whitelisted by this scheme. If
you use HTTPS, then you should be fine, no?

Re: [Android] SecureToken/NoFrak feature addition

[Martin Georgiev <mg...@utexas.edu>]

On Fri, Jan 31, 2014 at 3:27 PM, Andrew Grieve <ag...@chromium.org> wrote:
> Why is loadUrl insecure? (hopefully something less horrible than
> addJsInterface pre JB... :P)

Think about the usecase where a benign website is framed by a
malicious one. Again, this is server side. The app developer can't
prevent it from happening. The framework developer must make sure that
all usecases are handled properly.

Re: [Android] SecureToken/NoFrak feature addition

[Andrew Grieve <ag...@chromium.org>]

On Fri, Jan 31, 2014 at 4:13 PM, Martin Georgiev <mg...@utexas.edu>wrote:

> On Fri, Jan 31, 2014 at 2:58 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > Ha! Well that's pretty clear. :) I don't think having JS generate it is a
> > good idea then.
>
> It is not. You as an app developer do not control who puts where their JS.
>
>
> > Still, there might be an easier way than going through persistent
> storage.
>
> The reason for localStorage is cause it leverages SOP. If you find
> another way to leverage SOP, that would be fine too.
>

Providing bridge access to all frames of the same domain is harder than
providing it to just the top-frame, which is our current promise. To make
the bridge respect SOP, we'd need to make changes across all platforms (no
idea how you'd do this on iOS). Since same-domain frames run in the same JS
context, I think it's better to just continue to promise the bridge be
available to the top frame.

I *do* like the idea of explicitly blocking access to non-same-domain
iframes though.


>
> > Next idea:
> > How about having the Java side tell the JS side during start-up what the
> > token is?
> > E.g.: loadUrl(javascript:void(execToken=FOO)). JS can then get the token
> > from there when they want to use exec().
>
> Can't do that, cause loadUrl *is* insecure! Next idea please ;)
>

Why is loadUrl insecure? (hopefully something less horrible than
addJsInterface pre JB... :P)

Re: [Android] SecureToken/NoFrak feature addition

[Martin Georgiev <mg...@utexas.edu>]

On Fri, Jan 31, 2014 at 4:40 PM, Joe Bowser <bo...@gmail.com> wrote:
> On Fri, Jan 31, 2014 at 1:39 PM, Martin Georgiev <mg...@utexas.edu> wrote:
>>
>> Agree. Yet, it is unlikely that app developers will start caring about
>> security. All they care about is getting their app published (and
>> possibly making some $ off it). So, unless the framework developer
>> makes sure that all usecases are handled properly, there will always
>> be some users being hosed.
>
> It's software.  There are ALWAYS some users being hosed.  There's lot
> of nasty things you can do with the Android and iOS core frameworks as
> well.  You're familiar with the security-functionality-ease of use
> triangle, right?

Yep. I am. Well, just pointing it out. You guys decide which way is best.

Re: [Android] SecureToken/NoFrak feature addition

[Joe Bowser <bo...@gmail.com>]

On Fri, Jan 31, 2014 at 1:39 PM, Martin Georgiev <mg...@utexas.edu> wrote:
>
> Agree. Yet, it is unlikely that app developers will start caring about
> security. All they care about is getting their app published (and
> possibly making some $ off it). So, unless the framework developer
> makes sure that all usecases are handled properly, there will always
> be some users being hosed.

It's software.  There are ALWAYS some users being hosed.  There's lot
of nasty things you can do with the Android and iOS core frameworks as
well.  You're familiar with the security-functionality-ease of use
triangle, right?

Re: [Android] SecureToken/NoFrak feature addition

[Martin Georgiev <mg...@utexas.edu>]

On Fri, Jan 31, 2014 at 3:28 PM, Joe Bowser <bo...@gmail.com> wrote:
> On Fri, Jan 31, 2014 at 1:13 PM, Martin Georgiev <mg...@utexas.edu> wrote:
>> On Fri, Jan 31, 2014 at 2:58 PM, Andrew Grieve <ag...@chromium.org> wrote:
>>> Ha! Well that's pretty clear. :) I don't think having JS generate it is a
>>> good idea then.
>>
>> It is not. You as an app developer do not control who puts where their JS.
>>
>
> Remember, we're not App Developers, we're framework developers.  Our
> users are app developers, usually novice ones who know nothing about
> security, and do stupid things like include random JS from anywhere on
> the web.  These are the same people who do really stupid things like
> publish apps with practically no whitelist.
>
> This exercise is about adding a blade guard to our circular saw.  Our
> users can still cut their hands off by being stupid, but it should be
> obvious that's what they're doing.

Agree. Yet, it is unlikely that app developers will start caring about
security. All they care about is getting their app published (and
possibly making some $ off it). So, unless the framework developer
makes sure that all usecases are handled properly, there will always
be some users being hosed.

Re: [Android] SecureToken/NoFrak feature addition

[Joe Bowser <bo...@gmail.com>]

On Fri, Jan 31, 2014 at 1:13 PM, Martin Georgiev <mg...@utexas.edu> wrote:
> On Fri, Jan 31, 2014 at 2:58 PM, Andrew Grieve <ag...@chromium.org> wrote:
>> Ha! Well that's pretty clear. :) I don't think having JS generate it is a
>> good idea then.
>
> It is not. You as an app developer do not control who puts where their JS.
>

Remember, we're not App Developers, we're framework developers.  Our
users are app developers, usually novice ones who know nothing about
security, and do stupid things like include random JS from anywhere on
the web.  These are the same people who do really stupid things like
publish apps with practically no whitelist.

This exercise is about adding a blade guard to our circular saw.  Our
users can still cut their hands off by being stupid, but it should be
obvious that's what they're doing.

Re: [Android] SecureToken/NoFrak feature addition

[Martin Georgiev <mg...@utexas.edu>]

On Fri, Jan 31, 2014 at 2:58 PM, Andrew Grieve <ag...@chromium.org> wrote:
> Ha! Well that's pretty clear. :) I don't think having JS generate it is a
> good idea then.

It is not. You as an app developer do not control who puts where their JS.


> Still, there might be an easier way than going through persistent storage.

The reason for localStorage is cause it leverages SOP. If you find
another way to leverage SOP, that would be fine too.

> Next idea:
> How about having the Java side tell the JS side during start-up what the
> token is?
> E.g.: loadUrl(javascript:void(execToken=FOO)). JS can then get the token
> from there when they want to use exec().

Can't do that, cause loadUrl *is* insecure! Next idea please ;)

Re: [Android] SecureToken/NoFrak feature addition

[Andrew Grieve <ag...@chromium.org>]

Ha! Well that's pretty clear. :) I don't think having JS generate it is a
good idea then.

Still, there might be an easier way than going through persistent storage.

Next idea:
How about having the Java side tell the JS side during start-up what the
token is?
E.g.: loadUrl(javascript:void(execToken=FOO)). JS can then get the token
from there when they want to use exec().



On Fri, Jan 31, 2014 at 3:48 PM, Bas Bosman <ma...@nazgul.nu> wrote:

> > cordova.js goes in you <head>. I don't see how an iframe could get loaded
> > before it.
>
> Is that always the case? A lot of people consider it a best practice to
> include all script files at the end of the <body> for performance reasons:
> http://developer.yahoo.com/performance/rules.html#js_bottom
>
> In that situation the <iframe> tag would be before the cordova.js <script>
> tag.
>
> Bas
>
>

Re: [Android] SecureToken/NoFrak feature addition

[Bas Bosman <ma...@nazgul.nu>]

> cordova.js goes in you <head>. I don't see how an iframe could get loaded
> before it.

Is that always the case? A lot of people consider it a best practice to
include all script files at the end of the <body> for performance reasons:
http://developer.yahoo.com/performance/rules.html#js_bottom

In that situation the <iframe> tag would be before the cordova.js <script>
tag.

Bas

Re: [Android] SecureToken/NoFrak feature addition

[Andrew Grieve <ag...@chromium.org>]

cordova.js goes in you <head>. I don't see how an iframe could get loaded
before it.


On Fri, Jan 31, 2014 at 2:08 PM, Martin Georgiev <mg...@utexas.edu>wrote:

> On Fri, Jan 31, 2014 at 1:01 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > I don't think there's a chicken and egg problem:
> > State 0 - Native has no token, JS has no token
> > State 1 - JS in main frame include cordova.js
> > State 2 - JS in main frame generates a token, and provides it to native
> > State 3 - Native, not already having a token, accepts it and saves it.
> >
> > Now both JS and native have the same token in memory without needing to
> go
> > through localstorage.
>
> I read the above as:
>
> State 0 - Native has no token, JS has no token
> State 1 - JS in iframe include a modified cordova.js
> State 2 - JS in iframe generates a token, and provides it to native.
> State 2' - Due to frame confusion in some configurations the token is
> visible to anyone.
> State 3 - Native, not already having a token, accepts it and saves it.
>
> Now both JS (both originator and attacker, any pretty much anyone who
> wanted it) and native have the same token in memory without needing to
> go through localstorage.
>

Re: [Android] SecureToken/NoFrak feature addition

[Martin Georgiev <mg...@utexas.edu>]

On Fri, Jan 31, 2014 at 1:01 PM, Andrew Grieve <ag...@chromium.org> wrote:
> I don't think there's a chicken and egg problem:
> State 0 - Native has no token, JS has no token
> State 1 - JS in main frame include cordova.js
> State 2 - JS in main frame generates a token, and provides it to native
> State 3 - Native, not already having a token, accepts it and saves it.
>
> Now both JS and native have the same token in memory without needing to go
> through localstorage.

I read the above as:

State 0 - Native has no token, JS has no token
State 1 - JS in iframe include a modified cordova.js
State 2 - JS in iframe generates a token, and provides it to native.
State 2' - Due to frame confusion in some configurations the token is
visible to anyone.
State 3 - Native, not already having a token, accepts it and saves it.

Now both JS (both originator and attacker, any pretty much anyone who
wanted it) and native have the same token in memory without needing to
go through localstorage.

Re: [Android] SecureToken/NoFrak feature addition

[Andrew Grieve <ag...@chromium.org>]

On Fri, Jan 31, 2014 at 1:32 PM, Joe Bowser <bo...@gmail.com> wrote:

> On Fri, Jan 31, 2014 at 8:57 AM, Bas Bosman <ma...@nazgul.nu> wrote:
> >
> > LocalStorage leverages the browser's same origin policy to ensure that
> > content from other origins cannot read the token and thus cannot access
> > the bridge. If we use vanilla JS there is nothing stopping the malicious
> > code from reading the random # itself before calling the bridge.
> >
>
> We're not using Vanilla JS.  Tokens have to be added for all
> whitelisted domains natively.  This is done to solve the whole Chicken
> and the Egg problem that we have with our config.xml.  The value
> should exist when the browser gets access to the storage, and it has
> to match what it is natively, which I believed is stored in memory, so
> even if the value was added in Vanilla JS, it would be caught and set
> as invalid.  I haven't tested that.
>

localstorage would allow iframes on different domains than the top one to
use the bridge. I don't think that's very compelling. iframes can use
postMessage() to talk to the main frame, which in turn can call exec. If
you really wanted to, you could provide the token to the iframe via
postMessage. Localstorage seems like overkill to me still though.

I don't think there's a chicken and egg problem:
State 0 - Native has no token, JS has no token
State 1 - JS in main frame include cordova.js
State 2 - JS in main frame generates a token, and provides it to native
State 3 - Native, not already having a token, accepts it and saves it.

Now both JS and native have the same token in memory without needing to go
through localstorage.

Re: [Android] SecureToken/NoFrak feature addition

[Joe Bowser <bo...@gmail.com>]

On Fri, Jan 31, 2014 at 8:57 AM, Bas Bosman <ma...@nazgul.nu> wrote:
>
> LocalStorage leverages the browser's same origin policy to ensure that
> content from other origins cannot read the token and thus cannot access
> the bridge. If we use vanilla JS there is nothing stopping the malicious
> code from reading the random # itself before calling the bridge.
>

We're not using Vanilla JS.  Tokens have to be added for all
whitelisted domains natively.  This is done to solve the whole Chicken
and the Egg problem that we have with our config.xml.  The value
should exist when the browser gets access to the storage, and it has
to match what it is natively, which I believed is stored in memory, so
even if the value was added in Vanilla JS, it would be caught and set
as invalid.  I haven't tested that.

Re: [Android] SecureToken/NoFrak feature addition

[Bas Bosman <ma...@nazgul.nu>]

>> >> * Drop support for Android 2.3.x - I don't care if it's 20% of the
>> >> market, if an insecure 20% and people need to stop targeting it
>> >> because of how insecure it is.  We can't fix it, and Google and
>> >> handset makers have no interest in fixing it either.  It's the IE6 of
>> >> Mobile, and Android 2.3.x needs to die.  (In hindsight, I feel bad
>> >> for giving a friend of mine my old HTC Desire HD. :( )
Because 20% is still a rather large number I would not be in favor of
dropping support for 2.3.x. Looking at my apps it's even closer to 30%. I
would be in favor though of having 2.3.x support switched off by default,
where people developing apps using Cordova have to explicitly turn that
support on and we can give them good documentation on what that will mean
and how to mitigate risks where possible.

>> >   2. Use a shared secret to authenticate communication across the
>> > bridge  (this is a good idea, probably on all platforms -- I
>> > think there may be better ways of doing this though)
>> I like how NoFrak hijacks localStorage to do it.  If I didn't, I
>> wouldn't recommend we use it. :P
>>
> What's the reason for doing this? E.g. we could
> 1 - Have JS create a random # on start-up
> 2 - Have JS tell the native side the number
> 3 - Have the native side ignore any exec calls that doesn't include that
> number.
>
> Does using localstorage do something more?

LocalStorage leverages the browser’s same origin policy to ensure that
content from other origins cannot read the token and thus cannot access
the bridge. If we use vanilla JS there is nothing stopping the malicious
code from reading the random # itself before calling the bridge.

Bas

Re: [Android] SecureToken/NoFrak feature addition

[Andrew Grieve <ag...@chromium.org>]

On Fri, Jan 31, 2014 at 8:57 AM, Joe Bowser <bo...@gmail.com> wrote:

> On Fri, Jan 31, 2014 at 5:14 AM, Ian Clelland <ic...@chromium.org>
> wrote:
> > On Thu, Jan 30, 2014 at 6:16 PM, Joe Bowser <bo...@gmail.com> wrote:
> >
> >> Anyway, I propose we do the following:
> >>
> >> * Drop support for Android 2.3.x - I don't care if it's 20% of the
> >> market, if an insecure 20% and people need to stop targeting it
> >> because of how insecure it is.  We can't fix it, and Google and
> >> handset makers have no interest in fixing it either.  It's the IE6 of
> >> Mobile, and Android 2.3.x needs to die.  (In hindsight, I feel bad for
> >> giving a friend of mine my old HTC Desire HD. :( )
> >>
> >
> > +1
> >
> >
> >> * Drop support for Cordova 2.9 - I think we're at the six month window
> >> for this already, and we've only issued one point release after 2.9.0.
> >>
> >
> > +0
> >
> > If we do this, we'll need to be very clear to the community that it's
> > unsupported, and specifically that it isn't receiving any security
> updates
> > at all from this point on.
> >
> >
>
> I think we've been pretty bad about supporting 2.x branch in general.
> At least on Android, our last commit is November 1 for 2.9.1.  We
> really made a promise that we couldn't keep in saying that we were
> going to keep supporting the 2.9.x branch, and I would like to just
> come clean about this.
>
> >> * Implement NoFrak as a configurable option for people who aren't
> >> scared of the lack of certificate pinning
> >>
> >
> > We should be clear about exactly what this means -- I'm uncomfortable
> with
> > just "implement NoFrak" as a goal; it's not a phrase that means anything.
> > I'd split this into a couple of proposals:
> >
> >   1. Remove the Cordova Whitelist (not really cool with that, especially
> on
> > other platforms -- if an app wants to do it, that's what origin="*" is
> for)
>
> NoFrak still uses the Whitelist XML and still implements *, and I'm
> glad that you're not cool with removing the whitelist.  Neither am I,
> and you'll see why very quickly.
>
> >   2. Use a shared secret to authenticate communication across the bridge
> > (this is a good idea, probably on all platforms -- I think there may be
> > better ways of doing this though)
>
> I like how NoFrak hijacks localStorage to do it.  If I didn't, I
> wouldn't recommend we use it. :P
>

What's the reason for doing this? E.g. we could
1 - Have JS create a random # on start-up
2 - Have JS tell the native side the number
3 - Have the native side ignore any exec calls that doesn't include that
number.

Does using localstorage do something more?


>
> >   3. Use the <access> tags in config.xml to determine what domains get to
> > use the bridge (??? That's not what they're for)
>
> That kinda is what the access tags are for.  When you whitelist
> something, you allow it in the WebView, and it gets to use the bridge.
>  I'd like to see this be configurable, where we have classic mode
> which offers strict blocking, and "NoFrak" mode, which allows for
> untrusted code to appear in iFrames, but not have access to the
> bridge.
>

Is the proposal here to enable use of exec() for iframes that have a src=
that's not in your whitelist? I don't think we really do anything to make
exec() work form iframes right now, so I'd be happy to explicitly disable
exec() in all iframes. If you want your iframe to be able to call exec,
make it same-domain and use top.cordova.exec(). wdyt?



>
> >   4. Remove the ability for the client to choose the bridge interface
> (also
> > a good idea)
> >
> > I'm +1 on 2&4 here, -1 on 1&3.
> >
>
> Can we choose? I thought it was all about feature detection.
>

Right now they are all enabled on the native side, and you can use a setter
in JS to specify which to use. So long as we disable the insecure one (JS
interface on < JB), I don't see a reason to disallow this.


>
> >
> >> * Remove support for addJavascriptInterface for any platform that uses
> >> NoFrak below Jellybean and force them to use prompt
> >>
> >
> > So this covers APIs 11-14 (Honeycomb 3.0 to ICS 4.0.4). Do you mean that
> we
> > remove addJavascriptInterface for all of those versions? I'm not sure
> what
> > "any platform that uses NoFrak below Jellybean" means.
> >
>
> Yes, because if someone right now does something stupid and whitelists
> everything, they could run untrusted Javascript, use Java reflection
> through JS and totally pwn your phone.  I didn't think anyone was
> stupid enough to release with this code, but after reading the report,
> people are that dumb (BTW: If you did this, you should unpublish your
> app.):
>
>
> https://labs.mwrinfosecurity.com/blog/2013/09/24/webview-addjavascriptinterface-remote-code-execution/
>
> > I don't know enough about the reasons for the different bridges to know
> > whether this is a good idea or not.
> >
>
> This is why we can't have nice things!
>

+1 here. Not a big deal to force use of prompt bridge.



>
> >
> >> Now, I started work on moving NoFrak to 3.x on my own personal fork
> >> once the PoC author signed the ICLA, and you can find the branches on
> >> my GitHub:
> >>
> >> https://github.com/infil00p/cordova-android/tree/SecureToken
> >> https://github.com/infil00p/cordova-js/tree/SecureToken
> >>
> >> If we decide to do this, I'll copy the branch over to the official
> >> cordova-android and cordova-js repos and we can work on that fork
> >> there.  Right now it builds, but that's about it.  I haven't
> >> re-written the exec method yet.  Since we're moving this from a 2.9.x
> >> based version of Cordova to the current tree, there's probably a lot
> >> of code that can be refactored and removed.  It also needs a lot of
> >> cleanup, so any help with that would be awesome.
> >>
> >> Also, we're going to need tests if we're going to add this as a
> >> feature.  This is a lot of code, but it's probably a good idea to add
> >> this.
> >>
> >> Joe
> >>
> >
> > Sorry to complicate things :)
> >
> > If we're doing this, I'm more than willing to help out; security is
> > important. Let me know what I can help you with.
> >
>
> Awesome! Thanks for responding so quickly.
>
> Joe
>

Re: [Android] SecureToken/NoFrak feature addition

[Joe Bowser <bo...@gmail.com>]

On Fri, Jan 31, 2014 at 5:14 AM, Ian Clelland <ic...@chromium.org> wrote:
> On Thu, Jan 30, 2014 at 6:16 PM, Joe Bowser <bo...@gmail.com> wrote:
>
>> Anyway, I propose we do the following:
>>
>> * Drop support for Android 2.3.x - I don't care if it's 20% of the
>> market, if an insecure 20% and people need to stop targeting it
>> because of how insecure it is.  We can't fix it, and Google and
>> handset makers have no interest in fixing it either.  It's the IE6 of
>> Mobile, and Android 2.3.x needs to die.  (In hindsight, I feel bad for
>> giving a friend of mine my old HTC Desire HD. :( )
>>
>
> +1
>
>
>> * Drop support for Cordova 2.9 - I think we're at the six month window
>> for this already, and we've only issued one point release after 2.9.0.
>>
>
> +0
>
> If we do this, we'll need to be very clear to the community that it's
> unsupported, and specifically that it isn't receiving any security updates
> at all from this point on.
>
>

I think we've been pretty bad about supporting 2.x branch in general.
At least on Android, our last commit is November 1 for 2.9.1.  We
really made a promise that we couldn't keep in saying that we were
going to keep supporting the 2.9.x branch, and I would like to just
come clean about this.

>> * Implement NoFrak as a configurable option for people who aren't
>> scared of the lack of certificate pinning
>>
>
> We should be clear about exactly what this means -- I'm uncomfortable with
> just "implement NoFrak" as a goal; it's not a phrase that means anything.
> I'd split this into a couple of proposals:
>
>   1. Remove the Cordova Whitelist (not really cool with that, especially on
> other platforms -- if an app wants to do it, that's what origin="*" is for)

NoFrak still uses the Whitelist XML and still implements *, and I'm
glad that you're not cool with removing the whitelist.  Neither am I,
and you'll see why very quickly.

>   2. Use a shared secret to authenticate communication across the bridge
> (this is a good idea, probably on all platforms -- I think there may be
> better ways of doing this though)

I like how NoFrak hijacks localStorage to do it.  If I didn't, I
wouldn't recommend we use it. :P

>   3. Use the <access> tags in config.xml to determine what domains get to
> use the bridge (??? That's not what they're for)

That kinda is what the access tags are for.  When you whitelist
something, you allow it in the WebView, and it gets to use the bridge.
 I'd like to see this be configurable, where we have classic mode
which offers strict blocking, and "NoFrak" mode, which allows for
untrusted code to appear in iFrames, but not have access to the
bridge.

>   4. Remove the ability for the client to choose the bridge interface (also
> a good idea)
>
> I'm +1 on 2&4 here, -1 on 1&3.
>

Can we choose? I thought it was all about feature detection.

>
>> * Remove support for addJavascriptInterface for any platform that uses
>> NoFrak below Jellybean and force them to use prompt
>>
>
> So this covers APIs 11-14 (Honeycomb 3.0 to ICS 4.0.4). Do you mean that we
> remove addJavascriptInterface for all of those versions? I'm not sure what
> "any platform that uses NoFrak below Jellybean" means.
>

Yes, because if someone right now does something stupid and whitelists
everything, they could run untrusted Javascript, use Java reflection
through JS and totally pwn your phone.  I didn't think anyone was
stupid enough to release with this code, but after reading the report,
people are that dumb (BTW: If you did this, you should unpublish your
app.):

https://labs.mwrinfosecurity.com/blog/2013/09/24/webview-addjavascriptinterface-remote-code-execution/

> I don't know enough about the reasons for the different bridges to know
> whether this is a good idea or not.
>

This is why we can't have nice things!

>
>> Now, I started work on moving NoFrak to 3.x on my own personal fork
>> once the PoC author signed the ICLA, and you can find the branches on
>> my GitHub:
>>
>> https://github.com/infil00p/cordova-android/tree/SecureToken
>> https://github.com/infil00p/cordova-js/tree/SecureToken
>>
>> If we decide to do this, I'll copy the branch over to the official
>> cordova-android and cordova-js repos and we can work on that fork
>> there.  Right now it builds, but that's about it.  I haven't
>> re-written the exec method yet.  Since we're moving this from a 2.9.x
>> based version of Cordova to the current tree, there's probably a lot
>> of code that can be refactored and removed.  It also needs a lot of
>> cleanup, so any help with that would be awesome.
>>
>> Also, we're going to need tests if we're going to add this as a
>> feature.  This is a lot of code, but it's probably a good idea to add
>> this.
>>
>> Joe
>>
>
> Sorry to complicate things :)
>
> If we're doing this, I'm more than willing to help out; security is
> important. Let me know what I can help you with.
>

Awesome! Thanks for responding so quickly.

Joe

Re: [Android] SecureToken/NoFrak feature addition

[Ian Clelland <ic...@chromium.org>]

On Thu, Jan 30, 2014 at 6:16 PM, Joe Bowser <bo...@gmail.com> wrote:

> Anyway, I propose we do the following:
>
> * Drop support for Android 2.3.x - I don't care if it's 20% of the
> market, if an insecure 20% and people need to stop targeting it
> because of how insecure it is.  We can't fix it, and Google and
> handset makers have no interest in fixing it either.  It's the IE6 of
> Mobile, and Android 2.3.x needs to die.  (In hindsight, I feel bad for
> giving a friend of mine my old HTC Desire HD. :( )
>

+1


> * Drop support for Cordova 2.9 - I think we're at the six month window
> for this already, and we've only issued one point release after 2.9.0.
>

+0

If we do this, we'll need to be very clear to the community that it's
unsupported, and specifically that it isn't receiving any security updates
at all from this point on.


> * Implement NoFrak as a configurable option for people who aren't
> scared of the lack of certificate pinning
>

We should be clear about exactly what this means -- I'm uncomfortable with
just "implement NoFrak" as a goal; it's not a phrase that means anything.
I'd split this into a couple of proposals:

  1. Remove the Cordova Whitelist (not really cool with that, especially on
other platforms -- if an app wants to do it, that's what origin="*" is for)
  2. Use a shared secret to authenticate communication across the bridge
(this is a good idea, probably on all platforms -- I think there may be
better ways of doing this though)
  3. Use the <access> tags in config.xml to determine what domains get to
use the bridge (??? That's not what they're for)
  4. Remove the ability for the client to choose the bridge interface (also
a good idea)

I'm +1 on 2&4 here, -1 on 1&3.


> * Remove support for addJavascriptInterface for any platform that uses
> NoFrak below Jellybean and force them to use prompt
>

So this covers APIs 11-14 (Honeycomb 3.0 to ICS 4.0.4). Do you mean that we
remove addJavascriptInterface for all of those versions? I'm not sure what
"any platform that uses NoFrak below Jellybean" means.

I don't know enough about the reasons for the different bridges to know
whether this is a good idea or not.


> Now, I started work on moving NoFrak to 3.x on my own personal fork
> once the PoC author signed the ICLA, and you can find the branches on
> my GitHub:
>
> https://github.com/infil00p/cordova-android/tree/SecureToken
> https://github.com/infil00p/cordova-js/tree/SecureToken
>
> If we decide to do this, I'll copy the branch over to the official
> cordova-android and cordova-js repos and we can work on that fork
> there.  Right now it builds, but that's about it.  I haven't
> re-written the exec method yet.  Since we're moving this from a 2.9.x
> based version of Cordova to the current tree, there's probably a lot
> of code that can be refactored and removed.  It also needs a lot of
> cleanup, so any help with that would be awesome.
>
> Also, we're going to need tests if we're going to add this as a
> feature.  This is a lot of code, but it's probably a good idea to add
> this.
>
> Joe
>

Sorry to complicate things :)

If we're doing this, I'm more than willing to help out; security is
important. Let me know what I can help you with.

Ian

Re: [Android] SecureToken/NoFrak feature addition

[Martin Georgiev <mg...@utexas.edu>]

On Fri, Jan 31, 2014 at 12:01 PM, Marcel Kinard <cm...@gmail.com> wrote:
>> * Remove support for addJavascriptInterface for any platform that uses
>> NoFrak below Jellybean and force them to use prompt
>
> In principle, this sounds reasonable, along with Ian's suggestion to maybe be a bit more aggressive in the removal. The MWR article does scare me.

You do not need to remove support for addJavascriptInterface. After
all, it is the intended way to build bridges on Android. All you need
to do here is handle it appropriately. That is, for Android > 17, use
addJavascriptInterface; For Android < 17, use JavaScript prompt. Real
simple. Just a couple of lines of code which run at app initialization
time to determine configuration. This behavior is totally transparent
to the app developer and the app user. That's it.

Re: [Android] SecureToken/NoFrak feature addition

[Marcel Kinard <cm...@gmail.com>]

On Jan 30, 2014, at 6:16 PM, Joe Bowser <bo...@gmail.com> wrote:

> * Drop support for Android 2.3.x - I don't care if it's 20% of the
> market, if an insecure 20% and people need to stop targeting it
> because of how insecure it is.  We can't fix it, and Google and
> handset makers have no interest in fixing it either.  It's the IE6 of
> Mobile, and Android 2.3.x needs to die.  (In hindsight, I feel bad for
> giving a friend of mine my old HTC Desire HD. :( )

-1. I'd use stronger number if I could. I agree that 2.3 being insecure makes it even more of a pain, and it is the IE6 of mobile, and should die. But it's 20% of the market and we aren't able to kill it. I was in the grocery store this week and stopped to look at the no-contract phones there, and every single new Android phone was shipping with 2.3. New phones, yeah. If we drop support for 2.3 then we put app developers between a rock and a hard place, and give them a reason to not use Cordova. I don't think that is what our mission is. 

If an app doesn't load 3rd-party ads or similar risky behavior, then we would be prematurely limiting them.

If the usage was 6% of the market, then I'd probably have a different response.

So I'd suggest that we continue support for 2.3, and communicate very clearly to app developers what the risks are with 2.3 and let *them* decide if their apps should run on 2.3 or if minsdk needs to be higher.

> * Drop support for Cordova 2.9 - I think we're at the six month window
> for this already, and we've only issued one point release after 2.9.0.

+1. As you pointed out, we haven't been very active at fixing defects there. We really are focused at putting commits only on master. The 6 months we promised have expired, let's just let 2.9 officially go inactive.

> * Implement NoFrak as a configurable option for people who aren't
> scared of the lack of certificate pinning

I'm not familiar with the implementation, but does it need to be configurable, or should it just have a fixed value? Unless there is a good use case for multiple values, just be prescriptive and keep the overall config simpler.

> * Remove support for addJavascriptInterface for any platform that uses
> NoFrak below Jellybean and force them to use prompt

In principle, this sounds reasonable, along with Ian's suggestion to maybe be a bit more aggressive in the removal. The MWR article does scare me.