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 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.  http://ha.ckers.org/blog/20060823/detecting-firefox-extentions/
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?
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.
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.
It might make sense to not report CSP violations on sites where the user has script disabled.
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
Summary: CSP reporting can expose what add-ons a user has installed → CSP reporting exposes the presence of add-ons that inject certain elements in the DOM
> 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.
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.
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.
(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
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.
(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.
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. ;)
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).
Priority: -- → P2
Whiteboard: [sg:nse] → [sg:nse] [CSP 1.0]
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 615708
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.