While looking at a separate csp-related task, I noticed that we no longer appear to be serving content-security-policy-report-only headers to authenticated users on group1 and group2 wikis, which T207900 and its related change sets were supposed to implement. Looking at the relevant config block within CommonSettings.php, I'm not sure this ever worked? Though I feel like I remember seeing csp reports for enwiki, etc. within logstash, at some point. This conditional (as noted in the code comment) should, in theory, handle the logic that sends the report-only header for authenticated mediawiki users, but does not. And wmgUseCSPReportOnly and wmgUseCSP are currently false for group1 and group2 wikis. I'm not sure currently how much of an issue this is since CSP on the projects has been stalled for some time. The easy fix is setting wmgUseCSPReportOnly's default value to true, or at least add group1 and group2 keys set to true, but this would enable csp reporting for all users, anon and authenticated, which would probably be bad. And that doesn't address the logic issue of wmgUseCSPReportOnlyHasSession supposedly being allowed to override certain configurations of wmgUseCSPReportOnly and wmgUseCSP.
Description
Details
- Risk Rating
- Medium
- Author Affiliation
- WMF Technology
Related Objects
Event Timeline
The way it ended up being implemented, is that wmgUseCSPReportOnlyHasSession controls the CSP behaviour within the scope of whether it is enabled. It does not by itself enable it. I think that might actually be easier to reason about - if it weren't for the confusing comment and variable name.
I'd propose the following to perhaps better model what we have:
- $wmgEnableCspEnforce (wmgUseCSPReportOnly)
- $wmgEnableCspReport (wmgUseCSP)
- $wmfCspForSessionsOnly (wmgUseCSPReportOnlyHasSession)
Related to how CSP is configured: T288225: Remove need for $wgExtensionFunction to configure CSP in MediaWiki
I don’t think it even does that at the moment, since the whole session check currently only runs if CSP is fully disabled, making it a no-op as far as I can tell. (I just reported this at T353816 without checking whether it had been reported before; possibly it’s a duplicate of this task, not sure.)
Just as a historical note - the primary goal at the time was to be a test in preparation of using real CSP, which never happened. Report only headers by themselves provide questionable value. I suppose they could be used to help enforce policy around not including external resources in common.js, as well as in compromise scenarios where off-site js is loaded, however there is probably a real question of if it makes sense to continue with them if there is no plan to use the real header (I know krinkle has had opinions on this in the past)
I know this is an older task dealing with a few different issues, but I'd like to get group1 wikis into report-only mode via: https://gerrit.wikimedia.org/r/1216660. Given the volume we've seen for group0 wikis over the past few months (~ 50k to 90k per day on average, save that weird spike):
I think this should be ok, re: volume of reports. And we can always revert if it becomes untenable. The impetus behind this has been the strong reconsideration of setting some variety of enforcing CSP in Wikimedia production as part of the work related to T398517. And since we'll likely need to build some variety of allow-list mechanism(s) per T208188 et al, we'll need to better understand total usage around third-party resources across all projects.
Change #1216660 merged by jenkins-bot:
[operations/mediawiki-config@master] Set CSP Report Only mode for group1 wikis
Change #1224144 had a related patch set uploaded (by SBassett; author: SBassett):
[operations/mediawiki-config@master] Set CSP Report Only mode for all wikis
Change #1224144 merged by jenkins-bot:
[operations/mediawiki-config@master] Set CSP Report Only mode for all wikis