Re: CSP3 as a polylithic set of modules?

Mike West <mkwst@google.com> wrote:

> We've had some success splitting out features like Upgrade recently.
> Perhaps we can go even further to break up our monolith into a set of
> miniliths that lean on each other in various ways?
>
> I have a half-baked idea to split CSP3 into a number of documents along
> the following lines:
>
> * "CSP: Core": defines the headers, their syntax, the general processing
> model, the binding of policies to Documents and Workers, and provide hooks
> for the general concept of "violation" and reporting that other documents
> could poke at (reporting might be worth breaking out into a separate
> document, actually).
>

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.


> As a test balloon for this last bit of the proposal, I've sketched out
> mnot's `cookie-scope` idea as a separate document at
> https://w3c.github.io/webappsec/specs/csp-cookies/. WDYT? On the one
> hand, it's pretty small. On the other, perhaps browser vendors could be
> encouraged to tick a number of tiny checkboxes faster than they might tick
> a big checkbox, even if the functionality is the same?
>

The main advantage I see in splitting out features into multiple documents
is that things that trigger the W3C process causing a document reverting
back to CR from PR (etc.) would negatively affect smaller pieces.

Since the goal seems to be to prioritize features that browsers should
implement right away, I think it is worth categorizing features this way:

1. Features that everybody implements (approximately CSP 1).

2. Aspects that affect compatibility with CSP-1-only implementations. For
example, if there are aspects of the CSP 2 syntax that cause CSP-1-only
implementations to fail to parse the policy, because the policy conforms to
CSP 2 syntax but not CSP 1 syntax, then these issues should be addressed in
some way.

3. Apsects of CSP that are really important for a browser to implement,
because they cannot be enforced by input-side validation of CSP policy
conformance (on the server or in JS code implementing a templating engine).
For example, "frame-ancestor" is very important for browsers to implement
because it can't be enforced input-side, but new source-list stuff is less
important because the templating engine can and should have already have
prevented all that badness in the first place before the browser sees it.

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.

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


> P.P.S. I'm also starting to think that Brian was right about CSP being
> better if we lock it down it to purely restrictive directives, and move
> things like `referrer` out to their own whatever.
>

Brilliant!


> Don't tell him I said so, though.
>

Will do. He'd never let you forget it. :)

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