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 unsafe-inline 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

edit

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

Current policy: default-src 'none';
style-src 'unsafe-inline' data:;
font-src data:;
img-src data: https://upload.wikimedia.org/favicon.ico;
media-src data:;
sandbox;
report-uri https://commons.wikimedia.org/w/api.php?reportonly=1&source=image&action=cspreport&format=json&
(Also using old versions of header name)

Current state:

  • In testing on all wikis except enwiki, commonswiki

To do:

  • 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

edit

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

edit

Current state:

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';
default-src 'self' data: blob: upload.wikimedia.org https://commons.wikimedia.org 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;
style-src 'self' data: blob: upload.wikimedia.org https://commons.wikimedia.org 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';
img-src * data: blob:;
report-uri /w/api.php?action=cspreport&format=json&reportonly=1&

  • 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.

To do

edit

Step 1

edit

Step 2

edit

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

edit

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

edit

Enforce everywhere.