615708 - CSP blocks content injected by add-ons (including data: URLs)

Status: RESOLVED DUPLICATE of bug 1267027

(Core :: DOM: Security, defect, P3)

Description

[Wil Clouser [:clouserw]]

Attachment: example add-on

Many add-ons inject images/iframes/objects/scripts/etc. into the pages of websites (translate buttons, link modification, the list goes on and on).  If a site has CSP enabled (with a recommended strict set of rules) all of these wanted adjustments won't happen.  This will lead to a bad experience for end users and also gives the site owner more control over what can and can't be done on their site than they have traditionally had.

This affects external resources _and_ data URLs so there is no good way to work around it from an add-on developers perspective.  I expect this to be a point of frustration for add-on developers and add-on users if CSP gets widespread use.

I'm attaching an example add-on that injects some elements into a page on reload.  Thanks to jorgev for writing the add-on.

Comment 1

[Boris Zbarsky [:bzbarsky]]

The problem is that if you inject content like this it looks just like the web page's own content.  So we can't tell it apart from the web page itself.... and from just the kinds of attacks CSP is designed to protect against.

That said, what particular things does recommended CSP block that addons want to do?  Maybe there are better ways of doing them?

Comment 2

[Wil Clouser [:clouserw]]

The add-ons landscape is enormous, I imagine Jorge can come up with all kinds of examples.  The ones that I noticed when I filed this bug were:

- something trying to modify links (good or bad, I have no idea).  This could be something trying to alter amazon links for referral codes, change hostnames on links for testing purposes, change links to avoid non-ssl to prevent the firesheep stuff, etc.

- Something trying to inject the yahoo babelfish icon.  I assume it's an add-on that enables easy translation

- the AniWeather add-on trying to load images and such off amazonaws.  I guess it puts this stuff right on the page?

- Several other data: urls that I didn't bother decoding.

These were all in the span of an hour or so of access logs - a more extensive look will get you plenty more.

Comment 3

[Jorge Villalobos [:jorgev] (he/him)]

Some add-ons will just insert stuff in the content because adding floating chrome content on top of the web content has always been a pain. I think this has been somewhat fixed in Firefox 4, but I haven't verified this yet.

There are many add-ons that do insert content into the webpage with the purpose of enhancing it. I can definitely understand why you would block an image that points to a different domain, but I'm surprised that the same is done for data: URLs, which don't load external content. I wonder if the same happens with SVG. We normally request add-on authors to stick to local content when injecting anything into web pages, but it sounds like this will become increasingly hard because of CSP.

It looks like it's still possible to do with chrome:// URLs, so that's still a viable option.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> - something trying to modify links

Why is CSP a problem here?

> Something trying to inject the yahoo babelfish icon.

So the issue here is a data: URL, right?

> the AniWeather add-on trying to load images and such off amazonaws.

The problem here is a blocked cross-site load?

> but I'm surprised that the same is done for data: URLs

The point of CSP is to guard against content-injection attacks.  A data: URL is still content-injection, no?

If we had a way to flag data: URLs as being sourced from somewhere trusted, that might work.  But we don't...

Comment 6

[Wil Clouser [:clouserw]]

(In reply to comment #5)
> > - something trying to modify links
> 
> Why is CSP a problem here?

It was trying to load an external script to do it (which is, admittedly, against our guidelines).

> > Something trying to inject the yahoo babelfish icon.
> 
> So the issue here is a data: URL, right?

Yes

> > the AniWeather add-on trying to load images and such off amazonaws.
> 
> The problem here is a blocked cross-site load?

Yes

Comment 7

[Brandon Sterne (:bsterne)]

Currently, nsIContentSecurityPolicy only exposes a way to tighten a document's Content Security Policy.  This was a consequence of a design principle we followed that any policies received should only be able to make things stricter.   We were coming from the perspective of an attacker injecting an additional policy and we wanted to make sure that they couldn't lower the security profile by doing so.  An add-on is presumably trusted by the user and perhaps should have a way to add additional permitted hosts to the policy...

Sid, Dan, what do you guys think?

Comment 8

[Sid Stamm [:geekboy or :sstamm]]

I'd be okay with making an nsIContentSecurityPolicy update to loosen a policy as long as it can only be accomplished by heavyweight add-ons. 

The main issue I see with this is that popularity of an add-on is in contention with security of a site.  Say an add-on inserts a bunch of data: URIs, allowing data: in the CSP for a site.  If the majority of users of that site have the add-on installed, they're all now vulnerable to data: URI injection on the site.

I guess there are add-ons that completely rewrite sites anyway without their permission (readability, etc) so this would be very similar.

Comment 9

[Wil Clouser [:clouserw]]

This bug is generating so many uncachable http requests (POSTs) that it is in danger of overwhelming AMO and we've been forced to disable CSP on AMO.  I expect any site with a lot of traffic will run into the same problems and be unable to enable CSP protection.

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

What is the goal here? Is the goal to make sure that <img src="data:..."> etc inserted by add-ons into CSP pages to "just work"? I.e. with no actions taken by the add-on other than what they do on non-CSP pages?

Or is the goal that add-ons which take extra steps can make their page modifications work on CSP pages?

I think we need a detailed list of what add-ons are doing, and then develop plans for what we can do for each of the items in that list. The actions will probably be different for different items so this isn't a matter of simply applying some blanket change to the CSP code to make add-ons work again.

Comment 11

[Jorge Villalobos [:jorgev] (he/him)]

(In reply to Jonas Sicking (:sicking) from comment #10)
> What is the goal here? Is the goal to make sure that <img src="data:...">
> etc inserted by add-ons into CSP pages to "just work"? I.e. with no actions
> taken by the add-on other than what they do on non-CSP pages?

I think that's the goal, yes.

> Or is the goal that add-ons which take extra steps can make their page
> modifications work on CSP pages?

On comment #3 I mentioned that this is still possible to insert content using chrome:// URLs. The problem that the AMO people are having is that many add-ons insert content differently and this apparently causes a flood of requests sent to AMO.

> I think we need a detailed list of what add-ons are doing, and then develop
> plans for what we can do for each of the items in that list. The actions
> will probably be different for different items so this isn't a matter of
> simply applying some blanket change to the CSP code to make add-ons work
> again.

It's unpractical to come up with a comprehensive list, but here are a few things:
* Inserting content with data: URLs.
* Inserting content with regular URLs.
* Inserting content with chrome URLs.
* Inserting <script> and <style> elements.
* Rearrange or add or remove elements from the page.

If I understand this correctly, inserting content with regular URLs pointing to a different domain is forbidden by CSP, which means that AMO will continue to receive these requests to some extent, even if the other cases are addressed. If that's the case, then I think that this bug is not a sufficient solution to solve the problem being presented.

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

(In reply to Jorge Villalobos [:jorgev] from comment #11)
> (In reply to Jonas Sicking (:sicking) from comment #10)
> > What is the goal here? Is the goal to make sure that <img src="data:...">
> > etc inserted by add-ons into CSP pages to "just work"? I.e. with no actions
> > taken by the add-on other than what they do on non-CSP pages?
> 
> I think that's the goal, yes.

Ok, then I will treat this bug with that goal in mind.

> > I think we need a detailed list of what add-ons are doing, and then develop
> > plans for what we can do for each of the items in that list. The actions
> > will probably be different for different items so this isn't a matter of
> > simply applying some blanket change to the CSP code to make add-ons work
> > again.
> 
> It's unpractical to come up with a comprehensive list, but here are a few
> things:
> * Inserting content with data: URLs.
> * Inserting content with regular URLs.
> * Inserting content with chrome URLs.
> * Inserting <script> and <style> elements.
> * Rearrange or add or remove elements from the page.

Ok, so our goal is to make all of the above work with no changes to the addon?

You have separated "content" from "<script> and <style>". So I assume that by "content" you mean other things such as <img>? Anything more? <iframe>?

And even though you don't say so explicitly, I assume that <script> and <style> can be linked to data:/regular/chrome URLs?

Rearranging and removing elements should not be any problem. If it is, please file a separate bug.


> If I understand this correctly, inserting content with regular URLs pointing
> to a different domain is forbidden by CSP, which means that AMO will
> continue to receive these requests to some extent, even if the other cases
> are addressed. If that's the case, then I think that this bug is not a
> sufficient solution to solve the problem being presented.

So interestingly enough, there are more concerns being raised here about these error requests going back to AMO, than there are about addons not functioning as they should.

Maybe we should focus on supressing error reports if the origin of a blocked action comes from an addon.


There is going to be a lot of security problems allowing addons to do anything they have been able to do on CSP pages. We might over time be able to enable most things that have traditionally worked, but it will take time. I.e. it's not something we can do short-term.

Maybe a good short-term fix is to try to suppress the error reports, and the long-term fix is to make things "work" such that addons can make whatever changes they want to.

Comment 13

[Wil Clouser [:clouserw]]

> So interestingly enough, there are more concerns being raised here about
> these error requests going back to AMO, than there are about addons not
> functioning as they should.

I think that's bug 615711.  (Where I see I already said comment 9 a year ago.  Too many bugs in brain!)

Comment 14

[Jorge Villalobos [:jorgev] (he/him)]

(In reply to Jonas Sicking (:sicking) from comment #12)
> > * Inserting content with data: URLs.
> > * Inserting content with regular URLs.
> > * Inserting content with chrome URLs.
> > * Inserting <script> and <style> elements.
> > * Rearrange or add or remove elements from the page.
> 
> Ok, so our goal is to make all of the above work with no changes to the
> addon?

Ideally, yes. Though inserting scripts or images from other domains would break CSP, so it is reasonable not to allow this. In general we require AMO add-ons to insert all content locally, for security reasons (not breaking HTTPS and making it easier for us to review).

> You have separated "content" from "<script> and <style>". So I assume that
> by "content" you mean other things such as <img>? Anything more? <iframe>?

Yes, images, iframes, scripts and styles. Some might insert <object> or <embed> elements as well. 

> And even though you don't say so explicitly, I assume that <script> and
> <style> can be linked to data:/regular/chrome URLs?

Yes.

> So interestingly enough, there are more concerns being raised here about
> these error requests going back to AMO, than there are about addons not
> functioning as they should.

I doubt many add-on devs are running into sites with CSP enabled. If they do and they see their add-on not working, they'll try to work around it until it works. So, I'd say the AMO problem is the bigger one at the moment.

> Maybe a good short-term fix is to try to suppress the error reports, and the
> long-term fix is to make things "work" such that addons can make whatever
> changes they want to.

That sounds good to me.

Comment 15

[Rob Mueller]

Just to add a data point, we've just tried enabling CSP on our site www.fastmail.fm in report only mode and have had to immediately disable it. The false positives caused by many different addons that alter the page make it completely unusable in report only mode let alone attempting to enforce a CSP.

Without fixing this, CSP will be completely unusable in the real world, even when fully implemented in Firefox.

Comment 17

[Sid Stamm [:geekboy or :sstamm]]

This is causing report-uri flooding (caused by add-on changes), and also breaking add-on functionality.  To fix this we could make it easier add-ons to add exceptions for their content to CSP policy checks.  The spec says user agents should make it possible for extensions to get around these issues (but it's non-normative).

Comment 18

[Garrett Robinson [:grobinson]]

(In reply to Jonas Sicking (:sicking) from comment #12)
> Maybe we should focus on supressing error reports if the origin of a blocked
> action comes from an addon.

Anybody have thoughts on how best to determine "the origin of a blocked action"? Tainting is the obvious solution here, although inelegant and probably a fair amount of work (goes back to "making a list of everything an add-on can do" from Comment 10.

> There is going to be a lot of security problems allowing addons to do
> anything they have been able to do on CSP pages. We might over time be able
> to enable most things that have traditionally worked, but it will take time.
> I.e. it's not something we can do short-term.

However, the spec requires that CSP not interfere with add-ons: http://www.w3.org/TR/CSP/#processing-model. As you say, this creates opportunities for security problems. A discussion about this, and whether we need to change the spec as a result, was just opened on the w3c webappsec working group issue tracker: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23357

> Maybe a good short-term fix is to try to suppress the error reports, and the
> long-term fix is to make things "work" such that addons can make whatever
> changes they want to.

+1 this short-term/long-term plan combo.

Comment 19

[Frederik Braun [:freddy]]

Another stab at this would be rate-limiting violation reports. This has been discussed in the webappsec WG (is there a bug for this?) and could reduce the server load

Comment 20

[Garrett Robinson [:grobinson]]

(In reply to Frederik Braun [:freddyb] from comment #19)
> Another stab at this would be rate-limiting violation reports. This has been
> discussed in the webappsec WG (is there a bug for this?) and could reduce
> the server load

Recent related discussion from the WG: http://lists.w3.org/Archives/Public/public-webappsec/2013Aug/0000.html

Comment 22

[April King [:April]]

Has there been any progress on this bug?  It's very frustrating, and impedes the progress of CSP around the internet.

1. It causes a ton of report-uri spam, making CSP reporting endpoints difficult to run
2. It hurts the privacy of users, revealing to websites what addons they might have installed (something that should never happen), and
3. Breaks any addon which relies on injecting script into a page, which is a lot of addons

Comment 23

[fdsc]

I think this defect is more critical priority than normal. But they were never engaged for seven years now.

Comment 25

[Kuba Niewiarowski]

Bug 1389874 related.