Re: CSP3 as a polylithic set of modules?

On Tue, Sep 29, 2015 at 12:54 AM, Mike West <mkwst@google.com> wrote:

> On Mon, Sep 28, 2015 at 11:15 PM, Brian Smith <brian@briansmith.org>
> wrote:
>>
>> Reporting should be specified, normatively, in Javascript code that uses
>> the CSP2 DOM events and XHR to do what browser's reporting modules do. I
>> don't think reporting is really "core" to CSP, even though it is a very
>> useful feature. In particular, the reporting mechanism only makes sense for
>> browser implementations of CSP, but it doesn't really make sense for
>> server-side or client-side templating engines that take a CSP to guide them
>> in rejecting bad inputs (input-side validation instead of output-side
>> validation of CSP). So, I think reporting should be moved out of core.
>>
>
> 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.


> 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.


> 4. The defense-in-depth features that are redundant with good input-side
>> validation practices but which are critical if you have a bunch of terrible
>> code sitting on your servers with bugs that you want to use CSP to
>> wallpaper over.
>>
>
> This is most of CSP in your model, right?
>

It is a lot of CSP, at least.


>  Ultimately, I think it is unreasonable to expect web browsers to invest
> time to implement features that just wallpaper over server-side bugs, and I
> think a lot of CSP would actually be classified that way.
>
> I guess I disagree (folks aren't using the templating solutions that
> exist, and when they do, they do so poorly), but I also don't think that
> disagreement has much to do with the structure of the document we produce
> at the end of the day.
>

Right. My grouping in my previous message wasn't about document structure,
but about prioritization of features to add to web browsers.

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. 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.


>
>> I think CSP is brilliant but I think our emphasis on browser enforcement
>> of CSP policies is counterproductive in the long run. Most of CSP should
>> actually be enforced by the templating engines. I think the idea of sending
>> a CSP header with a bunch of source-list directives for the browser to
>> enforce will be considered an obsolete practice in a few years as
>> input-side enforcement of CSP gets implemented and deployed.
>>
>
> 1. I would love CSP to be obsolete in a few years.
>

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.

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, 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.

Cheers,
Brian
-- 
https://briansmith.org/