This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23357 - Subverting CSP policies for browser add-ons (extensions).
Summary: Subverting CSP policies for browser add-ons (extensions).
Status: RESOLVED WONTFIX
Alias: None
Product: WebAppsSec
Classification: Unclassified
Component: CSP2 (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Deadline: 2018-01-14
Assignee: Brad Hill
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-25 21:58 UTC by Glenn Adams
Modified: 2018-01-17 07:42 UTC (History)
9 users (show)

See Also:


Attachments

Description Glenn Adams 2013-09-25 21:58:31 UTC
Section 3.3 of CSP 1.1 WD [1] permits the subversion of CSP policies by browser add-ons (extensions), aka "user-supplied scripts" with the following language:

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

In the case that a browser add-on (extension) has been compromised, e.g., by a privilege escalation vulnerability [2] or a script-injection vulnerability [3], the intended mitigating effects of CSP may be subverted or entirely eliminated.

In order to provide Web Applications with protection against such vulnerabilities, one of the following solutions are suggested:

(1) Reverse the sense of the above cited specification text, i.e., explicitly require CSP policy to apply to user-supplied scripts such as third party add-ons, etc.

(2) Introduce a "user-script" declaration for use with the script-src directive, which, if absent, prevents execution of user-supplied scripts but without generating a report violation; [web app opts-in to enable user script]

(3) Introduce a "no-user-script" declaration for use with the script-src directive, which, if present, prevents execution of user-supplied scripts but without generating a report violation; [web app opts-out to disable user script]

[1] https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#processing-model
[2] http://www.eecg.toronto.edu/~ashvin/publications/securing-web-browsers.pdf
[3] http://qspace.library.queensu.ca/bitstream/1974/7560/1/Barua_Anton_201209_MSc.pdf
Comment 1 Brad Hill 2013-09-25 22:22:29 UTC
Glenn,

  This is a deliberate design decision.  Protecting against attacks originating from outside of the context of the resource the policy is attached to (e.g. from weaknesses in browsers or extensions) is explicitly out of scope for Content Security Policy.

  The WebAppSec WG is also chartered to respect the HTML design principles, specifically the "Priority of Constituencies" (http://www.w3.org/TR/html-design-principles/#priority-of-constituencies) which places the rights and concerns of users ahead of content authors.  Basically, the user agent is really the user's agent.  The content author does not have the right to tell the user how their browser should behave or what extensions and user-supplied scripts are or are not valid as part of user agent behavior.  CSP only allows content authors to suggest additional guidelines for the management of the content a policy is attached to.

At any rate, the threat model implied by a "no-user-script" directive is untenable. If a user wants to modify their user agent, including ignoring such a directive, there's really nothing that CSP can do to stop them.

Sincerely,

Brad Hill
Comment 2 Glenn Adams 2013-09-25 22:41:03 UTC
Because this "design decision" abrogates the effectivity of CSP, and, in fact, exposes web application content and behavior as well as private user state to potentially unauthorized access and modification by potentially compromised add-on, a design that assigns higher priority to a compromised add-on is fundamentally broken.

Regarding your claim that "the content author does not have the right to tell the user how their browser should behave", you know very well this is not true, for at least two reasons: CSP and CORS, both of which allow the content author to specify policy rules that must be adhered to by a UA designed to respect these specifications. What is content authoring if is not telling the UA how to behave (what to paint on the screen, how to interact with user)?
Comment 3 Brad Hill 2013-09-25 23:49:39 UTC
This is a consensus design decision of the WG, not a bug, and is out of scope for 1.0. 

CSP allows a resource to request limited privileges for itself, not for the browser.  The browser and its extensions are, just like the operating system, part of the trusted computing base for CSP.  CSP is enforced by the browser, so it cannot defend against attacks coming from the browser.  It can only attempt to influence the behavior of the resource it is delivered with, as a defense-in-depth, on the assumption of a trustworthy user agent enforcing the policy.

If you want to propose new features or changes to the scope of CSP version 1.1, which has not yet completed a Working Group Last Call, the work mode of the WebAppSec WG is to raise it on the discussion list at public-webappsec@w3.org and we can manage it as an issue in our tracker.
Comment 4 Glenn Adams 2013-09-26 22:47:42 UTC
(In reply to Brad Hill from comment #3)
> This is a consensus design decision of the WG, not a bug, and is out of
> scope for 1.0.

Firstly, I am not reporting this against 1.0, but 1.1 which is in WD. It is in scope since the scope includes mitigation against script injection vulnerabilities, and since add-ons are vulnerable to compromise.

> 
> CSP allows a resource to request limited privileges for itself, not for the
> browser.

CSP allows a resource to specify the policy of which scripts are allowed to operate when viewing that resource. User-defined scripts, which, through add-on and extensions, inject code into a resource contribute to the attack area of the resource, and a compromised add-on may subvert the operation of the resource, may access and acquire private user data by accessing DOM state.

When a resource specifies a white list of accessible scripts, it should not be subjected to potential injection attacks on the part of compromised add ons. Such add-ons should not be considered to be equivalent to the UA itself in terms of trustworthiness, at least in part because any liability accepted by the UA vendor is unlikely to extend to the behavior of the add-on.

The browser and its extensions are, just like the operating
> system, part of the trusted computing base for CSP.  CSP is enforced by the
> browser, so it cannot defend against attacks coming from the browser.

This statement is false with respect to add-ons, extensions, since the UA can enforce resource specified directives that limit the ability of a compromised add-on or extension to inject script into the resource.

It
> can only attempt to influence the behavior of the resource it is delivered
> with, as a defense-in-depth, on the assumption of a trustworthy user agent
> enforcing the policy.

The UA vendor is not the manufacturer or supplier of third party add ons that are permitted to inject script into a resource. The notion of trusting a UA vendor does not necessarily extend to trusting UA add-ons and extensions provided by third parties.

> 
> If you want to propose new features or changes to the scope of CSP version
> 1.1, which has not yet completed a Working Group Last Call, the work mode of
> the WebAppSec WG is to raise it on the discussion list at
> public-webappsec@w3.org and we can manage it as an issue in our tracker.

Firstly, I am reporting a serious security flaw in CSP, namely the existence of a backdoor for the injection of script by compromised add-ons/extensions. Secondly, I am suggesting three possible ways to address this bug.

Please do not close this bug again unless it is adequately addressed. Further, please record a Formal Extension against publishing CSP 1.1 as a CR unless this bug is substantively addressed. If not adequately resolved, you must document this FO in the SOTD section of the CR (or next LC).
Comment 5 Glenn Adams 2013-09-26 23:06:54 UTC
Changing component to reflect this is a report against CSP1.1.
Comment 6 Glenn Adams 2013-09-27 01:14:50 UTC
(In reply to Glenn Adams from comment #4)
> CSP allows a resource to specify the policy of which scripts are allowed to
> operate when viewing that resource. User-defined scripts, which, through

s/User-defined/User-supplied/

> Please do not close this bug again unless it is adequately addressed.
> Further, please record a Formal Extension against publishing CSP 1.1 as a CR

s/Extension/Objection/
Comment 7 Mike West 2013-09-27 08:49:45 UTC
Glenn, 

Thanks for the feedback!

First, a narrow point: Given that extensions (in Chrome, and I assume in Firefox as well) have the  ability to remove the CSP header entirely by modifying the HTTP request in-flight, I'm not sure user agents would technically be able to do to achieve the goals you're interested in achieving.

Beyond that, Brad correctly notes that user agents explicitly give extensions the ability to violate the wishes of site authors in a variety of ways. That's pretty much their raison d'etre. While I completely agree with you that publishers and authors would prefer to have complete control over the ability of users to inject script into their pages, I disagree that user agents should be required to give them that option. Adam explores this question eloquently in http://www.schemehostport.com/2011/10/priority-of-constituencies.html. I think that fairly clearly outlines the foundations of this decision.

Thanks!

-mike
Comment 8 Glenn Adams 2013-09-27 15:41:28 UTC
(In reply to Mike West from comment #7)
> First, a narrow point: Given that extensions (in Chrome, and I assume in
> Firefox as well) have the  ability to remove the CSP header entirely by
> modifying the HTTP request in-flight, I'm not sure user agents would
> technically be able to do to achieve the goals you're interested in
> achieving.

Since the UA sees those headers before the add-on does, and since the UA is responsible for granting access to add-ons to inject script, execute script, etc.,  it is straightforward for the UA to prevent the latter if those headers would otherwise prevent add-on script execution.

> Beyond that, Brad correctly notes that user agents explicitly give
> extensions the ability to violate the wishes of site authors in a variety of
> ways.

That's the fundamental problem. In the case that an add-on is not acting maliciously with respect to either the user's own wishes or the content author's wishes, then that is a reasonable strategy. However, in the case of a compromised add-on, there is likely to be malicious behavior with respect to the user's wishes.

For example, say I'm a commercial television service provider using the Open Web Platform to deliver television content to the user. At some point, I may need to send an Emergency Alert Message (EAM) to the user to warn her of a tornado heading towards her house. A function which the Government imposes on me to satisfy, and, even potentially to suffer liability consequences if I fail to do my best effort to deliver and display (or provide audio override).

Now say that the user has installed a third party add-on that either accidentally or intentionally (through design or through compromise) blocks or otherwise prevents my "TV Web Application" from delivering that EAM to the user, and, consequently their house is destroyed, potentially with loss of life.

Perhaps I am now sued for liability for such losses due to the fact that I failed to deliver or otherwise alert the user. Did I do everything I could under the circumstances to attempt delivery? Barring the behavior of the add-on, I can probably effectively argue that yes I did. However, if I could have told the UA to disable add-ons while the user is watching TV via this web application, then I might have prevented the add-on from blocking the EAM. A reasonable jury might find that I am liable for losses.

I believe CSP can help here and that UAs can implement policies that will do a better job of protecting the user. A similar scenario of protecting the user could be constructed regarding the potential for a compromised add-on to steal private user information, such as credit card information and so on. If I were authoring a banking application or an online store interface, I might also want to prevent arbitrary injection of scripts by add-ons into my sensitive application that is trying to provide valuable services and maintain user privacy.


> That's pretty much their raison d'etre. While I completely agree with
> you that publishers and authors would prefer to have complete control over
> the ability of users to inject script into their pages, I disagree that user
> agents should be required to give them that option. Adam explores this
> question eloquently in
> http://www.schemehostport.com/2011/10/priority-of-constituencies.html. I
> think that fairly clearly outlines the foundations of this decision.

Adam's post does not address the case in point in at least two ways:

(1) it does not recognize that, at least in the cases I've outlined above, the content author is attempting to protect the user, and that the ability of a compromised add-on to subvert this intention (with potentially financial, injury, or loss of life consequences) inverts the hierarchy of constituencies;

(2) in the current CSP specs, the UA is not given the option of providing a user interface to query the user in the case that a CSP enabled site wishes to disable add-on script injection; in this case, a UA could do what is now done with password managers, i.e., ask the user what they want to do; the same could be applied here, the UA could, for example, ask the user whether the request to disable the add-ons be accepted (temporarily or permanently) or ignored (temporarily or permanently);

The current CSP text doesn't explore this more flexible approach that permits the content author to at least attempt to protect the integrity of the application which may include protecting the integrity of the user *and* at the same time permit the user to have a say about what behavior should apply.

My conclusion is that CSP has not adequately addressed this area, and that more can and should be done to address it.
Comment 9 Glenn Adams 2014-01-29 16:53:45 UTC
Resolved satisfactorily in https://github.com/w3c/webappsec/commit/cbfaa8edfadebf21a9c7428242c12e45934d8c55
Comment 10 Glenn Adams 2014-01-29 16:54:36 UTC
Thanks!
Comment 11 Doug Schepers 2014-02-22 19:14:56 UTC
(In reply to Glenn Adams from comment #8)
> (In reply to Mike West from comment #7)
> > Beyond that, Brad correctly notes that user agents explicitly give
> > extensions the ability to violate the wishes of site authors in a variety of
> > ways.
> 
> That's the fundamental problem. In the case that an add-on is not acting
> maliciously with respect to either the user's own wishes or the content
> author's wishes, then that is a reasonable strategy. However, in the case of
> a compromised add-on, there is likely to be malicious behavior with respect
> to the user's wishes.
> 
> For example, say I'm a commercial television service provider using the Open
> Web Platform to deliver television content to the user. At some point, I may
> need to send an Emergency Alert Message (EAM) to the user to warn her of a
> tornado heading towards her house. A function which the Government imposes
> on me to satisfy, and, even potentially to suffer liability consequences if
> I fail to do my best effort to deliver and display (or provide audio
> override).
> 
> Now say that the user has installed a third party add-on that either
> accidentally or intentionally (through design or through compromise) blocks
> or otherwise prevents my "TV Web Application" from delivering that EAM to
> the user, and, consequently their house is destroyed, potentially with loss
> of life.
> 
> Perhaps I am now sued for liability for such losses due to the fact that I
> failed to deliver or otherwise alert the user. Did I do everything I could
> under the circumstances to attempt delivery? Barring the behavior of the
> add-on, I can probably effectively argue that yes I did. However, if I could
> have told the UA to disable add-ons while the user is watching TV via this
> web application, then I might have prevented the add-on from blocking the
> EAM. A reasonable jury might find that I am liable for losses.

While I acknowledge the use case, this argument has a flaw: you are presupposing the capability of disabling add-ons as a option that you could have taken, which is not part of CSP 1.0. In terms of your scenario (though we are not lawyers), a reasonable jury could not rule that you were at blame, because in CSP 1.0, you had no control over what an add-on did; as far as you were concerned, the add-on was acting on behalf of the user who installed the add-on. However, the author of the add-on might be liable.


> I believe CSP can help here and that UAs can implement policies that will do
> a better job of protecting the user. A similar scenario of protecting the
> user could be constructed regarding the potential for a compromised add-on
> to steal private user information, such as credit card information and so
> on. If I were authoring a banking application or an online store interface,
> I might also want to prevent arbitrary injection of scripts by add-ons into
> my sensitive application that is trying to provide valuable services and
> maintain user privacy.

But this also violates the user's wishes. Maybe the user is trying to retrieve their own data for their own purposes, through use of an extension, because the banking application does not provide a way to do this otherwise. Or maybe the extension is some sort of web payment system, that generates a secure nonce instead of a credit-card number, for payment to the online store.

The author/publisher should not be able to exert such control over the user's experience.


> (2) in the current CSP specs, the UA is not given the option of providing a
> user interface to query the user in the case that a CSP enabled site wishes
> to disable add-on script injection; in this case, a UA could do what is now
> done with password managers, i.e., ask the user what they want to do; the
> same could be applied here, the UA could, for example, ask the user whether
> the request to disable the add-ons be accepted (temporarily or permanently)
> or ignored (temporarily or permanently);
> 
> The current CSP text doesn't explore this more flexible approach that
> permits the content author to at least attempt to protect the integrity of
> the application which may include protecting the integrity of the user *and*
> at the same time permit the user to have a say about what behavior should
> apply.

I think this would be an acceptable compromise: allowing the user to decide whether or not extensions can act on their behalf on a case-by-case basis.

I object to the removal of the extension exemption as a complete solution, and suggest that the WG work on a solution more like this user-opt-in.
Comment 12 Cyril 2015-08-28 15:30:57 UTC
This wording has the impact that none of the major browser support CSP with user supplied scripts & bookmarklets.
Since, as I initially thought, the user should have the last word over whatever browser enforced policy, I think the specification should be, at least more clear.

I think we all agree that the initial intend was that not to decrease the usability of the current web experience. However, as more and more website have CSP policies set up, users' bookmarklet do not run because of this (with no error whatsoever visible to the user, it's probably the worst case, but this is another subject), thus, this degrades the experience and goes against your job goals.

What browser vendors are doing now ?
They answer that one should just write an add-on / extension / whatever-marketing-term for the incompatible bookmarlet. In the end, you as a developer, has to write an (proprietary) extension for Chrome, a (proprietary) add on for Firefox, and so on.
This is *VERY* bad. 
Even worse, extension system does not exist on mobile browser, so there is no other mean to do the same thing on such system.

If you kept the initial wording, at least, we, users of bookmarklet, would have had some weight to force the browser vendor to "respect the standard". 

With a "MAY" clause, it's like if the clause was not existing and we have no weight anymore.

The reason why all browser vendors do not implement this clause is because it's very difficult to track each action of a script to figure out if it's *going to* violate the CSP (for example, a lot of bookmarklets load their real script from outside, but the script itself is harmless)

Now the situation is *deadlocked* IMHO because the vendors don't want this additional workload. The situation can be unlocked here easily, freeing the vendors and the users, by slightly modifying the standard.


Please either restore the initial wording (but this does not "solve" anything) or at least add the following solution:
1) Create a "Content-Security-Policy-Overide" policy, that is ignored by user agent when received from server, but allows to overide the initial policy.
2) The policy specified by this key overides the website specified CSP like if it was merged (that is, it does not remove anything but only adds to the CSP)

-- In parallel
1) Provided javascript bookmarklet and user-supplied script provide a:
"Content-Security-Policy-Override: <policy>";
line that does nothing in javascript.
2) Allow the item to be merged with the user-agent "CSPO" policy.


With this in place, we can have bookmarklet and user-supplied scripts that works, because:

1) When storing a bookmarklet into a bookmark catalog, the user-agent can detect the "CSPO" line and popup a security warning about the intention for this script (like it does for any other extension, "This extension wants to: query google.com, post to facebook.com, etc...", that the user can allow or deny.
If the user deny it, the user-agent will not install the bookmarklet into the catalog.

2) When the user triggers a bookmarklet (this event is easily differentiable from any other action), the "CSPO" directive can be merged *before* running the script.

3) If the CSPO is merged, then the script will function as expected and no work is required from the vendors to monitor/track the action for this script.


This actually keep the safety as high as possible (current workaround is to disable *complete CSP* which, IMHO, is not good) as only the bookmarklet's specified CSPO is allowed, the user is aware of any supplier's evil intention when installing the bookmarklet. 

Please notice that any other script (fetched from remote sources) would not have the CSPO applied - this is because a click from the bookmark bar is an event that's not part of the page's internal script engine.

So the work for the vendors resumes in: 
1) Add some parsing code triggered when installing a bookmark/user script. This is already done in most user-agent because of "use strict"; directives. So I'd say, it's easy.
2) Add a security dialog when such directive is found. Most of them already have similar feature when asking for position/microphone/permission usage. This is not hard
3) Add a "merge CSPO with current CSP" in the bookmarkClicked event handler. This is not hard too.
4) That's it, when running the script, everything will work as expected, security will be as good as possible.

And this would solve all our problems.
Comment 13 Glenn Adams 2018-01-13 20:20:31 UTC
@redneckgirl2772@gmail.com please explain in a comment your recent changes
Comment 14 Glenn Adams 2018-01-17 06:58:44 UTC
Just notice this posting. Shall I say "I told you so!"?

https://arstechnica.com/information-technology/2018/01/500000-chrome-users-fall-prey-to-malicious-extensions-in-google-web-store/
Comment 15 Mike West 2018-01-17 07:42:37 UTC
Hey Glenn, thanks for the constructive feedback! As Brad noted in 2013, extensions are outside the threat model that CSP aims to address. I continue to agree with that assessment. Resolving this as WONTFIX accordingly.