Re: CSP3 as a polylithic set of modules?

On Tue, Sep 29, 2015 at 2:47 PM, Brian Smith <brian@briansmith.org> wrote:

> I think we agree on the conclusion, but maybe not on the way to specify
>> things. In particular, there are a few other specifications with reporting
>> requirements (HPKP, NEL <http://www.w3.org/TR/network-error-logging/>,
>> etc). I've talked with Ilya a bit about extracting the reporting concepts
>> from each of these documents into one place that deals with things like
>> batching and retrying, which are difficult-to-impossible to do with
>> JavaScript alone.
>>
>
> If batching and retrying or other aspects of reporting are
> difficult-to-impossible to do in the web platform, then the web platform
> sucks.
>

Batching violations in the context of a single page-load is trivial.
Retrying failed connections in that page load is equally straightforward.
The "difficult" bit would be doing so post-navigation, potentially batching
up requests from multiple pages. I don't think we have good primitives for
that.

I suppose Service Workers would be able to take care of same-origin things
reasonably well, though... hrm. Maybe I'm just wrong. :)

Basically, I'm frustrated that it took ~3 years to get CSP2 out the door.
>> There was basically nothing in that document that should have taken so
>> long, and I think we would have made more progress more quickly if we would
>> have split the things that practically everyone agreed upon out from the
>> things that were more contentious.
>>
>
> Wasn't this an explicit decision by the working group? I seem to remember
> CSP 1.1 being much less than CSP 2.0, but then CSP 1.1 was abandoned so as
> to not slow down the work on all the other stuff added in CSP 2.0.
>

I don't think we abandoned CSP 1.1, but renamed it:
https://lists.w3.org/Archives/Public/public-webappsec/2014Jun/0203.html.
The normative diff between http://www.w3.org/TR/2014/WD-CSP11-20140211/ and
http://www.w3.org/TR/2015/CR-CSP2-20150721/ is fairly insubstantial.

But regardless of the timing of anything, the time gap between CSP and CSP2
was huge, and I don't think the actual diff justifies that timeline. I'd
like to move a bit more quickly; everything we're doing feels slow.

Developers who aren't using the templating solutions that exist are not
> worth spending time on, except for encouraging them to adopt good
> templating solutions.
>

Belts and suspenders, right? I mean, we have pretty good templating
solutions at Google, but we still run into regular XSS on our sites.


> Developers that try to use templating solutions and make mistakes are
> worth helping, by improving the usability of their templating products. I
> think CSP is a key part of that: every templating library should have a
> mechanism for accepting a CSP policy as an input, which the templating
> system enforces itself (for things that can be done on the input side).
> There's way too much emphasis on browser enforcement of CSP. Most of CSP
> should be implemented by jQuery, React, PHP, etc., not by browsers.
>

That sounds like a pretty interesting model. I don't think it would deal
with redirects well, nor would it protect against JavaScript-based
injection, but you're correct to say that much of the remaining
resource-oriented CSP protection ought to be doable.

This isn't what I said. I think CSP is great. I think the process of
> sending a CSP policy full of source-lists to the browser so that the
> browser can enforce the CSP policy during fetch() processing is not the
> best model. CSP should be enforced well before the browser attempts a
> fetcth--before the XSS even enters the DOM. For example, I hope that in
> CSP3, the enforcement of CSP is browsers moved from fetch() processing to
> DOM construction/mutation. CSP is a good language for describing the rules
> to make that happen, regardless of what enforces the rules.
>

As above, that deals with a large chunk of the problem, but it doesn't deal
with redirects. I think we're going to require some Fetch integration
regardless for that piece, and since dealing with redirects is the same as
dealing with the initial request (hooray recursive algorithms), it's not
clear to me what we'd gain by defining a DOM-based ruleset.

Could you elaborate a bit on what you'd like to see the implementation do?


> Anyway, the main takeaway I had from your initial message is that we
> should break up the spec so as to guide implementers to implement more of
> it. I don't know if breaking up the spec is useful for accelerating
> incremental implementation of CSP 2.0,
>

Note that Anne and others have also expressed some hesitations on this
point. :)

It would be helpful if folks from browser vendors would weigh in regarding
whether or not this would be useful in terms of prioritization and clarity.

but I do agree that it is very important for browsers to implement at least
> frame-ancestors from CSP 2.0. I also think it is very important to
> implement something to disable document.cookie, because browsers can use
> such a cue to disable the parent<->child communication of cookies, which
> makes sandboxing much stronger. And, similarly your proposal for credential
> management, for similar reasons. And also the iframe sandbox improvements
> so that advertisements and widgets can be moved to iframes. And referrer
> control mechanisms. All of these things seem more important to me than the
> rest of CSP 2.0, because these are things that websites need browsers to
> help with even if they put in the effort to do proper, safe, templating,
> and these are things that websites cannot do with extensions to jQuery, et
> al., whereas most of CSP 2.0 can be done without the browser's help.
>

There's a lot of important stuff that I'd like to see implemented more
widely. I would love, love, love advice on how to get those things in front
of the people at various vendors who make decisions about what to focus on.

-mike