Page MenuHomePhabricator

Content Security Policy (CSP)
Open, NormalPublic

Description

Imported from bugzilla.wikimedia.org (original author: seather).

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks and unintentional privacy policy violations. Including:

  • Reduce Cross Site Scripting (XSS) and data injection attacks.
  • Avoid accidental loading of images, fonts, styles or other resources from third-party domains.

https://developer.mozilla.org/en/Introducing_Content_Security_Policy
https://www.w3.org/TR/CSP/

Enabling CSP is as easy as configuring your web server to return the Content-Security-Policy HTTP header.

Other products jumping on the band wagon:

See also:

Details

Reference
bz26508

Related Objects

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 21 2014, 11:21 PM
bzimport added a project: MediaWiki-JavaScript.
bzimport set Reference to bz26508.
bzimport added a subscriber: Unknown Object (MLST).

Blocking JS url's would break stuff, if not in core, definitely in userscripts. Well it'd be nice if we didn't use html event handler attributes, many extensions still do (many extensions also probably use eval). Most of this stuff probably wouldn't be too useful, but some of it possibly might.

Restricting what places the scripts can come from might be interesting (easy way to stop naive admins from including scripts from third parties). But one would have to be careful not to break things. People include scripts from other wikimedia projects and so on.

Adding Tim to see if he has any input on this security-related issue.

The first step is to remove all JavaScript that is embedded into the HTML output by the MediaWiki core via inline script-tags or "on"-attributes.

Most inline javascript is created while the HTML page is rendered and contains data that is specific to the current page. This data can be stored in data-attributes for HTML 5 and attributes in a non-html namespace for XHTML.

Once the MediaWiki core supports CSP, there could be a user option to enable unsave scripting. And a function for extensions to add unsave-inline, unsave-eval or urls to the whitelist.

At the beginning of this year -when this feature request was made- only Firefox supported CSP. But among Webkit based browsers, even the latest preview of Internet Explorer 10 supports it now.

The current draft of the specification is at: https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html

Hopefully not too off-topic: with "X-Content-Security-Policy: allow 'self'" set on the server, the "Vector" skin is not rendered correctly any more - but only in Firefox (no plugins loaded); Safari/Chrome/Opera are fine:

http://nerdbynature.de/bits/mw-26508/

Not sure if this is a problem with Firefox or something Mediawiki will have to fix.

Looks like it's considering data: image uris to not be permitted.

Apparently you'd need to use a header like:

X-Content-Security-Policy: allow 'self'; img-src 'self' data:

to allow data urls. But we also have inline js in vector skin that from my understanding won't get along with this.

FWIW, I took the setting from the (out-of-date) https://people.mozilla.com/~bsterne/content-security-policy/details.html#examples, where it was described as "Site wants all content to come from its own domain".

@Bawolff: yes, the setting you mentioned helps!

For those interested in CSP I put together a starting CSP branch:
https://github.com/dantman/mediawiki-core/compare/master...csp

It uses a proper api. It's got the starting for whitelisting ResourceLoader stuff. But it could use more work through core adding whitelists for images included in the parser output (ideally both local and foreign whitelisting).

I also haven't checked if anything we have relies on eval() which would require some extra metadata to tell the CSP code that it should allow eval() in the page.

Another CSP warning, MW 1.19.1, Firefox 13.0:


Timestamp: 6/21/12 01:37:49
Warning: CSP: Directive "inline script base restriction" violated
Source File: https://foo.example.com/wiki/Test
Line: 23
Source Code:

if(window.mw){ mw.config.set({"wgCanonic...

The warning is issued when a table with "class=sortable" is used and the sort-buttons are not displayed in Firefox. Setting X-Content-Security-Policy to

"allow 'self'; options inline-script; img-src 'self' data:",

makes the warning disappear and the sort-buttons are displayed.

Firefox & Chrome both have CSP enabled now. A single page load (6k article) gives multiple errors, here's how Chrome articulates this:

  • times reported, per page | v 6 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.

    6 Refused to execute inline script because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.

    11 Refused to load the image 'xxx' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'img-src' was not explicitly set, so 'default-src' is used as a fallback.

So, we have 23 CSP violations on a single page. Without a special CSP header for the mediawiki installation, these resources are NOT loaded and the wiki page looks not really pretty.

To make these warnings go away, the following CSP would be necessary:

"default-src 'self'; img-src 'self' data:; script-src 'self' 'unsafe-inline';
 style-src 'self' 'unsafe-inline'",

But especially these "unsafe-inline" statemtents are not recommended.

So, what can we do about this?

matmarex updated the task description. (Show Details)Dec 21 2014, 7:26 PM
matmarex edited projects, added MediaWiki-General; removed MediaWiki-JavaScript.
matmarex set Security to None.
matmarex removed a subscriber: Unknown Object (MLST).
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 9 2015, 9:03 AM
Krinkle updated the task description. (Show Details)Apr 13 2016, 9:32 PM
Krinkle added a project: Security-Team.
Krinkle updated the task description. (Show Details)
Nirmos added a subscriber: Nirmos.Sep 19 2017, 12:17 PM
Reedy added a subscriber: Reedy.
[15:18:19] <Reedy> https://twitter.com/Scott_Helme/status/962684239975272450
[15:18:21] <Reedy> This is fun
[23:33:32] <bd808> Reedy: crap like that is why we need CSP headers on the wikis

Will I as a gadget author have access to the violation reports for svwiki?

Will I as a gadget author have access to the violation reports for svwiki?

Not currently (As it may contain private data). We will need to find some way to get that info to gadget authors. The initial rollout will just change sources but still allow unsafe-inline, so it shouldn't affect too much.

RP88 added a subscriber: RP88.Sep 14 2018, 10:54 PM

@Bawolff I'd like to get svwiki in report-only mode. Should I start a discussion with the community about this now, or is it way too early?

@Bawolff I'd like to get svwiki in report-only mode. Should I start a discussion with the community about this now, or is it way too early?

Awesome. Thank you for volunteering. Actually do to certain circumstances, we are planning to expediate rolling out test mode to logged in users, so it should be happening for svwiki very soon.

See also T207900

I can't edit a certain page in ruwiki (https://ru.wikipedia.org/wiki/%D0%A1%D0%B1%D0%BE%D1%80%D0%BD%D0%B0%D1%8F_%D0%AF%D0%BF%D0%BE%D0%BD%D0%B8%D0%B8_%D0%BF%D0%BE_%D1%80%D0%B5%D0%B3%D0%B1%D0%B8-7 ) because of tons of errors related to Content Security Policy/CORS policy in browser console


2010 edit toolbar doesn't displayed, when I click on "Save" button, nothing happens, when I click preview, I got an error "HTTP error: error". Chrome (last release version), Monobook. There are not this issue in Firefox. Other pages can be edited.

MaxBioHazard raised the priority of this task from Normal to High.Nov 14 2018, 3:37 PM
Bawolff lowered the priority of this task from High to Normal.Nov 14 2018, 5:53 PM

@MaxBioHazard CSP is in test only mode - which means it puts errors in the console, but doesn't actually do anything (yet). Any issues you are having is not caused by the CSP warnings.

That said, something looks wrong here, as many of the csp report urls for your user are for things that should be allowed under the CSP policy. (The only one's that seem valid are the blocks for dl.metabar.com).

I would say that its either some sort of browser bug, or a problem with an add-on that you have installed in your browser.


As an aside, this is the bug about long-term rollout plans for CSP. Issues encountered related to CSP should be filed as separate bugs.

I updated Chrome to version 70.0.3538.102 and this doesn't happen now.

@Bawolff where you see dl.metabar.com on my screenshots? I want to know what of my userscripts accesses this URL.

I updated Chrome to version 70.0.3538.102 and this doesn't happen now.
@Bawolff where you see dl.metabar.com on my screenshots? I want to know what of my userscripts accesses this URL.

We record CSP reports. (Part of the reason we have csp in report only mode is to discover what would break if we turn it on). That was listed for your user in our csp reports database. I think that domain is associated with a browser plugin [maybe a yandex plugin] (some poorly written browser plugins are subject to the websites CSP policy, which really doesnt make sense) and not with a user script.

I don't have any Yandex plugin. I have only 4 enabled browser extensions: Google Translate, uBlock Origin, View Image (a small ext for Google Pictures) and a bypass of Russian state Internet censorship (https://chrome.google.com/webstore/detail/%D0%BE%D0%B1%D1%85%D0%BE%D0%B4-%D0%B1%D0%BB%D0%BE%D0%BA%D0%B8%D1%80%D0%BE%D0%B2%D0%BE%D0%BA-%D1%80%D1%83%D0%BD%D0%B5%D1%82%D0%B0/npgcnondjocldhldegnakemclmfkngch). Wiki[pm]edia is whitelisted in uBlock settings.

Rillke added a subscriber: Rillke.

API returns warnings about Unrecognized parameters at Wikimedia Commons.

{"warnings":{"main":{"*":"Unrecognized parameters: {\"csp-report\":{\"blocked-uri\":\"https://tools_wmflabs_org/convert/svg2png_php\",\"document-uri\":\"https://commons_wikimedia_org/w/index_php?title, withJS."}},"cspreport":"success"}

The warning message indicates the title and withJS parameters are unknown?

API returns warnings about Unrecognized parameters at Wikimedia Commons.

{"warnings":{"main":{"*":"Unrecognized parameters: {\"csp-report\":{\"blocked-uri\":\"https://tools_wmflabs_org/convert/svg2png_php\",\"document-uri\":\"https://commons_wikimedia_org/w/index_php?title, withJS."}},"cspreport":"success"}

The warning message indicates the title and withJS parameters are unknown?

See T208191. Its a known issue with HHVM. It might be fixed automatically as we move to php7 or I might write a work around patch. Note, even with the warnings, the cspreport should have been recorded just fine.

Is there a planned "target" CSP to which we should be working? Something like:

content-security-policy:
    default-src commons.wikimedia.org incubator.wikimedia.org meta.wikimedia.org login.wikimedia.org species.wikimedia.org wikimania.wikimedia.org *.wikipedia.org *.wiktionary.org *.wikisource.org *.wikibooks.org *.wikiversity.org *.wikiquote.org *.wikinews.org www.mediawiki.org www.wikidata.org *.wikivoyage.org blob: 'self';
    script-src www.mediawiki.org meta.wikimedia.org 'nonce-1234567890ABCDEF' 'strict-dynamic' 'unsafe-inline' 'self';
    style-src *.wikimedia.org 'unsafe-inline' 'self' data:;
    img-src  upload.wikimedia.org data:;
    media-src  upload.wikimedia.org;
    object-src 'none';
    base-uri 'self'