cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: [iOS] proposed major whitelist change
Date Mon, 20 Jul 2015 23:24:27 GMT
Ah I forgot about the legacy whitelist plugin -- we can't remove the
whitelist totally then, but as you said "default
the new whitelist plugin to a 'wildcard' network request list until the
user adds any entries".

That will preserve backwards compat.

On Mon, Jul 20, 2015 at 4:18 PM, Treggiari, Leo <leo.treggiari@intel.com>
wrote:

> I assume this is for the new whitelist plugin as opposed to the legacy
> whitelist plugin which will continue to use the current <access> tags.
>
> Another alternative, but not necessarily better, would be to default
> the new whitelist plugin to a 'wildcard' network request list until the
> user adds any entries.  When they add an entry the default wildcard
> entry is replaced.
>
> Leo
>
> -----Original Message-----
> From: Shazron [mailto:shazron@gmail.com]
> Sent: Monday, July 20, 2015 3:45 PM
> To: dev@cordova.apache.org
> Subject: Re: [iOS] proposed major whitelist change
>
> 1. "If a user is using CSP can we tell them to specify a single '*' entry
> for the network request whitelist (a.k.a. <access> tags)?"
> We could. But comes back to my point, why recommend *two* ways, it's just
> confusing -- especially if we recommend CSP and require an <access>
> wildcard. What I'm proposing is a permanent, unchangeable access wildcard
> effectively.
>
> 2. "If they are not using CSP,  in spite of our recommendation, do the
> <access> tags provide an alternative, though inferior solution?"
> Yes, <access> is definitely inferior.
>
>
> On Mon, Jul 20, 2015 at 3:36 PM, Treggiari, Leo <leo.treggiari@intel.com>
> wrote:
>
> > I'm not certain that this makes sense, but anyway...
> >
> > If a user is using CSP can we tell them to specify a single '*' entry for
> > the network request whitelist (a.k.a. <access> tags)?
> > If they are not using CSP,  in spite of our recommendation, do the
> > <access> tags provide an alternative, though inferior solution?
> >
> > And, is this different for the Android platform which already supports
> the
> > new whitelist plugin?
> >
> > Thanks,
> > Leo
> >
> > -----Original Message-----
> > From: Shazron [mailto:shazron@gmail.com]
> > Sent: Monday, July 20, 2015 3:24 PM
> > To: dev@cordova.apache.org
> > Subject: [iOS] proposed major whitelist change
> >
> > https://github.com/apache/cordova-plugin-whitelist
> >
> > Previously, the initial implementation for the plugin for iOS didn't
> > support the <access> tag, but that proved problematic since not
> supporting
> > it meant all *native* code network connections were effectively
> > blacklisted.
> >
> > I added the support back in, but this will end up confusing the user even
> > more. Right now we are recommending that the user support CSP, but that
> > only works in the context of the WebView (whether UIWebView or
> WKWebView) -
> > ie xhr, images, etc.
> >
> > If the user specified a CSP src for access to a domain in their .html,
> but
> > did not specify an <access> tag for that domain, the connection will fail
> > (since the native code whitelist filters all network connections). So
> this
> > in effect doubles the number of declarations needed -- a CSP policy needs
> > to have its mirror in the <access> tag. You can see where this can get
> > confusing.
> >
> > We could have a dynamic CSP parser in native code to dynamically
> "generate"
> > access tags but that will add on more complexity (but this would be best
> > workaround).
> >
> > I propose that we get rid of the native code whitelist (effectively
> > allowing all connections)  and rely on CSP only. I'm not sure that
> having a
> > native code whitelist can really be truly secure, with the dynamic nature
> > of Objective-C this is just a fa├žade anyway.
> >
> > In any case, native code whitelisting will only work on UIWebView, there
> is
> > no way our current whitelisting system will work on WKWebView at all --
> > more fodder for us to abandon our whitelisting system.
> >
> > The whitelisting should really be handled lower level by the system, and
> > indeed this is coming in iOS 9 with Application Transport Security (ATS):
> >
> >
> https://developer.apple.com/library/prerelease/ios/technotes/App-Transport-Security-Technote/index.html#//apple_ref/doc/uid/TP40016240
> >
> > The ATS whitelisting is through new tags in Info.plist, and we will have
> to
> > map our existing whitelist tags to ATS when the time comes.
> >
>

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