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 <[email protected]> wrote: > > > > On Fri, Jan 31, 2014 at 4:34 PM, Martin Georgiev <[email protected]>wrote: > >> On Fri, Jan 31, 2014 at 3:27 PM, Andrew Grieve <[email protected]> >> 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? >
