615711 - CSP reporting exposes the presence of add-ons that inject certain elements in the DOM

Status: RESOLVED DUPLICATE of bug 615708

(Core :: DOM: Core & HTML, defect, P2)

Description

[Wil Clouser [:clouserw]]

Attachment: example add-on

When a user goes to a site that has CSP reporting enabled with a restrictive ruleset they are notified of all blocked elements, even if they didn't originate in the code of the original site.  Many add-ons inject images/iframes/objects/scripts/etc. into the pages of websites and if those sites have CSP they will be notified about the blocked element.

Add-on detection made the rounds a few years ago[1] and there were some good ideas brought up then about fingerprinting, statistical analysis, and potential security compromise.

To reproduce:
1) Enable CSP reporting on your website
2) Install an add-on that injects a blocked element into the page
3) Look at your logs

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

This is similar to bug 604177.

[1] http://ha.ckers.org/blog/20060823/detecting-firefox-extentions/

Comment 1

[Boris Zbarsky [:bzbarsky]]

Yeah, this is the same basic problem.  If you import your stuff into the web page's DOM, then as far as we know it's just part of the web page.  Not only that, but the web page can see those elements in the DOM, if it really wants to fingerprint you; it doesn't need CSP.

So:

1)  I don't think CSP causes any problems here that were not already present if
    a webpage was trying to fingerprint you.
2)  If an extension doesn't want to be fingerprinted it should not create
    content-visible objects.

Or am I missing something?

Comment 2

[Sid Stamm [:geekboy or :sstamm]]

I believe I concur with Boris on this.  CSP is just yet another mechanism to report content added to the DOM by add-ons.  One could do something similar with setTimeout() and an XHR.

Granted, we don't really want CSP to be yet another mechanism of this sort, but I don't believe it's adding attack surface and the functionality provided by reporting outweighs the minimal increased risk.

Comment 3

[Wil Clouser [:clouserw]]

I see your point about the setTimeout and XHR.  I guess if you really wanted to dig into it, the difference is that a user can opt out of your scenario (by not running scripts on the site) but in my scenario they can't - it's actually the browser sending the data to the remote site, bypassing any kind of script blocking the user has put in place.

Comment 4

[Boris Zbarsky [:bzbarsky]]

It might make sense to not report CSP violations on sites where the user has script disabled.

Comment 5

[Jesse Ruderman]

The add-ons that can be detected using CSP are a subset of the add-ons that can be detected by watching for DOM manipulation.  So this isn't a real privacy problem.

I'm kinda worried about polluting CSP logs with things the site owner can't do anything about, though!  And also the perf hit of sending CSP reports.

AMO could encourage add-on developers to consider these issues, and help them decide whether to...
* instead of injecting elements into pages, use overlays or toolbar buttons or even new APIs
* only inject elements that don't trigger CSP
* only inject elements on sites that don't use CSP
* warn users that the add-on is detectable

Comment 6

[Wil Clouser [:clouserw]]

> I'm kinda worried about polluting CSP logs with things the site owner can't do
> anything about, though!  And also the perf hit of sending CSP reports.

I agree with this, but I think you're ignoring the, admittedly small, privacy concerns of comment 3 and comment 4.

I also don't think encouraging developers to change their add-ons will help, particularly with no usable alternatives (CSP even blocks data urls, see bug 615708).  On top of all that, I expect a healthy amount of confusion and concern from the site owners when they see this start popping up in their logs.

Comment 7

[Jesse Ruderman]

I'm not enthusiastic about disabling CSP reporting when scripts are disabled. If my site uses CSP and the non-script fallback content uses to prohibited off-site images, I want to know that.

Comment 8

[Jeff Balogh (:jbalogh)]

A bigger problem than the fingerprinting is that CSP with blocking enabled would break a lot of add-ons that try to inject content into the page.

Comment 9

[Wil Clouser [:clouserw]]

(In reply to comment #8)
> A bigger problem than the fingerprinting is that CSP with blocking enabled
> would break a lot of add-ons that try to inject content into the page.

bug 615708

Comment 10

[Wil Clouser [:clouserw]]

For the record, we had to turn off CSP reporting on AMO when Firefox 4 launched because we were overwhelmed with POST requests.  The traffic concern is very legitimate since that can't be cached.  

We've since added percentage sampling so we discard most of the submissions.  The ones we do store now are overwhelmingly these add-ons that people have installed making it hard to determine if we can enable CSP or not.

Comment 11

[Brandon Sterne (:bsterne)]

(In reply to comment #10)
> We've since added percentage sampling so we discard most of the submissions.
> The ones we do store now are overwhelmingly these add-ons that people have
> installed making it hard to determine if we can enable CSP or not.

Can we create "signatures" for the violations that we can identify as being caused by these add-ons and only focus on the reports for those we're not sure about?  Twitter ran into similar problems of high report volume after they implemented CSP and were one of the loudest proponents that we implement bug 600584.

Comment 12

[Wil Clouser [:clouserw]]

We could, but then we're maintaining a list of signatures which doesn't sound like it'll scale super well (particularly on an add-on site).  There is also the additional overhead of looking up and matching those signatures before either accepting or discarding the submission.  It could mean turning down the percentage of reports we look at in order to balance the additional workload.

It also doesn't address the scenario in comment 3, but I seem to be the only one worried about that anyway. ;)

Comment 13

[Sid Stamm [:geekboy or :sstamm]]

The main issues here are that:
1. the functionality of add-ons that do this breaks
2. and the site gets false reports for addon-modified views

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