Improving the security of our users on Wikimedia sites

Translate this post
Wikimedia Foundation teamed up with iSEC Partners and the Open Technology Fund to assess the security of our sites and protect the privacy of our users. Image by Woodennature, freely licensed under CC BY-SA 3.0.

Wikimedia Foundation teamed up with iSEC Partners and the Open Technology Fund to assess the security of our sites and protect the privacy of our users. Image by Woodennature, freely licensed under CC BY-SA 3.0.
The Wikimedia Foundation is committed to keeping our users safe when they contribute and view content on Wikipedia and Wikimedia projects. This requires us to ensure that MediaWiki, the open-source software that powers our sites, is working as intended, protecting the safety and privacy of our users. To that end, we have been working with iSEC Partners, a respected security firm with a strong reputation for assessing applications security.
Today we’re publishing the Application Penetration Test report, performed by iSEC Partners this past December (download the full report PDF here). During this assessment, their security engineers developed attacks against the current version of MediaWiki. They did this by assessing the source code and launching attacks against a virtual environment that we configured for them — mimicking the way MediaWiki runs on our sites.
This assessment was sponsored by the Open Technology Fund (OTF), an organization established in 2012 to support freedom of information on the Internet. The OTF determined that the Wikimedia projects aligned with their mission, and saw an opportunity to collaborate on improving the security and privacy of users on Wikimedia sites.
The OTF’s Red Team Lab sponsors security audits of Internet freedom projects by third-party partners, such as iSEC Partners. As a consumer of many open-source applications and tools, many of which clearly had little security oversight, the Wikimedia Foundation is thrilled that the OTF is providing this much-needed service in a critical area. They deserve a small truckload of barnstars for their effort.

Why are we doing this?

Recent security bugs like Shellshock and Heartbleed have shown that it’s not enough for open-source projects to have lots of users looking at their code to prevent security issues, projects need regular audits specifically looking for security issues. Both security bugs had significant vulnerabilities that were not discovered for several years.
This assessment identified several specific issues for us to address. Going forward, we hope that regular assessments from third-party organizations will allow us to measure the effectiveness of our security process.

What did we learn?

• Although most of the issues identified by iSEC were new flaws, there were two issues that were previously known, but fixes weren’t completed. Additionally, planned hardening countermeasures would have prevented one of the issues from being exploitable in the WMF environment. We’re hiring on our Wikimedia Security Team to ensure we can address issues faster in the future.
• In another case, we had specifically tested for a vulnerability previously, and although the MediaWiki code hadn’t changed much since we tested for the vulnerability, changes to the underlying platform and libraries caused subtle changes in functionality that we relied on. This highlighted for us the need for continuous security regression testing, as part of our QA process. We plan to adopt this in the near future.
• This assessment also reinforced the uniqueness of the information security challenges that the WMF faces. For example, where common security guidelines recommend hiding the usernames of privileged accounts so an external attacker might not be able to target their attacks to accounts with specific privileges, the WMF relies on this type of transparency for our community to function. This means that MediaWiki truly can’t rely on any “security through obscurity” tactics, and instead must rely on strong security fundamentals. We take this challenge to do things the right way seriously, and hope to inspire other organizations to do the same.


Huge thanks to Chad Hurley at the OTF for believing in our mission, and coordinating this valuable service for us. Thanks also to Valentin Leon, Justin Engler, David Thiel, and Tom Ritter from iSEC Partners for a professional and thorough review, and for taking time during their holiday schedules to make freely sharing in the sum of all knowledge a little safer for everyone.
Chris Steipp
Security Engineer
Wikimedia Foundation

Archive notice: This is an archived post from, which operated under different editorial and content guidelines than Diff.

Can you help us translate this article?

In order for this article to reach as many people as possible we would like your help. Can you translate this article to get the message out?

Inline Feedbacks
View all comments

Please get rid of nonfree Javascript code! LibreJS blocks part of the website. Proprietary code is inherently insecure because the community at large cannot audit the code.

Our js is free (all mediawiki code is gplv2 or something compatible). However it is difficult to annotate it with license information the way that librejs wants due to how the js is dynamically combined and generated (although i note that it seems librejs now supports inline annotation comments which might work better for us. It didnt support that last time I looked at it)

The review appears to have been restricted to purely technical vulnerabilities. What actions are planned to examine socio-technical issues such as insider threat, abuse of advanced privilieges and social engineering and their management by such means as internal audit, verification and behavioural pattern analysis?