I'm not completely certain of how the whitelist plugin is supposed to work
after this discussion.
To get the legacy whitelist plugin out of the way, if there are no <access>
entries, then the network web access is blocked, right? Which is why the
pre-5.0 default 'HelloCordova' app added
<access origin="*" />
That maintains compatibility with the 4.x whitelist support.
On to the new whitelist plugin, what I was suggesting and what I believe
Shazron agreed with is that if there are no <access> entries, then network
requests are wide open and security is handled via CSP.
Ian answered that this is the same for Android, which would be good!
What concerns me is that the documentation says this:
"Without any <access> tags, only requests to file:// URLs are allowed.
However, the default Cordova application includes <access origin="*"> by
default."
and 'HelloCordova' indeed has that line.
So, is the whitelist plugin network request list "*" with no <access> entries,
or
"*" because of the <access> entry added to the default project?
Thanks,
Leo
-----Original Message-----
From: Carlos Santana [mailto:csantan...@gmail.com]
Sent: Wednesday, July 22, 2015 3:37 PM
To: dev@cordova.apache.org
Subject: Re: [iOS] proposed major whitelist change
+1 CSP wins, otherwise we give false sense of security if not done
consistently
On Mon, Jul 20, 2015 at 9:32 PM Ian Clelland <iclell...@chromium.org> wrote:
> +1 to CSP as the "right way to do it".
>
> This all sounds very similar to what we ended up doing with the Android
> whitelist plugins: Default is (ugh) *, and the strong recommendation is to
> use CSP to actually filter requests from the WebView.
>
> On Mon, Jul 20, 2015 at 7:24 PM, Shazron <shaz...@gmail.com> wrote:
>
> > 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.treggi...@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:shaz...@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.treggi...@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:shaz...@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.
> > > >
> > >
> >
>
