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 <[email protected]>wrote: > 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. >
