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

On Wed, Oct 2, 2013 at 6:10 PM, Brad Hill <hillbrad@gmail.com> wrote:

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

Once again, I assert that is not necessarily true. In fact, you don't know
that it violates the PoC. When the user was signed up for a Web service,
she might have been asked if it is acceptable to disable add-ons when
accessing the service.

So, in fact, the semantics currently documented may in fact violate the PoC
because it ignores the user's permission and the content authors intent in
favor of the UA.


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

Yes there is. You could ask the user at the time a disabling of add-on is
requested.


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

Yes it is. And I've shown how to do it.


>   CSP does not attempt to defend against this threat.
>

But it could, but it bails out on the weak notion that the intent of the
user at the time of add-on installation overrides all other intents of the
same user.


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

Not true. Indeed, if that weren't true, then what is the point of a white
list. It is an exclusions list. Enforced by the UA.


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

Correct, but the UA can ask the user.


>
> 3) Even assuming a user does have a malicious or vulnerable extension, it
> would be potentially problematic for ALL resources.
>

Nothing about what I've suggested hints that I am implying a malicious
intent on the part of the user.


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

I suggested a number of alternative approaches. One is opt-in. One is
opt-out. I also suggested inverting the current language to read SHOULD
interfere with add-on script injection. But there is a fourth option: don't
say anything, and leave it UA dependent. There is also a fifth option: ask
the user.


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

Defense in depth usually entails multiple levels of impediments. This one
is reasonable, but CSP can do more as well. Relying on only one or the
other is less effective than using both.


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

Apparently this position didn't take into account the effects of malicious
or compromised add-ons. In any case, when I say "ask the user", I don't
mean it necessary to ask/prompt the user every time. That password managers
due a reasonable job of managing this situation means that such a prompting
would not be anything new not already encountered by users.


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

If that were the case, then why recommend specific UA behavior "SHOULD NOT
interfere with add-ons". If the spec had been silent, we wouldn't be having
this conversation.


>  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 they are able to meaningfully act on password manager prompts, then they
can manage here as well.


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

I haven't suggested mandating a prompt. When I suggest "ask the user", I
didn't imply "ask every time". The user interface should be up to the UA
vendor to decide what is relevant and useful. From a specification
perspective, it could easily be specified as:

"unless the user denies permission, then enable add-on script injection"
(user opts-out)

or

"unless the user grants permission, then disable add-on add-on script
injection" (user opts-in)


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

I'm not suggesting that a permanent user choice be registered, only that it
is possible. That detail should be left to the UA vendor.


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

I'm only mentioning possibilities, not specifying a definite behavior.
Again, how the prompt, if there is one, is formulated, should be up to the
UA vendor IMO.


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

Not necessary for spec to decide. UA vendor decides.


>
> What information could a user rely on to determine whether or not to allow
> an extension to operate against a given resource?
>

Tea leaves? I don't know. What information does a user rely on when
allowing a certificate to be stored or a password manager to be allowed to
use a cached credential? Well, they probably use their memory -- Have I
accessed this resource before? Have I signed up for a service that uses the
URL associated with this resource? Did I agree to disable add-ons when
signing up for this service? etc. Lots of possibilities. The spec need not
say anything.


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

Firstly, the user has more relevant information than the UA in this regard.
Secondly, the UA is not a human. The user can always make a decision more
relevant to their current intents than the UA can in forcing a single
static policy. Again, the UA vendor decides how to present an opt-out,
opt-in, etc. question to the end user.

These are just possible suggestions for ways to deal with this. I'm sure
there are others I haven't considered. The bottom line is that there is a
host of ways to attempt to do a better job of determining how to resolve
the PoC conflict apparent in the case that a resource requests that add-on
script injection be disabled and a user has a potential interest in
overriding that request (and accepting some amount of risk themselves).


>
> -Brad
>
>
>
>