User:BWolff (WMF)/CSP plan

Plan for using CSP to prevent loading external resources:

Goals:
 * 1) Prevent admins from accidentally violating the privacy policy (e.g. Putting google analytics into mediawiki:Common.js)
 * 2) In the event that we have a malicious actor mess with site JS, ensure we have an audit trail of what happened, by disallowing external js so all js was saved in wikipages.
 * 3) [in parellel but separate from the other goals] Restrictive CSP on upload.wikimedia.org to mitigate malicious user uploads (esp. SVG)

Non-goals:
 * 1) Improve security of site javascript/prevent XSS. In the future getting rid of   could help with this significantly. But this is a non-goal right now as just forbidding external JS is a big enough task and likely to cause some pushback. At some future date we may want to do this, but not now.

In terms of Requests_for_comment/Content-Security-Policy we are doing stage 0-2 and 7. We are not doing the other stages in that document for the time being.

Risks:
 * Previously we allowed third party resources in personal JS, and also in cases where the user opts in. Taking this away is likely to annoy users.
 * The reporting mechanism could be spammed a lot, resulting in too much spam to logstash (If it becomes an issue, we could only enable reporting probabilistically)
 * A subrisk of that - if someone does something wrong on say enwiki common.js, we would get a massive jump in log events
 * A subrisk - using the API as the reporting endpoint means that in the unlikely event things became overloaded, it could in theory overload the entire API instead of just the reporting mechanism (imo, risk of this happening is low)

Upload CSP
This is separate from the rest of the CSP stuff. It is very unlikely to cause pushback from users barring unforeseen bugs.

Current policy: (Also using old versions of header name)

Current state: To do:
 * In testing on all wikis except enwiki, commonswiki
 * Maybe change format=json to format=none.
 * Need to verify it doesn't break certain things with videos, especially on cell phones that do weird stuff.
 * Then we enable on enwiki, followed by commons.
 * Then turn testing into enforce.

RL & API CSP
As a paranoia measure, probably doesn't hurt to add restrictive CSP to Resource loader and (non-help) API module output. It can act as defense in depth in the event someone manages to figure out a way to make RL or API output something that can be interpreted as html.

Wiki CSP
Current state:
 * In testing on group0 (e.g. https://test.wikipedia.org, https://www.mediawiki.org)
 * Current CSP policy is:


 * Potential adjustments in policy to investigate:
 * Make images follow default-src instead of broader *
 * Should it specify https:// instead of just the hostname?
 * wikimedia.org needs to be allowed for mathoid
 * upload.wikimedia.org https://commons.wikimedia.org meta.wikimedia.org Don't need to be in default src due to wildcard (They are currently being automatically added by CSP code for other MW features)
 * format might as well be none instead of json.

Step 1

 * Better tools to filter false positives from CSP log (ideas: field to indicate if user is logged in. Field if the source file is from the local wiki).
 * In our current test, get a list of affected things, and maybe reach out to people responsible ( https://logstash.wikimedia.org/goto/dc7bf465ac68c072af918bdce116072c )
 * Current list of affected things:
 * cvn.wmflabs.org seems to show up a bunch (Probably from https://meta.wikimedia.org/w/index.php?title=User:Krinkle/Scripts/CVNSimpleOverlay_wiki.js ). Usually also makes calls to https://tools.wmflabs.org/intuition/api.php
 * w:zh:User:镜音铃/Wikiplus / https://github.com/Wikiplus/
 * Some stewards are showing up with https://tools-static.wmflabs.org/meta/scripts/
 * https://xtools.wmflabs.org/api/page/articleinfo/www.mediawiki.org/Manual:Interface/JavaScript?format=html&uselang=en
 * https://labels.wmflabs.org (via people loading: https://labels.wmflabs.org/gadget/loader.js )
 * https://calendar.google.com on officewiki google calendar gadget.
 * https://tools.wmflabs.org/phabricator-bug-status/queryTasks?callback=jQuery321010145482690508523_1534942247808&ids=%5B199439%5D&_=1534942247809 via MediaWiki:Gadget-BugStatusUpdate.js
 * https://overpass-api.de/api/interpreter via https://www.wikidata.org/w/index.php?title=User:Abbe98/osm.js
 * [To check] There's some weird maps stuff using tool labs on wikivoyage.
 * Other weird things to investigate:
 * What is android-webview-video-poster
 * Another thing to consider, is will users consider it acceptable to totally block external resources. Maybe we might have to compromise and add a user preference to re-allow external resource (But still block external scripts in all cases). Thus allowing power users to still hit up external APIs using AJAX+CORS (like https://cvn.wmflabs.org/api.php) if they opt in.

Step 2
Once we have a good idea of how things are affected, we should enable CSP report only on further wikis to get a bigger sample size on potentially affected things. At this stage we should consider making test.wikipedia.org enforce, so people have somewhere to test their scripts on.

Open question: What should our user engagement plan be like? Is this the stage we start talking to users, or do we start earlier.

Step 3
Start enforcing in some real (non-test) places. Good first candidates are things like mediawiki.org and officewiki. We may also want to pick some smaller user-facing wikis to start with. I think ideally we'd look through the logs and pick whatever wiki has the lowest CSP violation reports. Or ask some wikis to be volunteers to go first.

Step 4
Enforce everywhere.