Talk:Requests for comment/Content-Security-Policy

First off, glad it's finally implemented.

Am I off with the syntax? @Bawolff

$wgCSPHeader = [
       'default-src' => [
               'self'
       ],
       'img-src' => [
               'site.com'
       ],
       'style-src' => [
               'site1.com',
               'site2.com'
       ]
];

default-src appears to register, but not img-src nor style-src.

I had to use "'self'" so that it has single quotes in the browser:

$wgCSPHeader = [
  'default-src' => [
    "'self'"
  ]
]

In fawiki we have many gadgets which use wmflabs.org as a service and for all of these gadgets browser shows similar to this error. how can i solve it in our codes (javascript/python)?

load.php?lang=fa&modules=startup&only=scripts&raw=1&skin=vector:11 [Report Only] Refused to load the script 'https://labels.wmflabs.org/gadget/loader.js' because it violates the following Content Security Policy directive: "script-src 'unsafe-eval' 'self' meta.wikimedia.org *.wikimedia.org *.wikipedia.org *.wikinews.org *.wiktionary.org *.wikibooks.org *.wikiversity.org *.wikisource.org wikisource.org *.wikiquote.org *.wikidata.org *.wikivoyage.org *.mediawiki.org 'unsafe-inline'". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.

for example this gadget

You should file a bug with the ORES people (If its an officially supported api, it probably is not supposed to be run on toolforge cloud VPS). There's not much you can do yourself at this time.

So far this error is just a warning. We will have a better system in place prior to this warning becoming an error. (e.g. a way for specific gadgets to opt out. Ideally the labels service would be moved into production). This may take a while, so for now you can just ignore the warning.

@Halfak (WMF) potentially interesting discussion for you to join here. Both @Yamaha5 and @Bawolff have confused labels.wmflabs.org for tools.wmflabs.org, but I believe the intent of the RFC is the same for either: eventually blocking js loading from Cloud VPS projects by on-wiki scripts.

Yes indeed. My apologies for conflating the two.

Ideally JS would never be loaded from something off production. The last plan I heard, Other data loads from non-production sources would be ok if the user opt-ed in to it - but nonetheless ideally that would not be used for anything maintained "officially" by WMF (not sure how "official" labels is supposed to be).

p.s. I should note, I no longer work for WMF and aren't working on this. This is just where things stood at the time I left.

@BDavis (WMF) Most of these gadgets worked for years and trusted. We should have a local whitelist to make a decision locally.

@Yamaha5 That is a fair argument to make to the folks in Wikimedia Security Team or whomever is currently working on this RFC's implementation. I believe that the intent of phab:T208188 is to allow such exceptions on a case by case basis.

Hey folks. We stopped recommend people load our JS from labels.wmflabs.org in mediawiki a while back. But we never disabled that functionality. I think it would be a fine idea to replace that Javascript with something that would direct people to do their labeling work on https://labels.wmflabs.org/ui/

@Halfak (WMF): That bot's concept is completely different from Lables.wmflabs. it checks miss-spelling or typos and some other problems in an article like this tool. Also we have other tools which are run based on the tools.wmflabs like move a list of cats and edit all their pages or adding category to articles based on the en.wiki's categories.

Oh yeah. I was only commenting WRT the use of labels.wmflabs.org JS as cross-site inclusion.

This is definitely a good idea, and even coming too late imo. But, carrying this thread on, I'd like to see *.toolforge.org and *.wmflabs.org added to the CSP directive on WMF wikis - having this as an option would be a huge plus for tools like mine (RedWarn) which use libraries not included in MediaWiki itself through toolforge CDN proxies.

@Bawolff: I was experimenting a bit with this new setting and it works as far as I can see. However it will be nice to be able to add something like "www.google.com/recaptcha" to the "script-src" parameter instead of just "www.google.com" to allow for an even more fine-grained control.

In theory i think that should work. Note though, that in CSP, www.google.com/recaptcha would be only precisely that page (There's some special rules for redirects also). You'd need to do www.google.com/recaptcha/ for all js pages starting with that prefix.

I think ideally the user wouldn't add this, but the recaptcha extension would use the ContentSecurityPolicyScriptSource hook to add this (Possibly the hooks for extensions could be thought out more. Maybe we need a method of OutputPage (or even ParserOutput) to add domains to CSP policy only for specific pages)

Thanks a lot for your comment. Well I was kinda hoping that "www.google.com/recaptcha/" would cover all of the scripts coming trough that path but in the end I am with you that the Recaptcha module to the ConfirmEdit extension should cater for it. From your reply I see two tasks need to be created: one for MediaWiki about adding a method to be able to allow extensions use it, which in turn is the second task for the ConfirmEdit extension (actually using it). I believe that you are more proficient to create a meaningful task when it comes to the first one.

So, "www.google.com/recaptcha/" with a / should cover all paths for recaptcha. In CSP, paths ending in / are considered to mean the directory, where paths that don't end in / mean exact match (like a file).

Thanks for bumping me. You are right, adding "www.google.com/recaptcha/" allows for a more narrow restriction of what may be loaded. Still the other two tasks need to be created since these are improvements to be done?

So there is currently a hook extensions can use, but its probably not ideal for that usecase. A more fine-grained ability (i.e. via OutputPage) still needs to be done.

At this stage, I'm primarily focusing on getting the minimum needed to get the initial deployment done on Wikimedia, but I also definitely want to ensure all the necessary pieces are there for non-wikimedia deployments, including proper extension hooks.

I figured that it might be preferable to have tasks at phabricator for this. I am far from trying to change current plans. In the end I very much value your overall work on and for MediaWiki and trust your ways of proceeding.

As Extension:MapSources was mentioned: In dewp there are two pop-up maps commonly included in articles (cf. for example Berlin, icons to the right of "Koordinaten:"). Eventually, AFAIK the OSM map will be replaced by Extension:Kartographer; I don't know if there are plans for WikiMiniAtlas. Both currently reside in (Tool) Labs and need to be addressed at some point. If .wmflabs.org would be white-listed, due to the open nature of (Tool) Labs there would not be an effective protection against attacks.

I suspect Wikivoyage will be affected much more because it uses map tiles from external sites. Even though we have switched the default tileset on most of languages, the Dutch community lead by FredTC has strongly opposed the switch. For that reason Interactive team had implemented a extra layers feature that is under the control of the community. This simply matches the existing functionality plus adds a proper warning for the users that they will be exposing their browsing to a 3rd party on click.

Stuff embedded as an iframe won't be immediately affected. <iframe>'s take the CSP policy of their source document, not the CSP policy of the document they are embedded in, except that the CSP policy of the embeding document can control what is allowed to be embedded. In this RFC, it doesn't include limitting child-src (ie What urls can be in iframe's) way until stage 7, which is a long way off. If we eventually do get there, we could possibly make an exception for OSM/WMA if that is so desired.

Bawolff, could you take a look at Maps with extra layers on en-Wikivoyage (the anchor jumps to the wrong place for some reason) - will that break? (the layers button in the upper right corner)

Yes, stage 7 would break that. We're probably not going to get there for a long time. But probably what we could do is have some sort of interface, where extensions could register extra sources that are allowed on a per-page basis.

Just a note from some local testing I have been doing with another app and CSP: the reporting endpoint will get some unknown amount of noise due to browser plugins. One that I have seen in my own browser setup is a warning triggered by the uBlock Origin Firefox plugin:

{
  "csp-report": {
    "blocked-uri": "self",
    "document-uri": "http://...",
    "line-number": 1,
    "original-policy": "script-src 'self'; default-src 'none'; img-src 'self'; media-src 'none'; style-src 'self'; object-src 'none'; connect-src 'self'; font-src 'self'; report-uri http://...",
    "referrer": "http://...",
    "script-sample": ":root #content > #right > .dose > .doses...",
    "source-file": "http://...",
    "violated-directive": "style-src 'self'"
  }
}

The eventual reporting/analysis tool that is used to decide what needs fixing from the logs will need to be prepared to deal with filtering such noise out.

I also like the general direction, as well as the phased approach. Some thoughts / notes off the top of my head:

• HTML and SVG responses from APIs are also a good target for CSP headers. As an example, the REST API already sends CSP headers disallowing unsafe inline scripts, and limits style loading to a few domains. This can be further tightened down, especially for media.
• JSON API responses containing HTML do not directly profit from CSP protection, and are commonly used in a way that requires the HTML to be properly sanitized. Having restrictive CSP headers on the parent page should be able to mitigate some issues from injected content, but probably not all of them. We should be clear about which issues cannot be addressed by CSP.

• Agree 100% about API responses. I also think things like serving images from Special:Undelete would also be a good target
• Indeed CSP will certainly not solve every security problem. In the JSON API case, at best it might help things if there is an insecure script on wiki, using the json response in an insecure way (That is, just throwing the html contents of some part of the json into innerHTML or something)

Setting Content-Security-Policy is definitely a good idea. Like Strict-Transport-Security, I think it's a basic best practice for any modern website.

I think this needs quite a lot of thinking through before it's implemented, but I like the careful, measured approach the proposer has taken to in proposing an incremental rollout instead of a flag day update.

Two questions:

• is there any way that we can either scan for, or instrument, what's going on at the moment to help find out what might break as we tighten up security?
• could we perhaps centralize CSS and JS content on separate domains devoted solely to serving such executable content across all Wikimedia sites, so that, for example, content now at //en.wikipedia.org/.../something.js would be served via //js-server.wikimedia.org/en.wikipedia.org/.../something.js , and ditto for sinilar corresponding css-server.wikimedia.org. font-server.wikimedia.org etc. etc. hostnames? (These domains could, of course, all point to the same servers/server cluster as everything else: the distinction is purely semantic, to allow for fine-grained policy filtering.)

  This would require some more (but relatively simple) infrastructural changes to create the necessary server-side configuration to serve the content from the new URLs, but would make the policy much smaller and easier to understand.

For instrumenting:

We could maybe use the search engine to look for strings that look suspicious (perhaps insource:/on\w+=/ intitle:js. insource:/javascript:/ intitle:js yields quite a lot actually. I think part of the problem there is there is no way to pass a function to mw.util.addPortlesLink currently.

Ultimately, we won't have a true idea until we start actually adding the Content-Security-Policy-Report-Only header. At the initial stage, we could also only add the header to something like 0.1% of users, so we don't end up drowning in reports.

For separating on to separate domains:

The main reason that the policy is long is for compatability with user scripts loading things from other sites. If we're willing to break that (When I first wrote the RFC I thought it would be bad to break that, but now I actually am more leaning towards allowing that, especially if we still allow meta), we could simply use 'self' after every keyword, and I think that would be very easy to understand.

If we do decide to limit default-src (or more specificly connect-src) we would need the full list of wikimedia domains in order to do CORS.

So I don't think we'd actually get much from separating out those content types into separate domains.

I take your point. Given the sheer amount of content we're already serving with each page, having the complete list of domains is probably not that much extra bloat, bearing in mind the possible substantial improvement in security that it will make possible, and also the likelihood that HTTP/2 header compression will optimize it all away for all but the first page load.

However, we should also bear in mind that the default size of the dynamic header compression dictionary is only 4096 bytes: see https://tools.ietf.org/html/rfc7540#section-6.5.2 -- if we blow that buffer out, the full benefits of header compression will cease to apply. So someone will need to keep an eye on possible "header bloat" in the longer term.