cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: [Android] SecureToken/NoFrak feature addition
Date Fri, 07 Feb 2014 15:22:07 GMT
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 <bowserj@gmail.com> wrote:

> On Fri, Jan 31, 2014 at 5:50 PM, Andrew Grieve <agrieve@chromium.org>
> 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 <agrieve@chromium.org>
> wrote:
> >
> >>
> >>
> >>
> >> On Fri, Jan 31, 2014 at 4:34 PM, Martin Georgiev <mgeorgiev@utexas.edu
> >wrote:
> >>
> >>> On Fri, Jan 31, 2014 at 3:27 PM, Andrew Grieve <agrieve@chromium.org>
> >>> 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?
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message