Thijs/wiki.techinc.nl
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
wiki.techinc.nl/tests/phpunit/includes/ContentSecurityPolicyTest.php

387 lines
22 KiB
PHP
Raw Normal View History

Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
<?php
use Wikimedia\TestingAccessWrapper;
class ContentSecurityPolicyTest extends MediaWikiTestCase {
/** @var ContentSecurityPolicy */
private $csp;
tests: Add explicit return type void to setUp() and tearDown() Bug: T192167 Depends-On: I581e54278ac5da3f4e399e33f2c7ad468bae6b43 Change-Id: I3a21fb55db76bac51afdd399cf40ed0760e4f343
2019-10-20 18:11:08 +00:00
protected function setUp() : void {
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
global $wgUploadDirectory;
$this->setMwGlobals( [
'wgAllowExternalImages' => false,
'wgAllowExternalImagesFrom' => [],
'wgAllowImageTag' => false,
'wgEnableImageWhitelist' => false,
Isolate globals for ContentSecurityPolicy tests With "$wgResourceBasePath = '/';", various ContentSecurityPolicy tests failed due to unexpected output. An extra "extensions" is added in the output line. The reason is getAdditionalSelfUrls() injecting URls from a few global settings but the test fails to set them in setUp(). The settings are: $wgLoadScript $wgExtensionAssetsPath $wgStylePath $wgResourceBasePath Set them explicitly in setUp() so the test outcome does not depend on values that might have been set in LocalSettings.php. Add a quick test to ensure getAdditionalSelfUrls() does recognize domains in those four global settings. Change-Id: Ia0dc2f44c71bdf89a0ee9ef82d9cb6a1cbd8a9da
2019-06-13 10:29:49 +00:00
'wgLoadScript' => false,
'wgExtensionAssetsPath' => false,
'wgStylePath' => false,
'wgResourceBasePath' => null,
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
'wgCrossSiteAJAXdomains' => [
'sister-site.somewhere.com',
'*.wikipedia.org',
'??.wikinews.org'
],
'wgScriptPath' => '/w',
'wgForeignFileRepos' => [ [
'class' => ForeignAPIRepo::class,
'name' => 'wikimediacommons',
'apibase' => 'https://commons.wikimedia.org/w/api.php',
'url' => 'https://upload.wikimedia.org/wikipedia/commons',
'thumbUrl' => 'https://upload.wikimedia.org/wikipedia/commons/thumb',
'hashLevels' => 2,
'transformVia404' => true,
'fetchDescription' => true,
'descriptionCacheExpiry' => 43200,
'apiThumbCacheExpiry' => 0,
'directory' => $wgUploadDirectory,
'backend' => 'wikimediacommons-backend',
] ],
Mild refactoring of ContentSecurityPolicy This is to make it behave in a more object orientied way. The goal is to make it be easier to allow extensions to mark certain pages as requiring a different policy (For example, CodeEditor extension uses a blob: url with a WebWorker. We don't want to include that on the policy of every page, but allow the extension to mark it as required whenever needed). This commit does not change code behaviour in any way. Change-Id: I4bf53dabb6e6c5446cea99a64db68b300cef2fd4
2019-10-28 05:01:17 +00:00
'wgCSPHeader' => true, // enable nonce by default
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
] );
// Note, there are some obscure globals which
// could affect the results which aren't included above.
$context = RequestContext::getMain();
$resp = $context->getRequest()->response();
$conf = $context->getConfig();
Mild refactoring of ContentSecurityPolicy This is to make it behave in a more object orientied way. The goal is to make it be easier to allow extensions to mark certain pages as requiring a different policy (For example, CodeEditor extension uses a blob: url with a WebWorker. We don't want to include that on the policy of every page, but allow the extension to mark it as required whenever needed). This commit does not change code behaviour in any way. Change-Id: I4bf53dabb6e6c5446cea99a64db68b300cef2fd4
2019-10-28 05:01:17 +00:00
$csp = new ContentSecurityPolicy( $resp, $conf );
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
$this->csp = TestingAccessWrapper::newFromObject( $csp );
Mild refactoring of ContentSecurityPolicy This is to make it behave in a more object orientied way. The goal is to make it be easier to allow extensions to mark certain pages as requiring a different policy (For example, CodeEditor extension uses a blob: url with a WebWorker. We don't want to include that on the policy of every page, but allow the extension to mark it as required whenever needed). This commit does not change code behaviour in any way. Change-Id: I4bf53dabb6e6c5446cea99a64db68b300cef2fd4
2019-10-28 05:01:17 +00:00
$this->csp->nonce = 'secret';
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
tests: Add explicit return type void to setUp() and tearDown() Bug: T192167 Depends-On: I581e54278ac5da3f4e399e33f2c7ad468bae6b43 Change-Id: I3a21fb55db76bac51afdd399cf40ed0760e4f343
2019-10-20 18:11:08 +00:00
parent::setUp();
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
}
Isolate globals for ContentSecurityPolicy tests With "$wgResourceBasePath = '/';", various ContentSecurityPolicy tests failed due to unexpected output. An extra "extensions" is added in the output line. The reason is getAdditionalSelfUrls() injecting URls from a few global settings but the test fails to set them in setUp(). The settings are: $wgLoadScript $wgExtensionAssetsPath $wgStylePath $wgResourceBasePath Set them explicitly in setUp() so the test outcome does not depend on values that might have been set in LocalSettings.php. Add a quick test to ensure getAdditionalSelfUrls() does recognize domains in those four global settings. Change-Id: Ia0dc2f44c71bdf89a0ee9ef82d9cb6a1cbd8a9da
2019-06-13 10:29:49 +00:00
/**
* @covers ContentSecurityPolicy::getAdditionalSelfUrls
*/
public function testGetAdditionalSelfUrlsRespectsUrlSettings() {
$this->setMwGlobals( 'wgLoadScript', 'https://wgLoadScript.example.org/load.php' );
$this->setMwGlobals( 'wgExtensionAssetsPath',
'https://wgExtensionAssetsPath.example.org/assets/' );
$this->setMwGlobals( 'wgStylePath', 'https://wgStylePath.example.org/style/' );
$this->setMwGlobals( 'wgResourceBasePath', 'https://wgResourceBasePath.example.org/resources/' );
$this->assertEquals(
[
'https://upload.wikimedia.org',
'https://commons.wikimedia.org',
'https://wgLoadScript.example.org',
'https://wgExtensionAssetsPath.example.org',
'https://wgStylePath.example.org',
'https://wgResourceBasePath.example.org',
],
array_values( $this->csp->getAdditionalSelfUrls() )
);
}
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
/**
* @dataProvider providerFalsePositiveBrowser
* @covers ContentSecurityPolicy::falsePositiveBrowser
*/
public function testFalsePositiveBrowser( $ua, $expected ) {
$actual = ContentSecurityPolicy::falsePositiveBrowser( $ua );
$this->assertEquals( $expected, $actual, $ua );
}
public function providerFalsePositiveBrowser() {
// @codingStandardsIgnoreStart Generic.Files.LineLength
return [
[ 'Mozilla/5.0 (X11; Linux i686; rv:41.0) Gecko/20100101 Firefox/41.0', true ],
[ 'Mozilla/5.0 (X11; U; Linux i686; en-ca) AppleWebKit/531.2+ (KHTML, like Gecko) Version/5.0 Safari/531.2+ Debian/squeeze (2.30.6-1) Epiphany/2.30.6', false ]
];
// @codingStandardsIgnoreEnd Generic.Files.LineLength
}
Allow extensions to modify CSP header on a per-page basis Adds method to the CSP object to add extra sources. This is meant so, for example, a recaptcha extension could add the recaptcha source on pages with captchas, or CodeEditor could add blob: as allowed JS sources on pages that need that (T214743). Change-Id: I68054644220cd03bc96cf8ffb9c7ee375be77f96
2019-10-28 08:51:34 +00:00
/**
* @covers ContentSecurityPolicy::addScriptSrc
* @covers ContentSecurityPolicy::makeCSPDirectives
*/
public function testAddScriptSrc() {
$this->csp->addScriptSrc( 'https://example.com:71' );
$actual = $this->csp->makeCSPDirectives( true, ContentSecurityPolicy::FULL_MODE );
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
$expected = "script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline'" .
Allow extensions to modify CSP header on a per-page basis Adds method to the CSP object to add extra sources. This is meant so, for example, a recaptcha extension could add the recaptcha source on pages with captchas, or CodeEditor could add blob: as allowed JS sources on pages that need that (T214743). Change-Id: I68054644220cd03bc96cf8ffb9c7ee375be77f96
2019-10-28 08:51:34 +00:00
" sister-site.somewhere.com *.wikipedia.org https://example.com:71; default-src *" .
Add object-src 'none' to MW CSP directive (configurable) <object> and <embed> are from a mostly bygone era. They often can be used to evade CSP rules, and are often a soft spot for browser security. The default value of 'none', disables <object>, <embed>. In some browsers this will also disable loading some file formats like pdf directly in an iframe. The only use I am aware of is in TimedMediaHandler. However, it seems like the mw.EmbedPlayerGeneric, mw.EmbedPlayerKplayer, and mw.EmbedPlayerVlc.js are no longer used. Bug: T239051 Change-Id: Iae7ab1f5b7c422803782848c787bc1a4c6339913
2020-02-17 12:10:36 +00:00
" data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri" .
Allow extensions to modify CSP header on a per-page basis Adds method to the CSP object to add extra sources. This is meant so, for example, a recaptcha extension could add the recaptcha source on pages with captchas, or CodeEditor could add blob: as allowed JS sources on pages that need that (T214743). Change-Id: I68054644220cd03bc96cf8ffb9c7ee375be77f96
2019-10-28 08:51:34 +00:00
" /w/api.php?action=cspreport&format=json";
$this->assertEquals( $expected, $actual );
}
/**
* @covers ContentSecurityPolicy::addStyleSrc
* @covers ContentSecurityPolicy::makeCSPDirectives
*/
public function testAddStyleSrc() {
$this->csp->addStyleSrc( 'style.example.com' );
$actual = $this->csp->makeCSPDirectives( true, ContentSecurityPolicy::REPORT_ONLY_MODE );
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
$expected = "script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline'" .
Allow extensions to modify CSP header on a per-page basis Adds method to the CSP object to add extra sources. This is meant so, for example, a recaptcha extension could add the recaptcha source on pages with captchas, or CodeEditor could add blob: as allowed JS sources on pages that need that (T214743). Change-Id: I68054644220cd03bc96cf8ffb9c7ee375be77f96
2019-10-28 08:51:34 +00:00
" sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:;" .
Add object-src 'none' to MW CSP directive (configurable) <object> and <embed> are from a mostly bygone era. They often can be used to evade CSP rules, and are often a soft spot for browser security. The default value of 'none', disables <object>, <embed>. In some browsers this will also disable loading some file formats like pdf directly in an iframe. The only use I am aware of is in TimedMediaHandler. However, it seems like the mw.EmbedPlayerGeneric, mw.EmbedPlayerKplayer, and mw.EmbedPlayerVlc.js are no longer used. Bug: T239051 Change-Id: Iae7ab1f5b7c422803782848c787bc1a4c6339913
2020-02-17 12:10:36 +00:00
" style-src * data: blob: style.example.com 'unsafe-inline'; object-src 'none'; report-uri" .
Allow extensions to modify CSP header on a per-page basis Adds method to the CSP object to add extra sources. This is meant so, for example, a recaptcha extension could add the recaptcha source on pages with captchas, or CodeEditor could add blob: as allowed JS sources on pages that need that (T214743). Change-Id: I68054644220cd03bc96cf8ffb9c7ee375be77f96
2019-10-28 08:51:34 +00:00
" /w/api.php?action=cspreport&format=json&reportonly=1";
$this->assertEquals( $expected, $actual );
}
/**
* @covers ContentSecurityPolicy::addDefaultSrc
* @covers ContentSecurityPolicy::makeCSPDirectives
*/
public function testAddDefaultSrc() {
$this->csp->addDefaultSrc( '*.example.com' );
$actual = $this->csp->makeCSPDirectives( true, ContentSecurityPolicy::FULL_MODE );
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
$expected = "script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline'" .
Allow extensions to modify CSP header on a per-page basis Adds method to the CSP object to add extra sources. This is meant so, for example, a recaptcha extension could add the recaptcha source on pages with captchas, or CodeEditor could add blob: as allowed JS sources on pages that need that (T214743). Change-Id: I68054644220cd03bc96cf8ffb9c7ee375be77f96
2019-10-28 08:51:34 +00:00
" sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:" .
" *.example.com; style-src * data: blob: *.example.com 'unsafe-inline';" .
Add object-src 'none' to MW CSP directive (configurable) <object> and <embed> are from a mostly bygone era. They often can be used to evade CSP rules, and are often a soft spot for browser security. The default value of 'none', disables <object>, <embed>. In some browsers this will also disable loading some file formats like pdf directly in an iframe. The only use I am aware of is in TimedMediaHandler. However, it seems like the mw.EmbedPlayerGeneric, mw.EmbedPlayerKplayer, and mw.EmbedPlayerVlc.js are no longer used. Bug: T239051 Change-Id: Iae7ab1f5b7c422803782848c787bc1a4c6339913
2020-02-17 12:10:36 +00:00
" object-src 'none'; report-uri /w/api.php?action=cspreport&format=json";
Allow extensions to modify CSP header on a per-page basis Adds method to the CSP object to add extra sources. This is meant so, for example, a recaptcha extension could add the recaptcha source on pages with captchas, or CodeEditor could add blob: as allowed JS sources on pages that need that (T214743). Change-Id: I68054644220cd03bc96cf8ffb9c7ee375be77f96
2019-10-28 08:51:34 +00:00
$this->assertEquals( $expected, $actual );
}
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
/**
* @dataProvider providerMakeCSPDirectives
* @covers ContentSecurityPolicy::makeCSPDirectives
*/
public function testMakeCSPDirectives(
$policy,
$expectedFull,
resourceloader: Give module eval the ContentSecurityPolicy nonce Previously domEval didn't have CSP nonces, causing it to violate the policy. Also removes the meta tag scheme, as I could not make it compatible with how RL storage works using domEval instead of real eval() and it didn't provide much protection anyways. Bug: T196923 Change-Id: I3cd2d7cc295c39b498d0bf37915d4ba167fdd48c
2018-07-02 06:19:43 +00:00
$expectedReport
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
) {
$actualFull = $this->csp->makeCSPDirectives( $policy, ContentSecurityPolicy::FULL_MODE );
$actualReport = $this->csp->makeCSPDirectives(
$policy, ContentSecurityPolicy::REPORT_ONLY_MODE
);
$policyJson = formatJson::encode( $policy );
$this->assertEquals( $expectedFull, $actualFull, "full: " . $policyJson );
$this->assertEquals( $expectedReport, $actualReport, "report: " . $policyJson );
}
public function providerMakeCSPDirectives() {
// @codingStandardsIgnoreStart Generic.Files.LineLength
return [
resourceloader: Give module eval the ContentSecurityPolicy nonce Previously domEval didn't have CSP nonces, causing it to violate the policy. Also removes the meta tag scheme, as I could not make it compatible with how RL storage works using domEval instead of real eval() and it didn't provide much protection anyways. Bug: T196923 Change-Id: I3cd2d7cc295c39b498d0bf37915d4ba167fdd48c
2018-07-02 06:19:43 +00:00
[ false, '', '' ],
CSP: Allow an option of disabling nonces The current rollout plan calls for initial rollout to only disallow external JS, and leave removing unsafe inline stuff to a later date. Thus this adds a useNonces option to the CSP config to allow that. Renamed ContentSecurityPolicy::isEnabled() to isNonceRequired for clarity. The old name has never been in a released version of MediaWiki, so is removed immediately. Change-Id: I756d8e97b77c6f97dbbf040a20c8750fecb157c5
2018-07-02 06:52:51 +00:00
[
[ 'useNonces' => false ],
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
"script-src 'unsafe-eval' blob: 'self' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json",
"script-src 'unsafe-eval' blob: 'self' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json&reportonly=1",
"script-src 'unsafe-eval' blob: 'self' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'"
CSP: Allow an option of disabling nonces The current rollout plan calls for initial rollout to only disallow external JS, and leave removing unsafe inline stuff to a later date. Thus this adds a useNonces option to the CSP config to allow that. Renamed ContentSecurityPolicy::isEnabled() to isNonceRequired for clarity. The old name has never been in a released version of MediaWiki, so is removed immediately. Change-Id: I756d8e97b77c6f97dbbf040a20c8750fecb157c5
2018-07-02 06:52:51 +00:00
],
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
[
true,
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json",
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json&reportonly=1",
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
],
[
[],
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json",
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json&reportonly=1",
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
],
[
[ 'script-src' => [ 'http://example.com', 'http://something,else.com' ] ],
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' http://example.com http://something%2Celse.com 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json",
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' http://example.com http://something%2Celse.com 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json&reportonly=1",
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
],
[
[ 'unsafeFallback' => false ],
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json",
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json&reportonly=1",
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
],
[
[ 'unsafeFallback' => true ],
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json",
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json&reportonly=1",
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
],
[
[ 'default-src' => false ],
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json",
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json&reportonly=1",
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
],
[
[ 'default-src' => true ],
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src 'self' data: blob: https://upload.wikimedia.org https://commons.wikimedia.org sister-site.somewhere.com *.wikipedia.org; style-src 'self' data: blob: https://upload.wikimedia.org https://commons.wikimedia.org sister-site.somewhere.com *.wikipedia.org 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json",
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src 'self' data: blob: https://upload.wikimedia.org https://commons.wikimedia.org sister-site.somewhere.com *.wikipedia.org; style-src 'self' data: blob: https://upload.wikimedia.org https://commons.wikimedia.org sister-site.somewhere.com *.wikipedia.org 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json&reportonly=1",
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
],
[
[ 'default-src' => [ 'https://foo.com', 'http://bar.com', 'baz.de' ] ],
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src 'self' data: blob: https://upload.wikimedia.org https://commons.wikimedia.org https://foo.com http://bar.com baz.de sister-site.somewhere.com *.wikipedia.org; style-src 'self' data: blob: https://upload.wikimedia.org https://commons.wikimedia.org https://foo.com http://bar.com baz.de sister-site.somewhere.com *.wikipedia.org 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json",
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src 'self' data: blob: https://upload.wikimedia.org https://commons.wikimedia.org https://foo.com http://bar.com baz.de sister-site.somewhere.com *.wikipedia.org; style-src 'self' data: blob: https://upload.wikimedia.org https://commons.wikimedia.org https://foo.com http://bar.com baz.de sister-site.somewhere.com *.wikipedia.org 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json&reportonly=1",
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
],
[
[ 'includeCORS' => false ],
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline'; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json",
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline'; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json&reportonly=1",
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
],
[
[ 'includeCORS' => false, 'default-src' => true ],
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline'; default-src 'self' data: blob: https://upload.wikimedia.org https://commons.wikimedia.org; style-src 'self' data: blob: https://upload.wikimedia.org https://commons.wikimedia.org 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json",
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline'; default-src 'self' data: blob: https://upload.wikimedia.org https://commons.wikimedia.org; style-src 'self' data: blob: https://upload.wikimedia.org https://commons.wikimedia.org 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json&reportonly=1",
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
],
[
[ 'includeCORS' => true ],
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json",
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json&reportonly=1",
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
],
[
[ 'report-uri' => false ],
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'",
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'",
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
],
[
[ 'report-uri' => true ],
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json",
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json&reportonly=1",
Add object-src 'none' to MW CSP directive (configurable) <object> and <embed> are from a mostly bygone era. They often can be used to evade CSP rules, and are often a soft spot for browser security. The default value of 'none', disables <object>, <embed>. In some browsers this will also disable loading some file formats like pdf directly in an iframe. The only use I am aware of is in TimedMediaHandler. However, it seems like the mw.EmbedPlayerGeneric, mw.EmbedPlayerKplayer, and mw.EmbedPlayerVlc.js are no longer used. Bug: T239051 Change-Id: Iae7ab1f5b7c422803782848c787bc1a4c6339913
2020-02-17 12:10:36 +00:00
],
[
[ 'report-uri' => 'https://example.com/index.php?foo;report=csp' ],
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri https://example.com/index.php?foo%3Breport=csp",
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri https://example.com/index.php?foo%3Breport=csp",
Add object-src 'none' to MW CSP directive (configurable) <object> and <embed> are from a mostly bygone era. They often can be used to evade CSP rules, and are often a soft spot for browser security. The default value of 'none', disables <object>, <embed>. In some browsers this will also disable loading some file formats like pdf directly in an iframe. The only use I am aware of is in TimedMediaHandler. However, it seems like the mw.EmbedPlayerGeneric, mw.EmbedPlayerKplayer, and mw.EmbedPlayerVlc.js are no longer used. Bug: T239051 Change-Id: Iae7ab1f5b7c422803782848c787bc1a4c6339913
2020-02-17 12:10:36 +00:00
],
[
[ 'object-src' => false ],
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; report-uri /w/api.php?action=cspreport&format=json",
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; report-uri /w/api.php?action=cspreport&format=json&reportonly=1",
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
],
[
Add object-src 'none' to MW CSP directive (configurable) <object> and <embed> are from a mostly bygone era. They often can be used to evade CSP rules, and are often a soft spot for browser security. The default value of 'none', disables <object>, <embed>. In some browsers this will also disable loading some file formats like pdf directly in an iframe. The only use I am aware of is in TimedMediaHandler. However, it seems like the mw.EmbedPlayerGeneric, mw.EmbedPlayerKplayer, and mw.EmbedPlayerVlc.js are no longer used. Bug: T239051 Change-Id: Iae7ab1f5b7c422803782848c787bc1a4c6339913
2020-02-17 12:10:36 +00:00
[ 'object-src' => true ],
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json",
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json&reportonly=1",
Add object-src 'none' to MW CSP directive (configurable) <object> and <embed> are from a mostly bygone era. They often can be used to evade CSP rules, and are often a soft spot for browser security. The default value of 'none', disables <object>, <embed>. In some browsers this will also disable loading some file formats like pdf directly in an iframe. The only use I am aware of is in TimedMediaHandler. However, it seems like the mw.EmbedPlayerGeneric, mw.EmbedPlayerKplayer, and mw.EmbedPlayerVlc.js are no longer used. Bug: T239051 Change-Id: Iae7ab1f5b7c422803782848c787bc1a4c6339913
2020-02-17 12:10:36 +00:00
],
[
[ 'object-src' => "'self'" ],
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'self'; report-uri /w/api.php?action=cspreport&format=json",
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'self'; report-uri /w/api.php?action=cspreport&format=json&reportonly=1",
Add object-src 'none' to MW CSP directive (configurable) <object> and <embed> are from a mostly bygone era. They often can be used to evade CSP rules, and are often a soft spot for browser security. The default value of 'none', disables <object>, <embed>. In some browsers this will also disable loading some file formats like pdf directly in an iframe. The only use I am aware of is in TimedMediaHandler. However, it seems like the mw.EmbedPlayerGeneric, mw.EmbedPlayerKplayer, and mw.EmbedPlayerVlc.js are no longer used. Bug: T239051 Change-Id: Iae7ab1f5b7c422803782848c787bc1a4c6339913
2020-02-17 12:10:36 +00:00
],
[
[ 'object-src' => [ "'self'", 'https://example.com/f;d' ] ],
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'self' https://example.com/f%3Bd; report-uri /w/api.php?action=cspreport&format=json",
"script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'self' https://example.com/f%3Bd; report-uri /w/api.php?action=cspreport&format=json&reportonly=1",
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
],
];
}
/**
* @covers ContentSecurityPolicy::makeCSPDirectives
*/
public function testMakeCSPDirectivesImage() {
global $wgAllowImageTag;
$origImg = wfSetVar( $wgAllowImageTag, true );
$actual = $this->csp->makeCSPDirectives( true, ContentSecurityPolicy::FULL_MODE );
$wgAllowImageTag = $origImg;
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
$expected = "script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json";
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
$this->assertEquals( $expected, $actual );
}
/**
* @covers ContentSecurityPolicy::makeCSPDirectives
*/
public function testMakeCSPDirectivesReportUri() {
$actual = $this->csp->makeCSPDirectives(
true,
ContentSecurityPolicy::REPORT_ONLY_MODE
);
include blob: as a default script-src blob: is basically a fancy version of eval(), commonly used with web workers. We currently allow eval() ('unsafe-eval'), so we might as well include blob. If we try and lock-down eval() at some later point, we can re-evaluate this decision. AFAIK, blob: urls are currently used with web workers in NavigationTiming and CodeEditor extensions. Bug: T245981 Change-Id: I3c44286e140ddfe2d3abd31428e0770ff5531e37
2020-02-24 10:10:02 +00:00
$expected = "script-src 'unsafe-eval' blob: 'self' 'nonce-secret' 'unsafe-inline' sister-site.somewhere.com *.wikipedia.org; default-src * data: blob:; style-src * data: blob: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json&reportonly=1";
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
$this->assertEquals( $expected, $actual );
// @codingStandardsIgnoreEnd Generic.Files.LineLength
}
/**
* @covers ContentSecurityPolicy::getHeaderName
*/
public function testGetHeaderName() {
$this->assertEquals(
$this->csp->getHeaderName( ContentSecurityPolicy::REPORT_ONLY_MODE ),
'Content-Security-Policy-Report-Only'
);
$this->assertEquals(
$this->csp->getHeaderName( ContentSecurityPolicy::FULL_MODE ),
'Content-Security-Policy'
);
}
/**
* @covers ContentSecurityPolicy::getReportUri
*/
public function testGetReportUri() {
$full = $this->csp->getReportUri( ContentSecurityPolicy::FULL_MODE );
Remove more HHVM hacks Change-Id: I6bd298ef3b887173b87004ee055be2a4f6ea5f11
2019-10-05 08:20:49 +00:00
$fullExpected = '/w/api.php?action=cspreport&format=json';
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
$this->assertEquals( $full, $fullExpected, 'normal report uri' );
$report = $this->csp->getReportUri( ContentSecurityPolicy::REPORT_ONLY_MODE );
Remove more HHVM hacks Change-Id: I6bd298ef3b887173b87004ee055be2a4f6ea5f11
2019-10-05 08:20:49 +00:00
$reportExpected = $fullExpected . '&reportonly=1';
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
$this->assertEquals( $report, $reportExpected, 'report only' );
global $wgScriptPath;
$origPath = wfSetVar( $wgScriptPath, '/tl;dr/a,%20wiki' );
$esc = $this->csp->getReportUri( ContentSecurityPolicy::FULL_MODE );
Remove more HHVM hacks Change-Id: I6bd298ef3b887173b87004ee055be2a4f6ea5f11
2019-10-05 08:20:49 +00:00
$escExpected = '/tl%3Bdr/a%2C%20wiki/api.php?action=cspreport&format=json';
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
$wgScriptPath = $origPath;
$this->assertEquals( $esc, $escExpected, 'test esc rules' );
}
/**
* @dataProvider providerPrepareUrlForCSP
* @covers ContentSecurityPolicy::prepareUrlForCSP
*/
public function testPrepareUrlForCSP( $url, $expected ) {
$actual = $this->csp->prepareUrlForCSP( $url );
$this->assertEquals( $actual, $expected, $url );
}
public function providerPrepareUrlForCSP() {
global $wgServer;
return [
[ $wgServer, false ],
[ 'https://example.com', 'https://example.com' ],
[ 'https://example.com:200', 'https://example.com:200' ],
[ 'http://example.com', 'http://example.com' ],
[ 'example.com', 'example.com' ],
[ '*.example.com', '*.example.com' ],
[ 'https://*.example.com', 'https://*.example.com' ],
[ '//example.com', 'example.com' ],
[ 'https://example.com/path', 'https://example.com' ],
[ 'https://example.com/path:', 'https://example.com' ],
[ 'https://example.com/Wikipedia:NPOV', 'https://example.com' ],
[ 'https://tl;dr.com', 'https://tl%3Bdr.com' ],
[ 'yes,no.com', 'yes%2Cno.com' ],
[ '/relative-url', false ],
[ '/relativeUrl:withColon', false ],
[ 'data:', 'data:' ],
[ 'blob:', 'blob:' ],
];
}
/**
* @covers ContentSecurityPolicy::escapeUrlForCSP
*/
public function testEscapeUrlForCSP() {
$escaped = $this->csp->escapeUrlForCSP( ',;%2B' );
$this->assertEquals( $escaped, '%2C%3B%2B' );
}
/**
* @dataProvider providerCSPIsEnabled
CSP: Allow an option of disabling nonces The current rollout plan calls for initial rollout to only disallow external JS, and leave removing unsafe inline stuff to a later date. Thus this adds a useNonces option to the CSP config to allow that. Renamed ContentSecurityPolicy::isEnabled() to isNonceRequired for clarity. The old name has never been in a released version of MediaWiki, so is removed immediately. Change-Id: I756d8e97b77c6f97dbbf040a20c8750fecb157c5
2018-07-02 06:52:51 +00:00
* @covers ContentSecurityPolicy::isNonceRequired
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
*/
public function testCSPIsEnabled( $main, $reportOnly, $expected ) {
CSP: In tests, use setMwGlobals() instead of manual set+undo This is the idiom as used in other PHPUnit tests for MediaWiki. Change-Id: I285e5abe57bad8b9a8a3b35d81bb3a9f5f3dbe85
2018-08-19 00:42:58 +00:00
$this->setMwGlobals( 'wgCSPReportOnlyHeader', $reportOnly );
$this->setMwGlobals( 'wgCSPHeader', $main );
CSP: Allow an option of disabling nonces The current rollout plan calls for initial rollout to only disallow external JS, and leave removing unsafe inline stuff to a later date. Thus this adds a useNonces option to the CSP config to allow that. Renamed ContentSecurityPolicy::isEnabled() to isNonceRequired for clarity. The old name has never been in a released version of MediaWiki, so is removed immediately. Change-Id: I756d8e97b77c6f97dbbf040a20c8750fecb157c5
2018-07-02 06:52:51 +00:00
$res = ContentSecurityPolicy::isNonceRequired( RequestContext::getMain()->getConfig() );
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
$this->assertEquals( $res, $expected );
}
public function providerCSPIsEnabled() {
return [
[ true, true, true ],
[ false, true, true ],
[ true, false, true ],
[ false, false, false ],
[ false, [], true ],
[ [], false, true ],
[ [ 'default-src' => [ 'foo.example.com' ] ], false, true ],
CSP: Allow an option of disabling nonces The current rollout plan calls for initial rollout to only disallow external JS, and leave removing unsafe inline stuff to a later date. Thus this adds a useNonces option to the CSP config to allow that. Renamed ContentSecurityPolicy::isEnabled() to isNonceRequired for clarity. The old name has never been in a released version of MediaWiki, so is removed immediately. Change-Id: I756d8e97b77c6f97dbbf040a20c8750fecb157c5
2018-07-02 06:52:51 +00:00
[ [ 'useNonces' => false ], [ 'useNonces' => false ], false ],
[ [ 'useNonces' => true ], [ 'useNonces' => false ], true ],
[ [ 'useNonces' => false ], [ 'useNonces' => true ], true ],
Initial support for Content Security Policy, disabled by default The primary goal here is a defense in depth measure to stop an attacker who found a bug in the parser allowing them to insert malicious attributes. This wouldn't stop someone who could insert a full script tag (since at current it can't distinguish between malicious and legit user js). It also would not prevent DOM-based or reflected XSS for anons, as the nonce value is guessable for anons when receiving a response cached by varnish. However, the limited protection of just stopping stored XSS where the attacker only has control of attributes, is still a big win in my opinion. (But it wouldn't prevent someone who has that type of xss from abusing things like data-ooui attribute). This will likely break many gadgets. Its expected that any sort of rollout on Wikimedia will be done very slowly, with lots of testing and the report-only option to begin with. This is behind feature flags that are off by default, so merging this patch should not cause any change in default behaviour. This may break some extensions (The most obvious one is charinsert (See fe648d41005), but will probably need some testing in report-only mode to see if anything else breaks) This uses the unsafe-eval option of CSP, in order to support RL's local storage thingy. For better security, we may want to remove some of the sillier uses of eval (e.g. jquery.ui.datepicker.js). For more info, see spec: https://www.w3.org/TR/CSP2/ Additionally see: https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy Bug: T135963 Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
2016-02-29 04:13:10 +00:00
];
}
}
Reference in a new issue Copy permalink