Finally got around to this. Might be nice if someone wanted to do a code review of the changes. Commits are linked off of the JIRA issue.
On Fri, Feb 7, 2014 at 10:22 AM, Andrew Grieve <[email protected]> wrote: > 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? >> >> >> > >
