On Fri, Jan 31, 2014 at 3:17 PM, Martin Georgiev <[email protected]>wrote:
> On Fri, Jan 31, 2014 at 2:14 PM, Andrew Grieve <[email protected]> > wrote: > > On Fri, Jan 31, 2014 at 3:05 PM, Martin Georgiev <[email protected] > >wrote: > > > >> On Fri, Jan 31, 2014 at 1:22 PM, Andrew Grieve <[email protected]> > >> 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.
