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
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
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
This works around a bug in HHVM, where it treats post body as part of
request parameters, even if content-type is application/json.
See https://github.com/facebook/hhvm/issues/6676.
Change-Id: Id54d6657056dee56fc71100dedfb3b53d512eaba
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
