uBO is blocking legitimate CSP reports.

[ScottHelme]

Describe the issue

uBO is blocking the sending of legitimate CSP reports.

One or more specific URLs where the issue occurs

I have a policy setup on https://scotthelme.co.uk which fires multiple reports that are all blocked.

Screenshot in which the issue can be seen

Steps for anyone to reproduce the issue

Visit https://scotthelme.co.uk which attempts to send multiple CSP reports to a reporting endpoint, check the console/network tabs in dev tools.

Your settings

• OS/version: Windows 10 Pro
• Browser/version: Chrome v61.0.3163.100
• uBlock Origin version: v1.14.12

Your filter lists

Default settings.

Your custom filters (if any)

None.

[gorhill]

By design. uBO will block CSP reports if it injects at least one neutered script in a page. This is what is happening on https://scotthelme.co.uk/, uBO is injecting a neutered Google Analytics script. In such case, uBO conservately assumes that the injected script is what is causing the CSP reports and blocks them. If you create an allow rule for Google Analytics for that site, the CSP reports are not blocked.

[ScottHelme]

Given the sheer number of sites that use Google Analytics this assumption will result in a considerable reduction in the amount of reports sent from a site, resulting in missing potentially important information. I appreciate the effort to reduce the possibility of false positive reports but this approach is also blocking legitimate reports that could be identifying a security concern.

I assume there are also other scenarios where uBO would end up preventing the CSP reports beings sent, not just this Google Analytics example? Depending on the user to manually white list this in order to allow the host to collect security related reporting data is dangerous and most likely won't happen at all.

Even if uBO did cause the CSP report to be sent based on the injection of the Google Analytics script, this could be identified and filtered on the inbound reports quite easily. More importantly what it would mean is that the host would receive all of the other reports sent across their entire site. I run https://report-uri.io so I speak from a position of experience in dealing with the signal to noise ratio in CSP.

If uBO is only dropping all of the reports as a convenience then I'd suggest allowing the reports to pass and leave the reporting endpoint to do the appropriate filtering. I'd rather receive the signal amongst the noise than hear nothing at all.

[gorhill]

this could be identified and filtered on the inbound reports quite easily

This would cause information about the user to be leaked (whatever data appear in the CSP report), and worst, this could leak browsing information to a 3rd-party (such as report-uri.io) for all sites for which scriplets are injected and for which the report-uri is a 3rd party. It's more than just a matter of avoiding spurious CSP reports.

[ScottHelme]

The stance seems to have shifted from preventing spurious reports being sent to preventing 3rd party data leakage so I will address those concerns too.

The data sent to the reporting endpoint contains only the UA string and the source IP that are related to the user, the contents of the JSON POST are related to the site and the violation of the CSP that occurred. The UA string and the source IP are also sent to any asset loaded from a 3rd party like CDN hosted JS, CSS and images, tools like Disqus, iframe embeds and countless other things, yet those are not blocked.

CSP is not a tracking mechanism and has to be specifically configured by the host to send reports. uBO also appears to be unilaterally blocking all reports when it triggers the blocking behaviour, even when those reports are sent to the same host. Not only that but uBO allows the reports when no action is taken on the page.

uBO will block CSP reports if it injects at least one neutered script in a page.

Only taking action to prevent a CSP report being sent in some circumstances and not others doesn't seem to add up, can you clarify why?

[gsuberland]

Have to agree with Scott here. CSP violation alerts are an important tool for identifying potential security issues before the bad guys do. I'm a uBO user and have CSP violation reporting enabled on my site, so this behaviour concerns me.

The justification of blocking report requests because it might leak the IP address and UA of the user is weak, as was already mentioned, particularly if both the report origin and report destination URIs are over HTTPS. Not to mention that an attacker can't forge the report URI to leak to an arbitrary domain - this has to be configured by the server operator.

I understand the rationale for blocking outbound requests in general, but for the specific case of CSP violation reports I think the benefit of sending the report outweighs the benefit of blocking it.

[gorhill]

The stance seems to have shifted

It has never shifted, the spurious CSP reports (sent as a result of injecting javascript) do leak bits of information. From the point of view of the servers receiving the CSP reports, these are spurious, from my point of view of having user's best interests at heart, the CSP reports are leaking information, and as said in the worst case, browsing information when these reports are all send to the same 3rd-party servers.

Only taking action to prevent a CSP report being sent in some circumstances and not others doesn't seem to add up, can you clarify why?

Yes, it's quite simple: uBO won't be the cause of user information being leaked. The consequence of uBO doing its job (injecting neutered scripts) may cause CSP reports to be fired, hence uBO blocks CSP reports.

[gorhill]

I understand the rationale for blocking outbound requests in general, but for the specific case of CSP violation reports I think the benefit of sending the report outweighs the benefit of blocking it.

Every network request which leaves a user agent must be for the benefit of the user, including CSP reports. The user agent is not owned by the remote server such that it gets to decide what should never be blocked or not.

Hence if a network request to a remote server is potentially detrimental to the user, it gets blocked, especially if that network request is fired solely as a result of uBO doing its job. This is such case here.

[gorhill]

Related:

• Site CSP's prevent surrogates from being loaded. google-analytics on Twitter for example #2823
• https://bugzilla.mozilla.org/show_bug.cgi?id=1267027

[nzall]

uBO won't be the cause of user information being leaked.

My instinct would be to only block the Google Analytics related CSP reports, because those are the ones caused by uBO. I'm not sure if such a thing is possible, but it seems like the right move.

[nzall]

#2823

On that issue, you say:

I don't plan to have uBO lower CSP rules set by a site. In my opinion, being able to inject a surrogate is less important than not relaxing existing CSP ruleset.

Isn't blocking CSP reports configured by a site EXACTLY "having uBO lower csp rules"? the CSP report is part of the CSP rule, so blocking them is effectively the same as removing that part from the CSP. Or do you have an explanation why this case is different?

[gorhill]

Isn't blocking CSP reports configured by a site EXACTLY "having uBO lower csp rules"?

It's a report. It exists for the remote server consumption's only, it has no tangible benefit to the user. The benefit to the user was to have the actual CSP directives enforced by the browser, that is not lowered by uBO.

[ScottHelme]

I don't disagree with your point @gorhill just the execution. If you wish to block CSP reports caused by uBO then absolutely, please do! To disable all CSP reports on a page though is in my opinion dangerous and neglectful as those reports could be related to security. You're taking unilateral action on all reports.

You say that all network requests leaving the browser must be a benefit to the user but somehow see the reporting of a security violation against the user as detrimental to them? This information is designed solely to allow the host know this occurred and to take steps to remedy the problem and protect the user. CSP reporting serves no other purpose.

You also assume that all browsers are fully CSP compliant, they aren't. When CSP capable browsers report violations they allow the host to become aware of the problem and resolve the underlying cause, thus protecting all users and not just those with modern browsers.

To satisfy both of our requirements it seems like all that is required is for uBO to inspect the CSP reports and discard only those caused by uBO. Would that be a reasonable solution?

[gorhill]

somehow see the reporting of a security violation against the user as detrimental to them?

Why is the security violation silently reported to a remote server? If you think the security violation is for the benefit of the users, why is it not first reported to them by the browser? It turns out that by the look of it the entire purpose of these CSP reports is to first and foremost help servers diagnose incorrect implementation of the Content-Security-Policy header they serve.

If a CSP violation occurs on Twitter as a result of say, being infected by malware, and Twitter receives the resulting CSP report, is Twitter going to call me to notify me that there is something happening on my side? Of course not, hence these CSP reports are entirely for the benefits of the servers, as a debugging tool, not to the benefits of users, and even with potentially down the road the (apparently unforeseen) ability to turn these CSP reports into trackers (imagine sites serving CSP violations by design + 3rd-party report-to -- if you think it's a stretch, consider that if anything has been learned at this point is that internet should be assumed hostile to users.)

To satisfy both of our requirements it seems like all that is required is for uBO to inspect the CSP reports and discard only those cause by uBO. Would that be a reasonable solution?

I can look (again) into this. In the past I decided against this because of 1) the added overhead, as this required to specify the requestBody, and 2) the fact that I hadn't looked into how this could be accomplished with the old Firefox's framework. With Firefox's WebExtensions, this feels now less rebarbative, and for the overhead worry, I can probabily come up with installing just one single handler for this very specific purpose, so that requestBody would apply only to CSP reports.

[nzall]

If you think the security violation is for the benefit of the users, why is it not first reported to them by the browser?

A) CSP violations ARE reported to the user, but only if they are looking for them, in the console. B) The user cannot do anything about CSP violations. CSP violations are meant for the developers. Not giving them access to these is nonsensical. These are effectively the client-side equivalent of the stack trace for server-side issues.

It turns out that by the look of it the entire purpose of these CSP reports is to first and foremost help servers diagnose incorrect implementation of the Content-Security-Policy header they serve.

This is a completely backwards interpretation of CSPs. CSPs are meant to STOP scripts that you haven't given explicit permission to. That's their first goal: if a user somehow has a dodgy script in their page that shouldn't be there, then the CSP is meant to stop that. The reports are then so the developer can verify what's going on, whether it's caused by their code or because someone is injecting /reflecting malicious javascript in their site. In both cases, knowing what's causing it is tantamount to fixing it.

[gorhill]

This is a completely backwards interpretation of CSPs.

You keep saying CSPs when I comment about CSP reports. That just adds noise to the issue here.

[nzall]

You keep saying CSPs when I comment about CSP reports.

When I said interpretation, I was refering to the "help servers diagnose incorrect implementation of the CSP header" part. Yes, it can help with that, but diagnosing incorrect implementations is what it does during development. Once the product has been deployed, the implementation should be correct for normal use of the app, and any further reports mostly aren't related to the implementation, but rather to the usage of the CSP. I should have been clearer that I meant both CSPs (as in what it does) and the reports (as in how problems with the CSP are reported). CSPs during development are usually put on report-only, but once the product is live, they're frequently put to fully blocking.

[gorhill]

CSPs during development are usually put on report-only, but once the product is live, they're frequently put to fully blocking.

From uBO's point of view, it is completely irrelevant why a CSP report exists at all, uBO's first duty is to act on behalf of users, to do what is in their best interests. It's not something to even argue, the only thing left to argue is whether uBO should (can) be more fine-grained about which CSP reports it blocks. As you can read above, I agreed to look into this.

[gorhill]

As said above, I will look into whether it is possible and practical for uBO to block only whatever CSP reports is fired as a result of uBO doing its job.

[jspraul]

It is naive at best to think that CSP reports could never be used as a tracking mechanism. The first thing that came to mind was the possibility of a Tor-busting originating IP leak as was claimed to have been accomplished via captchas. See also the "cookie" section of What to Expect When Expecting Content Security Policy Reports.

I appreciate uBlock's commitment to protecting its users from unexpected (and typically thus unwanted) requests being made to 3rd party sites, with a default of 'nope'. I believe there is still the possibility of allowing CSP reports to be sent back the originating site, under the same circumstances which cookies are theoretically allowed if I understood the above article correctly.

It is unfortunate that uBlock will hinder the effectiveness of SaaS such as Scott's in helping web server owners/operators (who would have to ask site owners to proxy CSP reports if allowed via same-origin), but this remains in line with uBlock's reputation for protecting its users' privacy.

[ScottHelme]

Why is the security violation silently reported to a remote server?

Considerable effort is already being put into reducing warning fatigue and advising the user of CSP violations doesn't help them. Either the policy is enforced and the action was blocked so the user is protected or the policy is in report-only mode most likely because the host is testing it prior to deployment to ensure there are no bugs in the policy.

It turns out that by the look of it the entire purpose of these CSP reports is to first and foremost help servers diagnose incorrect implementation of the Content-Security-Policy header they serve.

I don't really agree with that and even if it was the case it'd only be for a very short period of time. CSP reports are designed to alert a host of the problem so they can fix the underlying cause. CSP is defense in depth, not a solution.

If a CSP violation occurs on Twitter as a result of say, being infected by malware, and Twitter receives the resulting CSP report, is Twitter going to call me to notify me that there is something happening on my side? Of course not, hence these CSP reports are entirely for the benefits of the servers, as a debugging tool, not to the benefits of users

You give one edge case example of a CSP report and declare the whole mechanism as non-beneficial to the user based upon it? I have literally helped an organisation use CSP reports from malware infected endpoints triggered on an intranet site to identify those endpoints internally. Something happened on the page so the browser is telling the host so that they can take action to investigate and resolve the issue. Just because you can't see a use for it that doesn't mean there isn't one.

even with potentially down the road the (apparently unforeseen) ability to turn these CSP reports into trackers (imagine sites serving CSP violations by design + 3rd-party report-to -- if you think it's a stretch, consider that if anything has been learned at this point is that internet should be assumed hostile to users.)

If the fear is multiple hosts and a reporting service acting in concert to track users then I can provide the Privacy Policy for https://report-uri.io and ask that it be whitelisted as a privacy respecting service. No user information is stored or analysed to track or break their privacy in any way. This way we can ensure the user is not subjected to any unwanted or unnecessary tracking and that hosts who implement reporting get the full benefit of the data provided to protect their users.

If I can provide any input on how to identify/categorise reports then please let me know, I'd be happy to help.

[kasper93]

You give one edge case example of a CSP report and declare the whole mechanism as non-beneficial to the user based upon it?

He gave an example that is applicable to regular user. He also gave a hypothetical malicious CSP reports usage example that could be applied to regular user.

I have literally helped an organisation use CSP reports from malware infected endpoints triggered on an intranet site to identify those endpoints internally.

Great story, but this is literally... "one edge case example of a CSP report". Do you really think that those reports are beneficial for the user? I mean regular uBO user?

Something happened on the page so the browser is telling the host so that they can take action to investigate and resolve the issue.

Exactly, host can analyze the data and take action. But in all real life usage user will never be contacted by the host owner. Why would he be? Except this specific case about intranet and internal endpoint, where I hope everyone can see how little it is applicable to regular uBO user. And by the way there are really better ways to detect infected machines on intranet.

EDIT:

And since gorhill agreed to take a look into the issue. I think we can stop spamming here. Sorry for that.

[temporaryaccount]

@gorhill

I'm all in for blocking the CSP reports. As you said, protecting users' best interest should be important. In case I'm using uMatrix without uBO will it block the CSP reports too?

Please consider to also block the PKP reports - it's possible to create a host which serves an SSL certificate not listed in its PKP header and track the users using a unique "report-uri" parameter for each request.

[gorhill]

Unfortunately apparently there was no attempt to show the whole picture in the media, such that now uBO is being misrepresented as "making things worse" and "uBO is taking unilateral and indiscriminate action against all reports".

These of course are false, it's rather the opposite: because uBO's primary task of serving users interests first by blocking trackers et al. is fulfilled, the end result is things are made better for users. The importance of working on behalf of users has precedence over making web masters happy by sending them data for their own consumption.

Here is an example of what would happen if uBO didn't block the CSP reports it identifies as potentially spurious (a distinction which mostly is left out in the summary descriptions of the issue outside here).

I installed Privacy Badger, and I guessed that it didn't block these spurious CSP reports, and this is confirmed in the following screenshot:

I selected the CSP report which was triggered as a result of Privacy Badger injecting a neutered script for Google Analytics on the page, this is the information contained in the CSP report:

blocked-uri: "data"
disposition: "report"
document-uri: "https://scotthelme.co.uk/"
effective-directive: "script-src"
original-policy: "default-src 'none'; report-uri https://scotthelme.report-uri.com/r/default/csp/reportOnly"
referrer: ""
script-sample: ""
status-code: 0
violated-directive: "script-src"

This is why uBO blocks the potentially spurious CSP reports, which arise as a result of uBO fulfilling its first duty to users, because one of them will contain information which should not be gathered by a remote server.

With this spurious CSP report, the 3rd-party remote server at scotthelme.report-uri.com is in a position to know that a user with a specific IP, specific user agent, and at a specific time visited the page https://scotthelme.co.uk/ and is apparently having one data: URI-based script injected on that page. It could be inferred that whoever is having a data: URI-based script injected in a page is possibly using a content blocker which supports the neutering of blocked resources.

Now let's assume that the use of report-uri.com by sites is widespread, and that the use of, say, google-analytics.com by sites is widespread. The net result is that for a user of uBO with default settings, the detailed browsing history of that user would be collated by report-uri.com, as a result of uBO merely doing its job of blocking trackers.

This is why all potentially spurious CSP reports are blocked in uBO, to prevent leaking such information.

Now the issue here is why uBO is blocking all of them rather than the specific one triggered by the injection? The blocking of potentially spurious CSP reports has been in place since a long time now, before even Chromium supported the csp_report request type in its implementation of webRequest, and before Firefox WebExtensions was a thing, and also when CSP headers, let alone the CSP report-uri directive (which I see is now deprecated) were barely used anywhere.

In short, the amount of work to do to be more discriminate was just not worth it -- the top priority was (and will always be) to block trackers et al. as efficiently as possible while minimizing site breakages, not keeping web masters happy.

Now looking into this, I realize that since now Chromium supports the request type csp_report, and that also now Chromium and Firefox can share the same implementation, it's probably feasible to work on blocking only the actual spurious CSP report (though theoretically it's not possible absolutely guarantee that unrelated CSP reports won't be blocked).

Now the issue here is being vastly overblown in the media, and unfortunately fueled by some high profile Twitter accounts with no willingness to present the bigger picture.

If a web master's site is afflicted by a XSS weakness such that CSP reports are triggered as a result, these legitimate CSP reports (as of writing) would be blocked for one user somewhere on the internet only if the following conditions are all met:

• Using uBO.
• A neutered resource is injected by uBO on the page.
  • Neutered resources are injected only when a resource on the page was blocked and that there exists a neutered version of the blocked resource.

If any one of the condition is not fulfilled, no CSP reports are blocked.

uBO's top duty is to work on behalf of users, not web sites, hence why the choice was made here to block potentially spurious CSP reports potentially leaking information to a remote server.

[uBlock-user]

Troy Hunt is a pathetic creep lurking around here and there to find any small bit piece of information he can use to blow it open on the Twitter and his blog and he holds a very old grudge against content blockers in general probably he because he doesn't get his way when it comes to folks blocking ads, promotions and 3rd party content with impunity on his blog.

[gorhill]

By the way, testing the code for the fix here, I just realized there is this filter in EasyPrivacy:

||twitter.com/i/csp_report?

Purpose is to explicitly block CSP reports, so this shows not only uBO worries about these.

I am not 100% certain (I am having trouble making sense of the content of the CSP reports in the network pane), but it does seem these CSP reports on Twitter are triggered by a blocker's cosmetic filtering (injection of inline style tags) -- I can't see them fired when I disable cosmetic filtering on the site. If confirmed, this is an example of information about the user leaking (but fortunately blocked by EasyPrivacy).

[gorhill]

he holds a very old grudge against content blockers in general probably he because

See https://www.troyhunt.com/ad-blockers-are-part-of-the-problem/, this is where it started as far as uBO is concerned. I get that some people out there dislike blockers, this is no excuse to lie and misrepresent.

[uBlock-user]

I know, I read it months ago, and that also is the basis of my statement.

[ScottHelme]

Post up the JSON payload if you like and I will provide whatever insight I can.

Isn't it weird to block CSP reports especially when they're going to the same host? They already have the UA and IP so isn't the most they may be able to determine is that you have some kind of extension installed? (which they could also do via other easier means)

[gorhill]

Fix will be in the release following the current release candidate, this needs to be tested and I don't want the current release candidate to be delayed.

Fix works only for Chromium and Firefox WebExtensions. Fix does not work on the legacy version of uBO/Firefox -- the CSP reports will be assumed spurious -- i.e. will behave just as before the fix.

If for some reasons uBO can't parse the CSP report data needed to make a decision about whether the CSP report is spurious or not, the CSP report will be assumed spurious -- i.e. will behave just as before the fix.

Anyways, I only tested on https://scotthelme.co.uk/ and https://twitter.com/. Seemed to work.

As usual, the fix turned out to be more complicated than expected because CSP reporting has changed over time. See https://www.w3.org/TR/CSP3/. I just went with what I saw in the network pane for the two above sites and the CSP level 3 documentation.

[gorhill]

Fix in 1.14.17b0, pushed to both Chromium and Firefox dev channels.

[jspenguin2017]

CSP is not a tracking mechanism and has to be specifically configured by the host to send reports.

CSP is definitely not designed to be used for tracking, but it can be used for tracking. Google Analytics is also specifically configured by the site owner, I don't see your point.
A script on the page can dynamically generate different report (by changing blocked-uri) to track the user. And Referer can be leaked to third party too, which can reveal browsing history of an user.

I have a policy setup on https://scotthelme.co.uk which fires multiple reports that are all blocked.

I would've been neutral on this issue if you didn't do that. It's pretty clear that you are abusing CSP reports for something. Basically everything on the page or added to the page is reported to a remote server, if that is not for tracking, I don't know what it is for. I'm blocking all third party requests to report-uri.com and report-uri.io until further explanation.

[gorhill]

Well, the fix here takes care of report-uri, but apparently there is also the new report-to, documented here.

A key excerpt (my emphasis):

8. Privacy Considerations

8.1. Network Leakage

Because this reporting mechanism is out-of-band, and doesn’t rely on a page being open, it’s entirely possible for a report generated while a user is on one network to be sent while the user is on another network, even if they don’t explicitly open the page from which the report was sent.

Consider mitigations. For example, we could drop reports if we change from one network to another. WICG/background-sync#107.

So this confirms that dropping CSP reports is an acceptable course of action when it comes to privacy considerations.

[uBlock-user]

but apparently there is also the new report-to, documented here.

That report-to directive is also in development at Chromium - https://bugs.chromium.org/p/chromium/issues/detail?id=726634

[gorhill]

I will need to keep an eye on this. This new Reporting API is a superset of CSP reporting. So it could happen that the current request type csp_report is replaced with a more generic one, and uBO has to be ready to deal with this. Also, as a consequence, if needed I might have to change the new "Block CSP reports" setting to something also broader to block everything going through this reporting API.

[troysjanda]

If I want to block all globally what would be the filter to add? I don't trust csp_report and want to block globally

[gorhill]

Wait for 1.14.17b1 to come out later today in dev channels and check the new "Block CSP reports" checkbox in the Settings pane.

[troysjanda]

Thanks sir

…

On Thu, Oct 19, 2017, 10:14 AM Raymond Hill ***@***.***> wrote: Wait for 1.14.17b1 to come out later today and check the new "Block CSP reports" checkbox in the *Settings* pane. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3140 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AXe_Mc97z6qbG-Sb5Nv53gDiGt7C7Rquks5st4NkgaJpZM4P7HhC> .

[ghost]

Wait for 1.14.17b1 to come out later today in dev channels and check the new "Block CSP reports" checkbox in the Settings pane.

Good. It'll be checked here.
I read this long and most interesting thread attentively. I learned that CSP reports could serve tracking. I'll be more than ever attached to uBO and grateful for its immense contribution to users' privacy and security. What is performed by certain anti-adblock actors is a shame and the fact they distort reality shows evidence that they lack arguments. Everything is tried to conciliate a healthy advertisement business and respect for users, but the ad business considers the context as a war, so a war they have. The plan is vicious. Not to mention state actors, world-wide opposed but as united to get all they can from the planet's inhabitants' privacy.

[DanAtkinson]

Okay, this isn't a tabloid newspaper so let's not turn this into a bloody moral crusade with mudslinging and emotive statements that do nothing to further the discussion.

[ghost]

Who are you to decide what is to be said, DanAtkinson?
Of course Github is dedicated to code but as I understand it there are situations where thoughts are legitimate to jump on a more general level.
Be as so kind as to remain what and who you are, no more my friend. What a lack of education!