On Fri, Jan 31, 2014 at 8:57 AM, Joe Bowser <[email protected]> wrote:
> On Fri, Jan 31, 2014 at 5:14 AM, Ian Clelland <[email protected]> > wrote: > > On Thu, Jan 30, 2014 at 6:16 PM, Joe Bowser <[email protected]> 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 >
