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

On Tue, Oct 1, 2013 at 4:50 PM, Brad Hill <hillbrad@gmail.com> wrote:

> I'm not trying to sweep anything under the carpet.  Part of my
> responsibility as a chair is to make sure that we stay within our chartered
> scope and keep the group focused on making progress towards its
> deliverables.
>
> You gave the example of Emergency Alert Messages as a special case where
> the Priority of Constituencies this group is chartered to respect is
> impacted by regulatory requirements designed to allow content providers to
> override a user's stated preferences for their own best interest.
>
> I respect this use case, but maintain that it is and must be a special
> case that deserves its own treatment in order to respect that Priority of
> Constituencies.  Wireless carriers e.g. deliver EMS alerts to phones, and
> even messages from the President that cannot be disabled, but those systems
> presumably have regulatory safeguards regarding the right to use these
> channels and to prevent their abuse.  They are not general purpose
> mechanisms.
>
> Presumably, the fictional restaurant Grizzlebee's can't just set the
> "message from the President" flag to advertise its new Flamin' Onion
> Bursts(tm)! in a way that customers can't block.
>
> And although Cox may have only the purest intentions and the best
> interests of its customers at heart, the reason people keep bringing up DRM
> when they read your proposal is we can well imagine "if CSP enabled
> authors to declare that addons should not inject script and the end user
> doesn't override that declaration" it would be immediately and widely
> abused to violate the Priority of Constituencies for reasons that have
> nothing to do with Emergency Messages.
>

I do not buy your claim that allowing a content author to request the
disabling of a potentially malicious or compromised add-on is a violation
of PoC w.r.t the user's intents. Your position seems predicated on the weak
claim that the user was responsible for installing the add-on in the first
place, and that allowing it to be disabled violates the user's wishes.

However, this position does not recognize that:

(1) the actual user of a UA may not have been the user that installed the
add-on; this is likely in the case of using a UA on a public computer
(e.g., internet cafe, using a friend's computer, etc);

(2) the actual user of the UA may not know that some add-on is malicious or
has been compromised;

(3) the actual user of a UA may have different intentions in different
contexts, for example, that some add-ons be enabled in some cases and
disabled in others;

The current CSP specification language brushes over these distinctions, and
recommends a behavior that poses the most risk. For example, the currently
language says CSP policy *should not* interfere with third-party add-ons.
Instead, the specification could have taken alternative approaches:

(1) it could have said nothing, leaving this as a problem for UA vendors to
address; [e.g., Mozilla appears to have taken a different approach;]

(2) it could have said that the UA should inquire with the user as to their
intentions *in the context of the current web page*;

Instead, the UA recommends a policy that potentially exposes greater risk
to the user and that in fact may violate the user's intentions.



> That's a predictable consequence of such a change that violates our
> charter and one that we cannot ignore.
>

I don't buy this general statement, and interpret it as avoiding dealing
with the underlying substance.


> As a general-purpose mechanism, your proposal violates the PoC, and the
> special use-case exception you highlighted is better served by a special
> case solution.
>

General purpose mechanism? I have no idea what you are talking about.

CSP is about supporting the ability of a content author to specify a white
list for processing script content (and other features). At the same time,
CSP is saying that a UA should ignore this white list when it comes to
third-party add-ons. If the function of authored content is subverted by
add-on script injection, then I fail to understand the value of CSP at all.

If CSP is to have reasonable value, then it must respect the white list
provided by the content author, and if that is deemed to potentially
conflict with user intentions w.r.t. an add-on, then the user should be
consulted to resolve the ambiguity over whose interests are allowed to
apply.


>
> Similarly, the scope of work involved in architecting browsers and
> extension mechanisms to clearly delineate a scope of liability and build
> litigation-proof security boundaries around how each component can affect
> CSP in particular and the DOM in general (what if my extension deletes the
> EMS in the DOM using devtools APIs instead of script injection, or strips
> them directly instead of stripping the CSP header?) is an enormous
> undertaking that involves issues outside of our charter and subject matter
> expertise.
>

We are talking about nominal CSP behavior here, not developer APIs. Your
point isn't relevant.


>
> Again, a special purpose mechanism to deliver regulatory-mandated alerts
> to browsers that cannot be interrupted is a a laudable goal, a much more
> achievable one, and one that belongs elsewhere than WebAppSec.
>

Huh? You have turned my simple example into a request for a special purpose
mechanism to support regulatory mandates? I'm astounded at your response.

Please focus on the fact that a author defined white list for scripts means
absolutely nothing as CSP is defined. That is a general problem with CSP.
That's why I filed a *BUG*.



>
> Sincerely,
>
> Brad Hill
>
>
> On Tue, Oct 1, 2013 at 2:45 PM, Glenn Adams <glenn@skynav.com> wrote:
>
>>
>> On Tue, Oct 1, 2013 at 3:32 PM, Brad Hill <hillbrad@gmail.com> wrote:
>>
>>> This group is not chartered to address regulatory requirements or issues
>>> of legal liability.  We are chartered for web application attack surface
>>> reduction. If Cox has a regulatory or legal requirement to deliver
>>> emergency alert services over the Web, I believe that CSP is not the place
>>> for this, and that the WebAppSec WG is not chartered for and doesn't have
>>> the necessary constituencies and participation to address these use cases.
>>>
>>
>> Are you suggesting that I should not give an example of how the BUG I am
>> reporting is not a problem? Are you suggesting that I am asking to address
>> regulatory or legal liability requirements?
>>
>> Please address the substance of my BUG report. Daniel has done so, can't
>> you?
>>
>>
>>>
>>> Replicating something like the Commercial Mobile Alert System for the
>>> Web sounds like a worthy goal, but it belongs in another forum that can
>>> focus on those specific requirements.
>>>
>>
>> Are you suggesting that discussing a concrete example of how CSP affects
>> real world usage isn't appropriate?
>>
>>
>>> The topic involves a different IP scope, and requires a different set of
>>> subject matter experts and member organizations (including representation
>>> from the relevant regulatory bodies) from what we have and are chartered
>>> for in this WG.
>>>
>>
>> No. This topic, describing an example of CSP specification affects on
>> real world usage, does not involve a different IP scope or a different
>> subject matter. It involves real problems about how CSP is deployed and its
>> effectivity. The response from Daniel clearly shows there are problems in
>> this area, and I'm suggesting that they not be swept under the carpet,
>> which you seem to be very desperately trying to do.
>>
>>
>>> Brad Hill
>>>
>>>
>>>
>>>
>>> On Tue, Oct 1, 2013 at 1:16 PM, Glenn Adams <glenn@skynav.com> wrote:
>>>
>>>>
>>>> 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
>>>>>
>>>>>
>>>>
>>>
>>
>