Created a bug: https://issues.apache.org/jira/browse/CB-5988 Won't get to it today, but hopefully next week.
On Wed, Feb 5, 2014 at 4:30 PM, Joe Bowser <[email protected]> wrote: > 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? > >> >
