Re: [webappsec] POLL: Getting CSP 1.1 to LCWD

On Tue, Oct 1, 2013 at 3:36 PM, Glenn Adams <glenn@skynav.com> wrote:

>
> On Tue, Oct 1, 2013 at 3:02 PM, Carson, Cory <Cory.Carson@boeing.com>wrote:
>
>> I respectfully maintain the position that item 6 is out of scope for CSP.
>> I recognize that your proposals bring legal, user safety, or PoC benefits
>> for some actors in some situations, and I maintain my position that the
>> discussion be framed in the context of a hypothetical new document added to
>> the working group's scope.
>>
>
> If CSP said nothing about add-ons, then it would be better than what is
> there now. What is *in* CSP now:
>
> "Enforcing a CSP policy *should not* interfere with the operation of
> user-supplied scripts such as third-party user-agent add-ons and JavaScript
> bookmarklets."
>
> Brings the subject of add-on behavior in scope by itself. Suggesting that
> a hypothetical new document take up these processing semantics in more
> depth seems a very strange suggestion.
>

Considering your suggestion (of a new document) a bit more, I could accept
that approach if the above language was struck from both CSP 1.0 and 1.1,
and this new hypothetical document took up the matter of normatively
defining behavior surrounding add-ons/extensions, including the possibility
of defining new directives used in this context.


>
>
>
>> Attack Surface Reduction is guarded by the clause "potentially dangerous
>> features which they do not intend to use". Because user agent add-ons
>> operate outside of the standard web platform, I argue that scope statement
>> does not include item 6.
>>
>
> My contention is that because add-ons inject script into web content and
> that this results in that script being executed, that this is inside the
> standard web platform. Indeed, the above cited language from CSP gives this
> credence.
>
>
>>
>> The statement you cite in CSP 1.1 does not explicitly exclude user agent
>> scripts. However, the intention was to ensure that CSP only restricted
>> content, not restricting the user agent itself - this is evident by the
>> statement included in CSP that the filed bug requests changed. Changing the
>> statement is not a bug fix, but a goal change for CSP.
>>
>
> Pardon me, but Section 3.3 Processing Model [1] says:
>
> "To enforce a CSP policy, the user agent *must* parse the policy<https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#parse-a-csp-policy> and
> enforce each of the directives contained in the policy, where the specific
> requirements for enforcing each directive are defined separately for each
> directive (See Directives<https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#sec-directives>,
> below)."
>
> If this isn't a restriction on the user agent, then I don't know what is.
> Any normative statement of what a user agent "must" do is a restriction on
> the user agent.
>
> [1]
> https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#processing-model
>
> As far as I'm concerned, allowing unrestricted injection of script by an
> add-on into a web page is a major security hole, or at least has the
> potential for being exploited. CSP deals with allowing authors to specify
> policy directives which a UA must respect (if it implements CSP
> compliantly) with respect to the source script executed in the course of
> processing a web page. If add-on injected script is given carte blanche to
> inject script, then that's a bug or CSP is broken by design.
>
> I hope that this will be resolved in a substantive manner, and not simply
> side-skirted as being out of scope, or contrary to explicit design goals.
>
>
>
>> I raise EME to the discussion not as directly related to item 6, but as a
>> reference point for the level of effort for the feature of content
>> restricting what the user agent does to the content, either actions done by
>> users or actions done by user's chosen extensions.
>
>
> First, CSP does restrict what the user agent does with content, since it
> restricts which content can be accessed and processed. EME is not related
> to this nor is it a reference point.
>
>
>> The mailing list archive provides evidence that this type of feature
>> generates significant discussion. In order to not block every other aspect
>> of CSP from moving forward, this feature should be an independent
>> deliverable (document).
>>
>
> First,  I am not attempting to block progress on CSP. My formal objection
> would come into effect only when transitioning to CR or PR and if the BUG I
> am reporting is not adequately addressed.
>
>
>>
>> ----
>>
>> From: Glenn Adams [mailto:glenn@skynav.com]
>> Sent: Tuesday, October 01, 2013 1:16 PM
>> To: Carson, Cory
>> Cc: Brad Hill; public-webappsec@w3.org
>> Subject: Re: [webappsec] POLL: Getting CSP 1.1 to LCWD
>>
>>
>> On Tue, Oct 1, 2013 at 1:01 PM, Carson, Cory <Cory.Carson@boeing.com>
>> wrote:
>> On item 6, Disagree. I argue that item 6 is out of scope for Content
>> Security Policy based on these points:
>>
>> 1. Item 6 is counter to the stated goal of CSP. Content Security Policy
>> is intended to allow the content to request that the user agent restrict
>> what the content may do. From the charter posted at
>> http://www.w3.org/2011/08/appsecwg-charter.html :
>>     “The goal of this specification is to reduce attack surface by
>> specifying overall rules for what content may or may not do, thus
>> preventing violation of security assumptions by attackers who are able to
>> partially manipulate that content.”
>> Item 6 would change Content Security Policy to allow the content to
>> restrict what the user agent may do to the content, which is a very
>> different thing.
>>
>> I respectfully disagree. The intent of the bug is precisely what is
>> stated in the WG charter and the explicit goals of CSP:
>>
>> From Charter
>>
>> "Attack Surface Reduction: The WG will design mechanisms to allow
>> applications to restrict or forbid potentially dangerous features which
>> they do not intend to use, thus limiting the attack surface."
>>
>> From CSP 1.1
>>
>> "This declaration allows the client to detect and block malicious scripts
>> injected into the application by an attacker."
>>
>> This bug report is predicated on the following:
>>
>> (1) that third-party add-ons/extensions that inject script into a web
>> page for which CSP policies have been declared can behave in a manner that
>> is detrimental to the interests of the user and the web page author;
>>
>> (2) that third-party add-ons/extensions have been and can be compromised,
>> and, as such, contribute to the potential attack surface in a manner
>> similar to XSS;
>>
>> (3) that, in general, user agent vendors do not accept legal liability
>> for the function of third-party add-ons/extensions;
>>
>> (4) that end users are not necessarily aware of what third-party
>> add-ons/extensions are operating in the context of a web page, or which
>> inject code into or modify the behavior of that web page;
>>
>> As a starting point, can we agree on these points or not? If so, then I
>> would suggest that the bug report is entirely consistent with the WG
>> Charter and CSP Scope, and that we should not make this a scope discussion.
>>
>>
>>
>> 2. Item 6 violates the Priorities of Constituencies, from the discussion
>> linked at https://www.w3.org/Bugs/Public/show_bug.cgi?id=23357. The
>> linked bug comments provide discussion about why item 6 violates PoC, and
>> why PoC is important.
>>
>> Again, I respectfully disagree. I believe that CSP is violating the PoC
>> and that this bug report seeks to remedy this situation. I discuss this in
>> comment #8 [1]. In particular, I note that the example of autocomplete=off
>> and whether a Password Manager is enabled or not in Adam's blog post [2] is
>> not a good analogy here because, in the present case with CSP, there is no
>> way for an author to specify the equivalent of "don't use the password
>> manager" *and* allow the UA to permit the user to override this request.
>> Instead, CSP not only doesn't provide a way for an author to declare its
>> preference, but it suggests a specific policy always be applied: always
>> enable script injection by third-party add-ons.
>>
>> A better approach, where the PoC interests are better balanced, is to
>> allow the author to declare a preference, and to allow the UA to override
>> this preference in the case that the end user explicitly wishes to accept
>> the risk.
>>
>> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23357#c8
>> [2] http://www.schemehostport.com/2011/10/priority-of-constituencies.html
>>
>>
>> 3. Similar to item 6, the topic of "user agents attacking the content"
>> arose earlier this year on the webappsec mailing list, and was not added to
>> CSP. See the thread starting at
>> http://lists.w3.org/Archives/Public/public-webappsec/2013Jan/0028.html.
>> It was not successfully argued that CSP should handle this. The thread
>> ended at
>> http://lists.w3.org/Archives/Public/public-webappsec/2013Jan/0043.html,
>> a suggestion to rely on the security of a vendor-specific hardware product
>> that is out of the reach of the user agent.
>>
>> I believe that a third-party UA add-on is different from the UA itself.
>> Further, I believe the EUA employed by UA vendors probably does not cover
>> add-on behavior.
>>
>> A web site, particularly one that wants to provide sensitive services,
>> e.g., financial services, emergency alert services, etc., should be able to
>> distinguish between its ability to trust the UA and its ability to trust
>> third-party add-ons/extensions.
>>
>> To my knowledge, there is little or no use of UA injected script, but
>> many third-party add-ons do use injected script.
>>
>>
>> 4. Item 6 is a quantity of work that is worthy of it's own document. The
>> only other analog of content restricting the user agent itself is Encrypted
>> Media Extensions, posted at http://www.w3.org/TR/encrypted-media/.
>> Looking at the mailing list archives at
>> http://lists.w3.org/Archives/Public/public-html-admin/, the topic's
>> discussion is time intensive. Attaching this topic to the existing CSP
>> document may significantly delay CSP 1.1 from moving forward due to
>> discussion alone.
>>
>> This bug report has no relation whatsoever to EME or content protection.
>> That is a false analogy. Rather, this bug report is about attack surface
>> reduction and protection of PoC.
>>
>>
>> However, disagreeing on item 6 alone should not end the discussion of the
>> topic. Reading this working group’s charter, I hypothesize that item 6 is
>> within the mission but not the scope. I propose that the working group
>> discuss the topic as the question(s): Is this topic indeed within the
>> charter’s mission? If so, should the charter’s scope be expanded to include
>> a new deliverable (document) for this topic?
>>
>>
>> Cory Carson
>> Application Security Team
>> Boeing
>>
>> -----
>>
>> From: Glenn Adams [mailto:glenn@skynav.com]
>> Sent: Monday, September 30, 2013 10:31 PM
>> To: Brad Hill
>> Cc: public-webappsec@w3.org
>> Subject: Re: [webappsec] POLL: Getting CSP 1.1 to LCWD
>>
>>
>> On Mon, Sep 30, 2013 at 5:23 PM, Brad Hill <hillbrad@gmail.com> wrote:
>> As discussed on our last conference call and in a previous email, we are
>> behind schedule on our deliverables and I would like to propose that we
>> close the feature set for CSP 1.1.
>>
>> This is a formal poll to establish consensus.  Workgroup members, please
>> take a few minutes to respond to these 6 questions to the list.
>>
>> 1: We should close the feature set of CSP 1.1?  Agree / Disagree
>>
>> 2. We should include the application of 'unsafe-eval' semantics to the
>> CSSOM in the core CSP 1.1 feature set? Agree / Disagree
>>
>> 3. We should include the suborigin sandboxing proposal in the core CSP
>> 1.1 feature set? Agree / Disagree
>>
>> 4. We should include the "Session Origin Security" policy in the core CSP
>> 1.1 feature set?  Agree / Disagree
>>
>> 5. We should include the "cookie-scope" policy in the core CSP 1.1
>> feature set?  Agree / Disagree
>>
>> Finally, we have a Formal Objection that has been registered by the Cox
>> Communication representative Glenn Adams to reverse the currently specified
>> behavior of allowing user-defined scripts (including from extensions).
>>  Glenn has declined to raise his suggestions on this list after several
>> invitations to do so, but he gave a high-level set of proposals attached to
>> this bug:
>>
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23357
>>
>> 6. We should make changes to core CSP 1.1 behavior (including possibly
>> specifying a new directive about user script) as requested by Bug 23357?
>>  Agree / Disagree
>>
>> It is premature to ask for a poll on a bug report that has not been
>> discussed by the WG. I would suggest that a discussion occur at the next
>> scheduled teleconference. I would be happy to discuss our concerns that led
>> to filing this bug report at that time.
>>
>>
>> Please reply to this list so your views can be "on the record".  This
>> poll closes at the start of our next regularly scheduled teleconference on
>> October 8th at 2pm  United States Pacific Time.
>>
>> Thank you,
>>
>> Brad Hill
>> co-chair, WebAppSec WG
>>
>>
>