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

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

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.

I mean that a mechanism that simply allows any resource to assert that the
browser disable user add-ons violates the PoC.

You've given one specific example (Emergency Alerts) where this is not the
case, and I've proposed that actually satisfying this use case in the most
secure and efficient manner would be best accomplished by a purpose-built
mechanism, rather than the general mechanism of CSP.



>  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.
>

I don't think there's any other reasonable starting point but that the use
chose to install an extension.  The examples you give, like using a
borrowed computer, represent a very small percentage of any user's
experience.   As far as malware or compromise, we have CSP implementers on
very large sites who have reported their experience to this group.  They
have noted reports generated by bookmarklets and extensions, but have never
reported this kind of problem.  I don't deny that the possibility exists,
but:

1) The PoC says the user is in control of the behavior of their user agent.
 A baseline assumption that a resource's execution context / TCB is hostile
(as you seem to suggest) it is not a workable assumption from which to
begin constructing a security architecture.  CSP does not attempt to defend
against this threat.  CSP assumes that the execution context is an ally
that can be enlisted to provide defense in depth against weaknesses that
may exist  _in the resource itself_.  This is where the "authority" to
enforce such constraints comes from - they only apply to the resource
itself, not to anything external to it

2) Even assuming that some non-trivial set of extensions are malicious or
vulnerable, neither the browser nor especially the remote resource has any
way to distinguish the user's legitimate intent from an exploit at the time
of sending or enforcing a CSP policy.

3) Even assuming a user does have a malicious or vulnerable extension, it
would be potentially problematic for ALL resources. Asking resources to
opt-in to a policy to protect against a threat that is not
resource-specific places responsibility in the wrong place, while causing
all kinds of collateral damage to non-malicious use of extensions.  The
threat of malicious add-ons is much better handled by reputational and
editorial systems in the browser to prevent the user from installing such
code in the first place: systems like Microsoft's SmartScreen or Google's
Bouncer are good examples of this.

You propose resolving (2) by prompting the user.  It has been a consensus
design principle of CSP since before this WG was incorporated, and
reaffirmed explicitly at our first meeting in Nov of 2011 and several times
since, that CSP should not generate prompts to the user.  We did not
specify this in normative spec text because, as Dan mentions, we are
generally trying to leave the user experience for browser vendors to
decide.  However, there are currently no prompts specified because we
agreed as a group that the average user is unable to understand and act
meaningfully on them.

If you want to propose that this consensus be reversed by adding normative
language requiring a prompt, I believe the burden falls to you to explain
why and how such prompts could be meaningful, relevant, accurate and
actionable by users.

Also remember that policies are set on a per-resource basis and there is
currently no state maintenance requirement for user agents related to CSP.
 A "don't ask again" flag in such a dialog represents a substantial design
and implementation change to CSP, even more so if it allowed any resource
to potentially set state for an entire origin.

And if it were per-resource, the user will see such prompts much more
often, and the browser will have to store that much more state.

And consider that users that have one extension usually have many.  What
would be the granularity of such a prompt and consent, and how effective
would it be in defending against your threat?

What information could a user rely on to determine whether or not to allow
an extension to operate against a given resource?  And why would any
possible indica of a malicious/compromised extension that might be shown to
the user be best suited to action in the context of a specific resource
opting-in to a CSP policy, rather than mediated directly by the user-agent
in a global context?

-Brad