W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2015

Re: CSP3 as a polylithic set of modules?

From: Daniel Veditz <dveditz@mozilla.com>
Date: Sun, 4 Oct 2015 09:43:24 -0700
Message-ID: <CADYDTCBFzdZ_Zy1m=WFoO28gzq+Pmf6H_BUcRS-ADTKqTFrtmg@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Cc: Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Brad Hill <hillbrad@gmail.com>, Mark Nottingham <mnot@mnot.net>, Travis Leithead <Travis.Leithead@microsoft.com>
On Tue, Sep 29, 2015 at 5:47 AM, Brian Smith <brian@briansmith.org> wrote:

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

Redirects make this impossible for the -src directives. We can't expose
redirects to the page without violating the same origin policy--and there
have been exploitable bugs that take advantage of​
​ the times we let some of them leak.

We should not just forget about redirects​
​. Anecdotally Gecko's internal ​implementation makes it easy for add-ons
to filter URLs loaded explicitly from a page but doesn't handle redirects.
Most add-ons that do load filtering--and all of the ones that do so for
security reasons--have made the extra effort to capture redirects as well.

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.
In practical terms that will spread enforcement all over the DOM engine
whereas fetch() localizes it​. Not to mention things like Workers that
never go through the DOM.

-Dan Veditz
Received on Sunday, 4 October 2015 16:43:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:52 UTC