RE: [webappsec] Call for Consensus: CSP 1.1 to FPWD

First, I want to reiterate that my feedback here should not block FPWD-I support that publication.

>> Whether we address this use case is also largely independent of
whether we use a <meta> element or an attribute on <html>.

Choosing a <meta> tag approach could limit our ability to choose whether we address the policy mutation use case.  I think it would be harder to choose for the policy to be immutable if we go the meta tag approach. Otherwise, what happens when a script appears before the meta tag?  I see only two behaviors:


1)     The policy is mutable.  So the first script executes with a blank policy (e.g. no restrictions), then the meta tag imposes tighter restrictions thereafter.

2)     The policy is immutable. What happens? Does the meta tag just get ignored because a script has already executed?

From: Mike West [mailto:mkwst@google.com]
Sent: Thursday, November 29, 2012 10:33 AM
To: Adam Barth
Cc: Jacob Rossi; Eric Chen; Fred Andrews; Hill, Brad; public-webappsec@w3.org
Subject: Re: [webappsec] Call for Consensus: CSP 1.1 to FPWD

I'm very much in favor of moving the current document to WD; it will facilitate conversations exactly like this one. :)

With regard to the <meta> discussion, I'd agree with Adam that there are at least two questions:

* First, we're asking where we should allow an inline policy declaration. I'm fairly agnostic on this; I think there are reasonable arguments for a number of options.

* Second, we're asking whether a developer should be allowed to tighten a page's policy after some amount of loading has taken place. I think we should, and I'd actually prefer to address the use case by expanding the script interface to explicitly support it. Injecting <meta> elements feels like a hacky solution, and a script interface would allow us to lock down <meta> parsing to enhance security.

--
Mike West <mkwst@google.com<mailto:mkwst@google.com>>, Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

On Wed, Nov 28, 2012 at 6:04 AM, Adam Barth <w3c@adambarth.com<mailto:w3c@adambarth.com>> wrote:
On Tue, Nov 27, 2012 at 5:58 PM, Jacob Rossi <Jacob.Rossi@microsoft.com<mailto:Jacob.Rossi@microsoft.com>> wrote:
>>> The advantage of this solution lies in its usability. Site authors can
>>> allow "trusted" inline scripts to execute before turning on CSP, they also
>>> don't need to whitelist any external scripts added before the <meta>
>>> injection point.
>>>
>>> I'm not sure if there is another way to accomplish this so I would like
>>> to keep this discussion open before removing <meta> entirely from CSP.
>
> This type of design complicates the implementation considerably (enabling
> mutability of the restrictions on a document), which could increase the
> surface area for implementation bugs (leading to vulnerabilities in the
> design).  It also could lead to author mistakes (accidentally including a
> 3rd party script above the <meta> tag).
>
> In the past, Microsoft has gotten negative feedback from authors for <meta>
> tags that have restrictions or special behavior based on their ordering with
> respect to other tags in the document. The example that comes to mind was
> our X-UA-Compatible meta tag, which can be used to change the rendering
> engine in IE for compatible behavior with legacy versions of the browser.
> It must be placed before certain other types of elements in the head,
> otherwise it is ignored. This has led to author confusion and even
> compatibility issues where sites did not get the correct behavior because
> the tag was not placed in the correct order.
>
> My preference would be to recommend authors simply include all scripts as
> external and with exceptions for them in the CSP. This reduces the
> complexity and  ensures utmost clarity in the behavior (avoiding mistakes).
Whether we address this use case is also largely independent of
whether we use a <meta> element or an attribute on <html>.  For
example, if we use an attribute on <html>, we need to decide what
happens when the page modifies the attribute or adds the attribute to
an <html> element that did not previously have the attribute.

One approach is to look at the attribute only when the documentElement
is inserted into the document for the first time.  Another approach is
let a web page set its policy by adding the attribute to the
documentElement at any point in time.

Adam

Received on Thursday, 29 November 2012 20:17:59 UTC