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 Sat, 01 Feb 2014 01:50:52 GMT
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 <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