W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2012

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

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 27 Nov 2012 21:04:56 -0800
Message-ID: <CAJE5ia_P+wbPunxL5gKJDMTOv0WHG+POmBk1F6TTxWwVpNHZcg@mail.gmail.com>
To: Jacob Rossi <Jacob.Rossi@microsoft.com>
Cc: Eric Chen <eric.chen@sv.cmu.edu>, Fred Andrews <fredandw@live.com>, "Hill, Brad" <bhill@paypal-inc.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
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 Wednesday, 28 November 2012 05:05:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 28 November 2012 05:05:59 GMT