Allow CSP reporting on the same domain

[Eccenux]

Prerequisites

• I verified that this is not a filter list issue. Report any issues with filter lists or broken website functionality in the uAssets issue tracker.
• This is NOT an issue with YouTube, Facebook or Twitch.
• This is not a support issue or a question. For support, questions, or help, visit /r/uBlockOrigin.
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue.
• The issue is not present after disabling uBO in the browser.
• I checked the documentation to understand that the issue I am reporting is not normal behavior.

I tried to reproduce the issue when...

• uBO is the only extension.
• uBO uses default lists and settings.
• using a new, unmodified browser profile.

Description

CSP report-uri is blocked and I know this is intentional for 3rd-party requests, but uBO also blocks same-party requests (same domain). I understand concerns about data-leaks when sending CSP reports to a 3rd party sever. That is way I've written my own, simple reporting server... But that still doesn't work for FF+uBO. Note that this is quite important, because I actually encouraged clients to install Firefox with uBlock Origin. I have server stats and they are skewed towards Firefox (more FF users then in general population).

A specific URL where the issue occurs.

http://localhost/_test/CSP-policy-report/

Steps to Reproduce

Steps:

1. Prepare test HTML with onclick on a local Apache server. Example: CSP report test example.
2. Add Header set ... "... ; report-uri /_test/csp-report-to/" in .htaccess.
3. (optional) Add csp-report-to to the same local server.
4. Open prepared test HTML.

Example .hta:

<IfModule mod_headers.c>

Header set Content-Security-Policy "\
	frame-ancestors 'self'\
	; script-src-attr 'none'\
	; frame-src 'none'\
	; report-uri /_test/csp-report-to/\
"
</IfModule>

This is the fetch request Firefox (Nightly) is doing when uBlock is disabled:

await fetch("http://localhost/_test/csp-report-to/", {
    "credentials": "omit",
    "headers": {
        "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:123.0) Gecko/20100101 Firefox/123.0",
        "Accept": "*/*",
        "Accept-Language": "pl,en-US;q=0.7,en;q=0.3",
        "Content-Type": "application/csp-report",
        "Sec-Fetch-Dest": "report",
        "Sec-Fetch-Mode": "no-cors",
        "Sec-Fetch-Site": "same-origin",
        "Pragma": "no-cache",
        "Cache-Control": "no-cache"
    },
    "body": "{\"csp-report\":{...}}",
    "method": "POST",
    "mode": "cors"
});

Expected behavior

uBO should allow 1st party requests for CSP reporting. CSP is crucial for security reasons, and reporting is, in our case at least, a service for our users. Our clients are public libraries, many lacking dedicated IT departments. Small libraries are fortunate if they receive a monthly visit from an IT professional. Our users also include children from primary schools who cannot report problems directly. Therefore, automatic reporting of security issues is essential. Both librarians and children are vulnerable to security problems such as XSS and clickjacking. If something is going on we could block a specific installation, inform librarians and investigate.

Additionally, note that CSP can report issues related to valid usages. Despite blocking our site's usage in an iframe (mostly due to clickjacking prevention), we still want the ability to identify valid use cases that we may consider allowing in the future.

Actual behavior

The CSP request is blocked. Even on the same domain. Even on localhost.

Note that FF itself doesn't block CSP reporting even in enhanced privacy mode.

uBO version

1.55.0

Browser name and version

Firefox Nightly v123.0a1

Operating System and version

Windows 10

[gwarser]

LiCybora/NanoDefenderFirefox#196 (comment)

report-uri is deprecated. report-to not implemented.

---

I'm glad report-to is not enabled, because it seems to be another hole to soak fingerprintable data mozilla/standards-positions#104 (comment)

[Eccenux]

report-uri is deprecated. report-to not implemented.

Exactly why I use report-uri.

I'm glad report-to is not enabled, because it seems to be another hole to soak fingerprintable data mozilla/standards-positions#104 (comment)

CSP reporting on its own doesn't provide any identifying information (no IP, no browser info, not even browser type). Of course, you have an IP from the request itself, but that is the same as I already have for any standard API requests. Leaking IP, etc., is only a problem for 3rd-party reporting tools. As mentioned before, Mozilla's Firefox does support report-uri even in enhanced privacy mode.

Note that I want to add CSP exactly because otherwise user data might leak out to 3rd parties. CSP is an extra layer of security for XSS problems, and XSS is an extra 3rd-party request (most of the time). Also, as a result of an attack, you could maybe even hijack an administrator password (which would be a huge privacy problem, not likely in our case, but more likely in a more generic situation).

But I can just add CSP without reporting, right? No, unfortunately not. Excessively strict CSP might break some existing features. So, we cannot use a more strict CSP if we will not be able to monitor the situation properly. And a loose CSP means less security for users... I really don't want that extra security to die on the altar of stability, but that might be the reality of the situation.

As a side note, I want to add that I looked through many documentation and articles on CSP lately. Most of them (almost all of them) point out that (as a starting point) you should always use reporting with Content-Security-Policy-Report-Only to avoid blocking things that shouldn't be blocked. Even OWASP mentions this:

2. Content-Security-Policy-Report-Only Header
   [...]
   This is also a W3C Spec standard header. Supported by Firefox 23+, Chrome 25+ and Opera 19+, whereby the policy is non-blocking ("fail open") and a report is sent to the URL designated by the report-uri (or newer report-to) directive. This is often used as a precursor to utilizing CSP in blocking mode ("fail closed")

[pcjmfranken]

Check the wiki's section on CSP reports¹ for arguments in favour of blocking these reports, as well as instructions for employing dynamic filtering rules to configure this on a per-site basis that works regardless of the relevant global setting.

Maybe you could deploy² the correct setup for your specific needs to just your clients.

Footnotes

1. https://github.com/gorhill/uBlock/wiki/Dashboard:-Settings#block-csp-reports ↩

2. https://github.com/gorhill/uBlock/wiki/Deploying-uBlock-Origin ↩

[Eccenux]

Maybe you could deploy2 the correct setup for your specific needs to just your clients.

Company I work for is selling a service and helpdesk. We are not selling systems with pre-installed Firefox. I can suggest some things, but cannot enforce them. I wouldn't even want to be able to enforce them. We have millions of users. Some of them are kids. We don't even have any actual analytical tools where kids are involved.

You can block network requests made as a result of your browser reporting Content Security Policy violations ("CSP reports") to a remote server (which can be 3rd-party to the site where the violation occurred).

I can understand that you block 3rd-party calls. You should consider having different results for 3rd party calls and same domain. uBlock (by default) is not blocking images if ads come from same domain (1st-party).

Important: disabling CSP reporting is not something that will break web pages. The purpose of CSP reporting is strictly a development tool for websites.

It is a development tool, but not a tool that is only used during development. I wouldn't bother with reports if it would be only needed during development. I have a browser console for that.

https://w3c.github.io/reporting/#privacy
That said, it can’t be the case that this general benefit be allowed to take priority over the ability of a user to individually opt-out of such a system. Sending reports costs bandwidth, and potentially could reveal some small amount of additional information above and beyond what a website can obtain in-band ([NETWORK-ERROR-LOGGING], for instance). User agents MUST allow users to disable reporting with some reasonable amount of granularity in order to maintain the priority of constituencies espoused in [HTML-DESIGN-PRINCIPLES].

I don't mind that uBlock can block CSP. By all means allow users to block any individual request. Just don't do it by default. That is all I ask. As said before, allowing CSP Reporting does actually benefit users. Various groups of users have different functions and use functions differently and they add various kinds of content to the app which make it behave differently. Although ideally one could test everything in-house it is not really feasible. CSP Reporting is made for that - make sure rules don't send any reports. If they do send reports in normal situations, then the rules need to relaxed before patching app. In abnormal situations, when a user is attacked, then the report is needed even more and benefit a user directly.

[gorhill]

Probably best is to add a sub-option to not block 1st-party CSP reports.

[Eccenux]

So, after a year, these are just some examples of URIs blocked, probably mostly on Chrome.

• https://connect.facebook.net/en_US/... – Facebook trying to spy on kids, probably adding something with an extension (we don't use any Facebook pixels or similar tracking tools).
• https://ff.kis.v2.scr.kaspersky-labs.com/... – Kaspersky attempting to use its potentially invasive frame. In theory, this could be valid, but given the company's reputation...

There are many more examples from various sources, such as weird iframes, inline scripts, etc.

I would like to emphasize again that CSP is for the user's benefit. Please don't block 1st-party CSP reports by default.