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

On Tue, Oct 1, 2013 at 6:38 PM, Daniel Veditz <dveditz@mozilla.com> wrote:

> On 10/1/2013 4:22 PM, Glenn Adams wrote:
>
>> (2) the actual user of the UA may not know that some add-on is malicious
>> or has been compromised;
>>
>
> This is an unfortunate and too common situation and leads to lots of
> problems that don't involve injecting content into web pages. It doesn't
> really matter what we say in the CSP spec in this case, malware is going to
> do what it's going to do.
>

Sure, but isn't it reasonable to provide some incremental protection if
possible. An uncompromised UA is conceivably able to control what script
gets injected or executed, yes?


>
>  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.
>>
>
> "should not" is a strong recommendation, not a requirement. Firefox
> currently interferes and yet I believe it is still in compliance with this
> section of the spec.


Sure. As written, one couldn't claim a UA that ignores it isn't conformant.
However, I fear it sets a poor precedent and leads to expectations that are
possibly problematic. An add-on author that reads this may complain to a UA
vendor that ignores it, saying "you didn't do what the spec said you should
do". That's often sufficient to warrant implementing it.


>
>
>  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.
>>
>
> The primary intent of CSP is to prevent Cross-Site Scripting attacks,
> where an attacker on one web site can exploit flaws in a victim web site to
> inject content. This is extremely valuable whatever we decide to do about
> user scripts.


Let's say that the vector for compromising an add-on is via XSS, or say
that the add-on sources HTML content (via injected script) that hasn't been
subject to output validation. That seems to me to be no different from the
main intent of what CSP is attempting to mitigate.


>
>
>  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.
>>
>
> W3C content specs try not to specify particular user-interface interaction
> models but leave that design up to the user-agent. We could add an
> implementation note recommending some kind of interaction but it would be a
> non-normative part of the spec. Browsers have been trying to avoid these
> kinds of user interactions, though, so it'd be hard to get such a plan by
> my UX designers.
>

Sure, and I would argue as much. However, it isn't uncommon for a W3C spec
to provide provisions for user overrides. For example, TTML1 2nd Ed. [1]
specifies such a case with normative language:

"If a TTML processor is unable to dereference a non-standard *Profile
Definition Document*, then it must not further process the document without
the presence of an explicit override from an end-user or some
implementation specific parameter traceable to an end-user or to a user or
system configuration setting."

It shouldn't be hard to craft similar language for use with CSP that avoids
the issue of how a UA might support such an override.


> -Dan Veditz
>
>