On Fri, Jan 31, 2014 at 5:50 PM, Andrew Grieve <[email protected]> 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 <[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? >>
