That's a good point Chuck. Since the meaning of <access> would be changing in a dramatic way, I think we should just come up with something new, and leave <access> for anyone that wants to use the legacy-whitelist plugin.
Maybe: <allow-navigation>PATTERN</allow-navigation> <allow-system-url>PATTERN</allow-system-url> On Wed, Dec 17, 2014 at 5:29 PM, Chuck Lantz <[email protected]> wrote: > > Yeah, I also am thinking about "upgrade" situations where someone takes an > existing app and moves it to Android Cordova 4.0. It strikes me there we'd > either want the existing behavior to be preserved (flaws aside) or move it > to the top level nav behavior. Did I read correctly the current whitelist > would be refactored out to a plugin? > > -Chuck > > -----Original Message----- > From: Ian Clelland [mailto:[email protected]] > Sent: Wednesday, December 17, 2014 1:02 PM > To: [email protected] > Subject: Re: How to handle CSP for XHR in Cordova 4.0 > > I think that access tags (and the widget spec generally) were never a good > fit for the top-level-navigation case. Widgets, as far as I know, were > always intended to be single page apps, and the <access> tag wouldn't have > any affect on that at all. > > We've used it for nav in the past, though, so the question is whether > familiarity with the old syntax trumps the fact that we're changing the > behaviour. > > On Wed Dec 17 2014 at 11:47:02 AM Chuck Lantz <[email protected]> > wrote: > > > I suppose that is a good question. I took a look at the Widget Access > > Request Policy W3C spec where that element comes from. It's actually > > pretty ambiguous. > > > > "A user agent enforces an access request policy. ... In the default > > policy, a user agent must deny access to network resources external to > > the widget by default, whether this access is requested through APIs > (e.g. > > XMLHttpRequest) or through markup (e.g. iframe, script, img).." > > > > ... but... > > > > "A user agent may apply a different default policy if the widget is > > being used in a context that defines its own policy, such as for > > instance a widget served over HTTP. A more lenient policy can be > > defined with the access-request list as defined in the processing > > section. ... Furthermore, a user agent may grant access to certain URI > > schemes (e.g., mailto:) without the need of an access request if its > > security policy considers those schemes benign." > > > > It strikes me that today we implement the default policy and what > > we're proposing here is a more lenient, alternate policy. > > > > For what it's worth, here's how this is defined in the Windows world: > > > > <ApplicationContentUriRules> > > <Rule Match="https://www.google.com"; Type="include" /> > > </ApplicationContentUriRules> > > > > -Chuck > > > > -----Original Message----- > > From: Ian Clelland [mailto:[email protected]] > > Sent: Wednesday, December 17, 2014 8:16 AM > > To: [email protected] > > Subject: Re: How to handle CSP for XHR in Cordova 4.0 > > > > Definitely want to handle iOS, with the same policy. I've been working > > on that in parallel with Android. > > > > Do we want to use <access> for Nav? I wasn't sure, given its history, > > and the fact that we're changing its behaviour. Is it better to stick > > with the familiar tag and change what it tries to do? Or create a new > > tag and deprecate <access>? > > > > On Wed Dec 17 2014 at 10:30:18 AM Chuck Lantz <[email protected]> > > wrote: > > > > > What about top level nav and script access? Would the thought be > > > that the <access> elements would map to that in the base platform? > > > I'm thinking in terms of consistency across the different platforms. > > > It strikes me we'd want to update iOS at least as well. > > > > > > -Chuck > > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] On Behalf Of > > > Andrew Grieve > > > Sent: Tuesday, December 16, 2014 7:21 AM > > > To: dev > > > Subject: Re: How to handle CSP for XHR in Cordova 4.0 > > > > > > On Mon, Dec 15, 2014 at 8:19 PM, Chuck Lantz <[email protected]> > > wrote: > > > > > > > > Near term, for Windows 8.0/8.1, a custom security policy is in > > > > place at the platform level for store apps so CSP doesn't really > > > > apply there at the moment. (And, to be really specific, CSP > > > > support is pretty limited in > > > > IE10/11 focusing on the sandbox directive. The Windows 10 Tech > > > > Preview is where you can see the real support in IE right now.) > > > > So, it's a more of forward-thinking topic in that world. > > > > > > > > A related question, however - CSP support only started in the > > > > Android browser with 4.4 did it not? Obviously Crosswalk would > > > > have it but what about when using the base browser? Is the > > > > thought devs should use the old whitelist model here? > > > > > > > > > > I think one of the big issues is that the whitelist never worked for > > > blocking *all* requests. It didn't work pre-3.0, and it doesn't > > > block <audio>, <video>, websocket in any version. Supporting the > > > illusion of a whitelist is probably worse than not supporting it at > all. > > > > > > > > > > > > > > > > > Safari seems to support it back at least as far as iOS 7 (or 6 > > > > with a custom header) - the main reason I bring it up is > > > > developers could see different behaviors between devices and > > > > versions if the default CSP policy leaves something like inline or > eval disabled. > > > > > > > > -Chuck > > > > > > > > -----Original Message----- > > > > From: Ian Clelland [mailto:[email protected]] > > > > Sent: Monday, December 15, 2014 11:17 AM > > > > To: [email protected] > > > > Subject: Re: How to handle CSP for XHR in Cordova 4.0 > > > > > > > > On Mon Dec 15 2014 at 11:28:43 AM Chuck Lantz > > > > <[email protected]> > > > > wrote: > > > > > > > > > For the Windows platform, IE 10 and 11 support CSP 1.0 - there's > > > > > one subtle difference (X-Content-Security-Policy vs > > > > > Content-Security-Policy in the HTTP header). The Win 10 Tech > > > > > Preview > > > > already has full CSP support. > > > > > In general, the conventional wisdom is to push app models > > > > > towards the CSP and away from custom enforcement policies from > > > > > our point of > > > view. > > > > > I love the idea of Cordova heading this same direction. > > > > > > > > > > > > > That's great to hear. > > > > > > > > > > > > > > Windows apps have a URI whitelist focused on top level > > > > > navigation and JavaScript includes on pages not XHR. The main > > > > > reason to lock down at this level is to reduce the risk of a > > > > > malicious user navigating the page to a URI outside of the app > > > > > author's control and take advantage of sensitive APIs. So, I > > > > > think some level of whitelist to help out in this situation is > > > > > advisable even with CSP being used. We’ve mapped <access> > > > > > elements in config.xml to the top level nav whitelist for this > > > > > reason. CSP isn’t really designed to help > > > with this kind of problem. > > > > > > > > > > > > > Agreed. CSP on the web can't really control navigation, or else > > > > web page authors would be able to trap browser windows on their > sites. > > > > It makes sense for installed apps, but not so much for sites or > > > > web > > apps. > > > > > > > > > > > > > > > > > > Perhaps a default CSP policy in the template coupled with a top > > > > > level nav whitelist is the right starting point. > > > > > > > > > > > > That sounds like what I'm trying to implement on Android and iOS. > > > > Let me know what I can do to make that easy for Windows. > > > > > > > > > > > > > Determining what the CSP policy looks like will be really > > > > > important – by default CSP blocks both inline and eval use. Of > > > > > the two, inline use tends to be the bigger risk factor. > > > > > > > > > > > > > True -- eval without inline can theoretically be controlled, > > > > although it's not great practice. inline, with or without eval is > > > > an XSS waiting to happen, in a web app. > > > > > > > > > > > > > > > > > > -Chuck > > > > > > > > > > -----Original Message----- > > > > > From: Ian Clelland [mailto:[email protected]] > > > > > Sent: Friday, December 12, 2014 9:34 AM > > > > > To: [email protected] > > > > > Subject: Re: How to handle CSP for XHR in Cordova 4.0 > > > > > > > > > > Default CSP is a good idea. I was worried about leaving new apps > > > > > vulnerable by default but that should close that. > > > > > > > > > > Do we know what the CSP story is on all platforms, to know that > > > > > it won't break anything else? > > > > > On 12 Dec 2014 11:56, "Michal Mocny" <[email protected]> wrote: > > > > > > > > > > > I'm fine with 1. coupled with a default CSP in the template > > > > application. > > > > > > > > > > > > For older apps not written from scratch, we can perhaps > > > > > > strongly suggest installing the legacy-whitelist, which would > > > > > > change the default-open behaviour to default-closed. > > > > > > > > > > > > Together, that would give sensible defaults that aren't > > > > > open-to-everything? > > > > > > > > > > > > -Michal > > > > > > > > > > > > On Fri, Dec 12, 2014 at 9:13 AM, Ian Clelland > > > > > > <[email protected]> > > > > > > wrote: > > > > > > > > > > > > > I'm just building the new optional whitelist plugins for > > > > > > > Cordova Android and iOS 4.x, and I'm thinking about how to > > > > > > > encourage developers to use > > > > > > CSP > > > > > > > for network requests, as opposed to a > > > > > > > > Cordova-implemented-whitelist-which-probably-leaks-like-a-sieve. > > > > > > > > > > > > > > (Note: This is really just about things like XHR requests, > > > > > > > <img> and <script> tags, etc, which are historically the > > > > > > > only things that we've reliably been able to filter out. > > > > > > > Other classes of network requests just bypass all of our > > > > > > > code anyway, which sucks, and frame navigation and external > > > > > > > application launches are already well handled > > > > > by the framework). > > > > > > > > > > > > > > The policy I've implemented on the unplug-whitelist > > > > > > > branches, which at first thought at least *sounds* sane, is > > > > > > > that network requests are > > > > > > blocked > > > > > > > by default. (At least all of the ones that we can intercept). > > > > > > > That way, a plugin, such as the legacy-whitelist plugin, can > > > > > > > open up access to > > > > > > specific > > > > > > > resources, and the fallback is safety. > > > > > > > > > > > > > > To use CSP, though, we have to open up access to the > > > > > > > outside, and we > > > > > > don't > > > > > > > necessarily know what the developer wants to open (the whole > > > > > > > point is > > > > > > that > > > > > > > they specify in the HTML, not in a config file.) The easiest > > > > > > > way is to > > > > > > open > > > > > > > up access to *all* resources to the webview, and then > > > > > > > restrict it through the CSP header/meta-tag, which does a > > > > > > > better job of blocking those > > > > > > requests > > > > > > > than we do in any case. > > > > > > > > > > > > > > I think that we want to encourage developers to use CSP, for > > > > > > > a lot of reasons, but I'm going to have to do one of these > > > > > > > things, and I'm not entirely sure which is the right one: > > > > > > > > > > > > > > 1. Open access to all network resources by default in > > > > > > > Cordova > > 4.x. > > > > > > > * This doesn't apply to navigations, or launching other apps. > > > > > > > They're still blocked by default. > > > > > > > * Any plugin implementing shouldAllowRequest would still > > > > > > > be able to > > > > > > turn > > > > > > > this into a disallow-by-default whitelist > > > > > > > * We can't block everything anyway (see websockets, > > > > > > > audio/video > > > > > > streams / > > > > > > > probably more), so it removes the illusion that we can. > > > > > > > > > > > > > > 2. Make another whitelist-y plugin, something like > > > > > > "org.apache.cordova.csp" > > > > > > > that exists only to open up access to network resources. > > > > > > > Direct all users who want to use CSP to install that plugin > first > > > > > > > * It's a 4th network plugin (after legacy-whitelist, > > > > > > navigation-whitelist > > > > > > > and intent-whitelist) > > > > > > > * Adding it doesn't actually add any CSP protection, so it > > > > > > > probably > > > > > > needs > > > > > > > a better name > > > > > > > * It's an extra step that may confuse people and limit > > > > > > > adoption > > > > > > > > > > > > > > 3. Do something crazy. Maybe a CSP plugin that automatically > > > > > > > creates CSP tags *and* updates the XHR whitelist, both from > > > > > > > config > > > > directives. > > > > > > > * Lots more work > > > > > > > * We probably don't know enough about real requirements to > > > > > > > get this > > > > > > right > > > > > > > * If CSP is doing its job, then the XHR whitelist isn't > > > > > > > needed anyway; > > > > > > it > > > > > > > would just be another layer that isn't doing anything > different. > > > > > > > > > > > > > > I'm leaning towards #1, but its a it's a decision that we > > > > > > > really should think about and decide on-list before moving > > forward. > > > > > > > > > > > > > > Ian > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > -- > > > > > -- > > > > > - To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
