Last modified: 2013-10-06 18:59:28 UTC
Coming in Firefox 4 "Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks." "Enabling CSP is as easy as configuring your web server to return the X-Content-Security-Policy HTTP header." Example of change required: " * User Agents MUST block: o The contents of internal <script> nodes o javascript: URIs, e.g. <a href="javascript:bad_stuff()"> (unless enabled by policy) o Event-handling attributes, e.g. <a onclick="bad_stuff()"> * User Agents MUST NOT block: o Scripts imported from external files whose sources are allowed by the protected document's policy AND are served with a Content-Type of application/javascript or application/json. " https://developer.mozilla.org/en/Introducing_Content_Security_Policy https://wiki.mozilla.org/Security/CSP/Specification https://wiki.mozilla.org/Security/CSP/Specification#Base_Restrictions Jumping on the band wagon: phpMyAdmin http://www.phpmyadmin.net/documentation/changelog.php "+ [core] Include Content Security Policy HTTP headers." MantisBT bugtracking http://www.mantisbt.org/blog/?p=119 "As Firefox 4 has been pushed back to early 2011 we have more time to finish off the implementation of X-Content-Security-Policy within MantisBT."
Blocking JS url's would break stuff, if not in core, definitely in userscripts. Well it'd be nice if we didn't use html event handler attributes, many extensions still do (many extensions also probably use eval). Most of this stuff probably wouldn't be too useful, but some of it possibly might. Restricting what places the scripts can come from might be interesting (easy way to stop naive admins from including scripts from third parties). But one would have to be careful not to break things. People include scripts from other wikimedia projects and so on.
Adding Tim to see if he has any input on this security-related issue.
The first step is to remove all JavaScript that is embedded into the HTML output by the MediaWiki core via inline script-tags or "on"-attributes. Most inline javascript is created while the HTML page is rendered and contains data that is specific to the current page. This data can be stored in data-attributes for HTML 5 and attributes in a non-html namespace for XHTML. Once the MediaWiki core supports CSP, there could be a user option to enable unsave scripting. And a function for extensions to add unsave-inline, unsave-eval or urls to the whitelist. At the beginning of this year -when this feature request was made- only Firefox supported CSP. But among Webkit based browsers, even the latest preview of Internet Explorer 10 supports it now. The current draft of the specification is at: https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html
Hopefully not too off-topic: with "X-Content-Security-Policy: allow 'self'" set on the server, the "Vector" skin is not rendered correctly any more - but only in Firefox (no plugins loaded); Safari/Chrome/Opera are fine: http://nerdbynature.de/bits/mw-26508/ Not sure if this is a problem with Firefox or something Mediawiki will have to fix.
Looks like it's considering data: image uris to not be permitted.
Apparently you'd need to use a header like: X-Content-Security-Policy: allow 'self'; img-src 'self' data: to allow data urls. But we also have inline js in vector skin that from my understanding won't get along with this.
FWIW, I took the setting from the (out-of-date) https://people.mozilla.com/~bsterne/content-security-policy/details.html#examples, where it was described as "Site wants all content to come from its own domain". @Bawolff: yes, the setting you mentioned helps!
For those interested in CSP I put together a starting CSP branch: https://github.com/dantman/mediawiki-core/compare/master...csp It uses a proper api. It's got the starting for whitelisting ResourceLoader stuff. But it could use more work through core adding whitelists for images included in the parser output (ideally both local and foreign whitelisting). I also haven't checked if anything we have relies on eval() which would require some extra metadata to tell the CSP code that it should allow eval() in the page.
Another CSP warning, MW 1.19.1, Firefox 13.0: ----------- Timestamp: 6/21/12 01:37:49 Warning: CSP: Directive "inline script base restriction" violated Source File: https://foo.example.com/wiki/Test Line: 23 Source Code: if(window.mw){ mw.config.set({"wgCanonic... ----------- The warning is issued when a table with "class=sortable" is used and the sort-buttons are not displayed in Firefox. Setting X-Content-Security-Policy to "allow 'self'; options inline-script; img-src 'self' data:", makes the warning disappear and the sort-buttons are displayed.
Firefox & Chrome both have CSP enabled now. A single page load (6k article) gives multiple errors, here's how Chrome articulates this: --- times reported, per page | v 6 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'style-src' was not explicitly set, so 'default-src' is used as a fallback. 6 Refused to execute inline script because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'script-src' was not explicitly set, so 'default-src' is used as a fallback. 11 Refused to load the image 'xxx' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'img-src' was not explicitly set, so 'default-src' is used as a fallback. So, we have 23 CSP violations on a single page. Without a special CSP header for the mediawiki installation, these resources are NOT loaded and the wiki page looks not really pretty. To make these warnings go away, the following CSP would be necessary: "default-src 'self'; img-src 'self' data:; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'", But especially these "unsafe-inline" statemtents are not recommended. So, what can we do about this?
