W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2014

Re: Header Policy Vs. Meta tag policy

From: Mike West <mkwst@google.com>
Date: Thu, 12 Jun 2014 09:20:07 +0200
Message-ID: <CAKXHy=eL5vR18doROPXV58DAt6Mswi+TXbhOo6kNKwqdbC5nBg@mail.gmail.com>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
Cc: Daniel Veditz <dveditz@mozilla.com>, Kevin Hill <khill@microsoft.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, Jun 11, 2014 at 8:55 PM, Devdatta Akhawe <dev.akhawe@gmail.com>
wrote:

> I agree with you. I think we should definitely encourage the ability to
> lock down further via multiple policies.
>

Hooray!


> I glanced over the directive list and I wonder if whitelisting does
> suffice: how about we only allow all *-src and form-action in the meta
> element? It does seem conceptually clearer than the blacklisting approach,
> where we have to think about threats every time a new directive is added.
>

What about 'plugin-types'? What about 'referrer'? What about
'frame-ancestors'? I can see value in all three.

Basically, I think we have to think about the threats for all of the
directives anyway (and there are only 18 of them). It's clearly bad to
screw around with XSS protections (
https://github.com/w3c/webappsec/commit/814d990604ccc4968a259d261866a13802b41461).
It's clearly bad to turn on reporting. Sandboxing is fairly ineffective
once the page has loaded.

It seems like there are reasonable arguments for allowing the rest of the
directives. *shrug* We could certainly just whitelist (all of) those, and
then do the same exercise again when we add new directives in 1.2.

-mike
Received on Thursday, 12 June 2014 07:20:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:05 UTC