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

On Thu, Oct 1, 2015 at 7:39 PM, Brian Smith <brian@briansmith.org> wrote:

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

(I'd appreciate thoughts, from you and others, on how we could speed things
up.)


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

This seems like a totally reasonable thing for templating systems to do!

I disagree that we shouldn't also have suspenders in the browser. Belts +
suspenders + MOAR SUSPENDERS seems like a winning combination.

Or maybe the browser is the belt. Either way, the security team at Google
has found CSP useful in terms of providing an extra layer of confidence
about the integrity of the systems they're responsible for. I think it's a
reasonable accessory for the UA to offer.


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

In this case, I'd agree with Dan's assessment: we have to write this code
anyway, and it deals with 100% of the enforcement that we need, so I don't
see a ton of value in adding a DOM-manipulation layer of enforcement as
well.

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

What is the value of that separation?

I understand that it could help template-engine developers add CSP-related
features into their engines. Is that the extent of the benefit?

-mike