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

397 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
Hooks::run() call site migration Migrate all callers of Hooks::run() to use the new HookContainer/HookRunner system. General principles: * Use DI if it is already used. We're not changing the way state is managed in this patch. * HookContainer is always injected, not HookRunner. HookContainer is a service, it's a more generic interface, it is the only thing that provides isRegistered() which is needed in some cases, and a HookRunner can be efficiently constructed from it (confirmed by benchmark). Because HookContainer is needed for object construction, it is also needed by all factories. * "Ask your friendly local base class". Big hierarchies like SpecialPage and ApiBase have getHookContainer() and getHookRunner() methods in the base class, and classes that extend that base class are not expected to know or care where the base class gets its HookContainer from. * ProtectedHookAccessorTrait provides protected getHookContainer() and getHookRunner() methods, getting them from the global service container. The point of this is to ease migration to DI by ensuring that call sites ask their local friendly base class rather than getting a HookRunner from the service container directly. * Private $this->hookRunner. In some smaller classes where accessor methods did not seem warranted, there is a private HookRunner property which is accessed directly. Very rarely (two cases), there is a protected property, for consistency with code that conventionally assumes protected=private, but in cases where the class might actually be overridden, a protected accessor is preferred over a protected property. * The last resort: Hooks::runner(). Mostly for static, file-scope and global code. In a few cases it was used for objects with broken construction schemes, out of horror or laziness. Constructors with new required arguments: * AuthManager * BadFileLookup * BlockManager * ClassicInterwikiLookup * ContentHandlerFactory * ContentSecurityPolicy * DefaultOptionsManager * DerivedPageDataUpdater * FullSearchResultWidget * HtmlCacheUpdater * LanguageFactory * LanguageNameUtils * LinkRenderer * LinkRendererFactory * LocalisationCache * MagicWordFactory * MessageCache * NamespaceInfo * PageEditStash * PageHandlerFactory * PageUpdater * ParserFactory * PermissionManager * RevisionStore * RevisionStoreFactory * SearchEngineConfig * SearchEngineFactory * SearchFormWidget * SearchNearMatcher * SessionBackend * SpecialPageFactory * UserNameUtils * UserOptionsManager * WatchedItemQueryService * WatchedItemStore Constructors with new optional arguments: * DefaultPreferencesFactory * Language * LinkHolderArray * MovePage * Parser * ParserCache * PasswordReset * Router setHookContainer() now required after construction: * AuthenticationProvider * ResourceLoaderModule * SearchEngine Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
2020-03-19 02:42:09 +00:00
use MediaWiki\MediaWikiServices;
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
use Wikimedia\TestingAccessWrapper;
MediaWikiTestCase to MediaWikiIntegrationTestCase The name change happened some time ago, and I think its about time to start using the name name! (Done with a find and replace) My personal motivation for doing this is that I have started trying out vscode as an IDE for mediawiki development, and right now it doesn't appear to handle php aliases very well or at all. Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
2020-06-30 15:09:24 +00:00
class ContentSecurityPolicyTest extends MediaWikiIntegrationTestCase {
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
/** @var ContentSecurityPolicy */
private $csp;
build: Updating dependencies composer: * mediawiki/mediawiki-codesniffer: 36.0.0 → 37.0.0 The following sniffs now pass and were enabled: * Generic.ControlStructures.InlineControlStructure * MediaWiki.PHPUnit.AssertCount.NotUsed npm: * svgo: 2.3.0 → 2.3.1 * https://npmjs.com/advisories/1754 (CVE-2021-33587) Change-Id: I2a9bbee2fecbf7259876d335f565ece4b3622426
2021-07-22 03:11:47 +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;
More misc test cleanup * parent::setUp() should be first, and ::tearDown() should be last * Move tests that directly extend PHPUnit\Framework\TestCase to /unit Change-Id: I1172855c58f4f52a8f624e6d596ec43beb8c93ff
2020-12-23 10:03:34 +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
$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();
Hooks::run() call site migration Migrate all callers of Hooks::run() to use the new HookContainer/HookRunner system. General principles: * Use DI if it is already used. We're not changing the way state is managed in this patch. * HookContainer is always injected, not HookRunner. HookContainer is a service, it's a more generic interface, it is the only thing that provides isRegistered() which is needed in some cases, and a HookRunner can be efficiently constructed from it (confirmed by benchmark). Because HookContainer is needed for object construction, it is also needed by all factories. * "Ask your friendly local base class". Big hierarchies like SpecialPage and ApiBase have getHookContainer() and getHookRunner() methods in the base class, and classes that extend that base class are not expected to know or care where the base class gets its HookContainer from. * ProtectedHookAccessorTrait provides protected getHookContainer() and getHookRunner() methods, getting them from the global service container. The point of this is to ease migration to DI by ensuring that call sites ask their local friendly base class rather than getting a HookRunner from the service container directly. * Private $this->hookRunner. In some smaller classes where accessor methods did not seem warranted, there is a private HookRunner property which is accessed directly. Very rarely (two cases), there is a protected property, for consistency with code that conventionally assumes protected=private, but in cases where the class might actually be overridden, a protected accessor is preferred over a protected property. * The last resort: Hooks::runner(). Mostly for static, file-scope and global code. In a few cases it was used for objects with broken construction schemes, out of horror or laziness. Constructors with new required arguments: * AuthManager * BadFileLookup * BlockManager * ClassicInterwikiLookup * ContentHandlerFactory * ContentSecurityPolicy * DefaultOptionsManager * DerivedPageDataUpdater * FullSearchResultWidget * HtmlCacheUpdater * LanguageFactory * LanguageNameUtils * LinkRenderer * LinkRendererFactory * LocalisationCache * MagicWordFactory * MessageCache * NamespaceInfo * PageEditStash * PageHandlerFactory * PageUpdater * ParserFactory * PermissionManager * RevisionStore * RevisionStoreFactory * SearchEngineConfig * SearchEngineFactory * SearchFormWidget * SearchNearMatcher * SessionBackend * SpecialPageFactory * UserNameUtils * UserOptionsManager * WatchedItemQueryService * WatchedItemStore Constructors with new optional arguments: * DefaultPreferencesFactory * Language * LinkHolderArray * MovePage * Parser * ParserCache * PasswordReset * Router setHookContainer() now required after construction: * AuthenticationProvider * ResourceLoaderModule * SearchEngine Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
2020-03-19 02:42:09 +00:00
$hookContainer = MediaWikiServices::getInstance()->getHookContainer();
$csp = new ContentSecurityPolicy( $resp, $conf, $hookContainer );
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
}
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 );
Fix inverted assertions in ContentSecurityPolicyTest Note that some (not all) of these are flipped, listing the expected value second. I guess this is because it's like this in QUnit. This patch also replaces loose assertEquals() checks with the more strict assertSame(), which should be preferred when comparing strings. Change-Id: I5bb27a6b63ab1642fab60483647d6b663100b144
2020-05-14 17:23:37 +00:00
$this->assertSame( $expected, $actual, $ua );
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 providerFalsePositiveBrowser() {
return [
Fix inverted assertions in ContentSecurityPolicyTest Note that some (not all) of these are flipped, listing the expected value second. I guess this is because it's like this in QUnit. This patch also replaces loose assertEquals() checks with the more strict assertSame(), which should be preferred when comparing strings. Change-Id: I5bb27a6b63ab1642fab60483647d6b663100b144
2020-05-14 17:23:37 +00:00
[
'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
],
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
];
}
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";
Fix inverted assertions in ContentSecurityPolicyTest Note that some (not all) of these are flipped, listing the expected value second. I guess this is because it's like this in QUnit. This patch also replaces loose assertEquals() checks with the more strict assertSame(), which should be preferred when comparing strings. Change-Id: I5bb27a6b63ab1642fab60483647d6b663100b144
2020-05-14 17:23:37 +00:00
$this->assertSame( $expected, $actual );
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::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";
Fix inverted assertions in ContentSecurityPolicyTest Note that some (not all) of these are flipped, listing the expected value second. I guess this is because it's like this in QUnit. This patch also replaces loose assertEquals() checks with the more strict assertSame(), which should be preferred when comparing strings. Change-Id: I5bb27a6b63ab1642fab60483647d6b663100b144
2020-05-14 17:23:37 +00:00
$this->assertSame( $expected, $actual );
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::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";
Fix inverted assertions in ContentSecurityPolicyTest Note that some (not all) of these are flipped, listing the expected value second. I guess this is because it's like this in QUnit. This patch also replaces loose assertEquals() checks with the more strict assertSame(), which should be preferred when comparing strings. Change-Id: I5bb27a6b63ab1642fab60483647d6b663100b144
2020-05-14 17:23:37 +00:00
$this->assertSame( $expected, $actual );
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
}
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
);
Fix a plethora of class and function call case mismatches Bug: T231412 Change-Id: I597a25de3294a6673424f30475760280ef209a8a
2020-05-26 13:14:46 +00:00
$policyJson = FormatJson::encode( $policy );
Fix inverted assertions in ContentSecurityPolicyTest Note that some (not all) of these are flipped, listing the expected value second. I guess this is because it's like this in QUnit. This patch also replaces loose assertEquals() checks with the more strict assertSame(), which should be preferred when comparing strings. Change-Id: I5bb27a6b63ab1642fab60483647d6b663100b144
2020-05-14 17:23:37 +00:00
$this->assertSame( $expectedFull, $actualFull, "full: " . $policyJson );
$this->assertSame( $expectedReport, $actualReport, "report: " . $policyJson );
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 providerMakeCSPDirectives() {
build: Swap deprecated @codingStandardsIgnore to phpcs:ignore Bug: T278594 Change-Id: I09a6175917090593e6e0055203a890c32bea03a5
2021-04-04 19:18:22 +00:00
// phpcs:disable Generic.Files.LineLength
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
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",
Cleanup mixed space/tab line indent Change-Id: I833052a656b1ce419c0929f6f0514f2a33c2c4cc
2021-09-03 22:52:31 +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
[
[ '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
],
];
build: Swap deprecated @codingStandardsIgnore to phpcs:ignore Bug: T278594 Change-Id: I09a6175917090593e6e0055203a890c32bea03a5
2021-04-04 19:18:22 +00:00
// phpcs:enable
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;
build: Swap deprecated @codingStandardsIgnore to phpcs:ignore Bug: T278594 Change-Id: I09a6175917090593e6e0055203a890c32bea03a5
2021-04-04 19:18:22 +00:00
// phpcs:ignore Generic.Files.LineLength
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";
Fix inverted assertions in ContentSecurityPolicyTest Note that some (not all) of these are flipped, listing the expected value second. I guess this is because it's like this in QUnit. This patch also replaces loose assertEquals() checks with the more strict assertSame(), which should be preferred when comparing strings. Change-Id: I5bb27a6b63ab1642fab60483647d6b663100b144
2020-05-14 17:23:37 +00:00
$this->assertSame( $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
}
/**
* @covers ContentSecurityPolicy::makeCSPDirectives
*/
public function testMakeCSPDirectivesReportUri() {
$actual = $this->csp->makeCSPDirectives(
true,
ContentSecurityPolicy::REPORT_ONLY_MODE
);
build: Swap deprecated @codingStandardsIgnore to phpcs:ignore Bug: T278594 Change-Id: I09a6175917090593e6e0055203a890c32bea03a5
2021-04-04 19:18:22 +00:00
// phpcs:ignore Generic.Files.LineLength
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";
Fix inverted assertions in ContentSecurityPolicyTest Note that some (not all) of these are flipped, listing the expected value second. I guess this is because it's like this in QUnit. This patch also replaces loose assertEquals() checks with the more strict assertSame(), which should be preferred when comparing strings. Change-Id: I5bb27a6b63ab1642fab60483647d6b663100b144
2020-05-14 17:23:37 +00:00
$this->assertSame( $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
}
/**
* @covers ContentSecurityPolicy::getHeaderName
*/
public function testGetHeaderName() {
Fix inverted assertions in ContentSecurityPolicyTest Note that some (not all) of these are flipped, listing the expected value second. I guess this is because it's like this in QUnit. This patch also replaces loose assertEquals() checks with the more strict assertSame(), which should be preferred when comparing strings. Change-Id: I5bb27a6b63ab1642fab60483647d6b663100b144
2020-05-14 17:23:37 +00:00
$this->assertSame(
'Content-Security-Policy-Report-Only',
$this->csp->getHeaderName( ContentSecurityPolicy::REPORT_ONLY_MODE )
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
);
Fix inverted assertions in ContentSecurityPolicyTest Note that some (not all) of these are flipped, listing the expected value second. I guess this is because it's like this in QUnit. This patch also replaces loose assertEquals() checks with the more strict assertSame(), which should be preferred when comparing strings. Change-Id: I5bb27a6b63ab1642fab60483647d6b663100b144
2020-05-14 17:23:37 +00:00
$this->assertSame(
'Content-Security-Policy',
$this->csp->getHeaderName( ContentSecurityPolicy::FULL_MODE )
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::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';
Fix inverted assertions in ContentSecurityPolicyTest Note that some (not all) of these are flipped, listing the expected value second. I guess this is because it's like this in QUnit. This patch also replaces loose assertEquals() checks with the more strict assertSame(), which should be preferred when comparing strings. Change-Id: I5bb27a6b63ab1642fab60483647d6b663100b144
2020-05-14 17:23:37 +00:00
$this->assertSame( $fullExpected, $full, 'normal report uri' );
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 = $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';
Fix inverted assertions in ContentSecurityPolicyTest Note that some (not all) of these are flipped, listing the expected value second. I guess this is because it's like this in QUnit. This patch also replaces loose assertEquals() checks with the more strict assertSame(), which should be preferred when comparing strings. Change-Id: I5bb27a6b63ab1642fab60483647d6b663100b144
2020-05-14 17:23:37 +00:00
$this->assertSame( $reportExpected, $report, 'report only' );
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 $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;
Fix inverted assertions in ContentSecurityPolicyTest Note that some (not all) of these are flipped, listing the expected value second. I guess this is because it's like this in QUnit. This patch also replaces loose assertEquals() checks with the more strict assertSame(), which should be preferred when comparing strings. Change-Id: I5bb27a6b63ab1642fab60483647d6b663100b144
2020-05-14 17:23:37 +00:00
$this->assertSame( $escExpected, $esc, 'test esc rules' );
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 providerPrepareUrlForCSP
* @covers ContentSecurityPolicy::prepareUrlForCSP
*/
public function testPrepareUrlForCSP( $url, $expected ) {
$actual = $this->csp->prepareUrlForCSP( $url );
Fix inverted assertions in ContentSecurityPolicyTest Note that some (not all) of these are flipped, listing the expected value second. I guess this is because it's like this in QUnit. This patch also replaces loose assertEquals() checks with the more strict assertSame(), which should be preferred when comparing strings. Change-Id: I5bb27a6b63ab1642fab60483647d6b663100b144
2020-05-14 17:23:37 +00:00
$this->assertSame( $expected, $actual, $url );
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 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' );
Fix inverted assertions in ContentSecurityPolicyTest Note that some (not all) of these are flipped, listing the expected value second. I guess this is because it's like this in QUnit. This patch also replaces loose assertEquals() checks with the more strict assertSame(), which should be preferred when comparing strings. Change-Id: I5bb27a6b63ab1642fab60483647d6b663100b144
2020-05-14 17:23:37 +00:00
$this->assertSame( '%2C%3B%2B', $escaped );
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 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() );
Fix inverted assertions in ContentSecurityPolicyTest Note that some (not all) of these are flipped, listing the expected value second. I guess this is because it's like this in QUnit. This patch also replaces loose assertEquals() checks with the more strict assertSame(), which should be preferred when comparing strings. Change-Id: I5bb27a6b63ab1642fab60483647d6b663100b144
2020-05-14 17:23:37 +00:00
$this->assertSame( $expected, $res );
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 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