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, 04 Jul 2014 02:13:05 GMT
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 <agrieve@chromium.org> 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 <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