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>, 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> wrote:

> On Tue, Nov 27, 2012 at 5:58 PM, Jacob Rossi <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 18:33:32 UTC