Non-browser implementation of CSP (was Re: CSP3 as a polylithic set of modules?)

On Tue, Sep 29, 2015 at 9:00 PM, Mike West <mkwst@google.com> wrote:

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


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

I agree.


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

Yes, but I think both the belt and suspenders could reasonably be on the
production side. Templating systems shouldn't stop doing what they are
currently doing; instead they should *add* CSP support.



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

JS-based injection would be solved by using a JS templating library, which
would optionally also enforce a CSP on generated content before inserting
it into the DOM.

As far as redirects: It is a good point that you can't do production-side
enforcement of CSP's redirect semantics. But, also, in order to get to the
redirects, you have to get past the CSP policy in the first place.


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

You are right

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

One of the problems with CSP as enforced in browsers today is that, even
when the browser blocks an XSS from loading some content, the HTML of the
XSS is still in the DOM. I'd like to find some way of preventing the XSS
from ever making it into the DOM. And, I'd like to be able to separate out
the parts of CSP that can be done production-side from the parts that have
to be done by the browser (e.g. redirects).

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