Security issues with authorisation extensions
MediaWiki is not designed to be a Content Management System (CMS), or to protect sensitive data. To the contrary, it was designed to be as open as possible. Thus it does not inherently support full featured, air-tight protection of private content. But with the massive increase of MediaWiki use in corporate intranets and the many CMS-like features emerging, demand for tighter security is emerging.
To help authors of security extensions, this list of the security flaws found in the field is being maintained, so that they can test their extension against each. There are several extensions that claim to give selective read/write access to pages in Category:Page specific user rights extensions , and currently most of these do exhibit several of the listed flaws.
Testing security extensions
If you are going to implement read or write access, check the extension for the flaws listed in the table below by logging in as a user without read/write permissions. Starting a new web browsing session via incognito mode allows for site navigation as an unprivileged user as the software is tested and configured.
Table of common security extension limitations
Function/Test | Check for | Comment |
---|---|---|
Inclusion/transclusion |
|
This is partially addressed by the $wgNonincludableNamespaces setting introduced in MW 1.10 (rev:19934). You can also use manual:Hooks/BeforeParserFetchTemplateAndtitle , ParserOptions::setTemplateCallback(), ParserOptions::setCurrentRevisionCallback() but be careful of caching. |
Preloading |
|
Should be safe with extension using the UserCan hook, at least since 1.12 (maybe also earlier). |
XML export (Special:Export) |
|
For extensions using the userCan hook, this has been fixed in MW 1.10 (rev:19935).
|
Atom/RSS feeds |
|
For extensions using the userCan hook, this has been fixed in MW 1.12 (rev:25944). userCan is not honored in MW 1.14 and definitely earlier (SpecialRecentChanges*.php got moved)! RecentChanges pages lists edit comments.
|
Listings & search |
|
For extensions using the userCan hook, this has been partially addressed in MW 1.10 (rev:21821): The search page no longer shows excerpts from pages that are not readable - but it still lists the titles of articles which are not accessable to the user. |
Diff & revision links |
|
For extensions using the userCan hook, this should be OK on recent versions of MediaWiki.
|
API |
|
In modern MediaWiki, a userCan hook should get the prop=revisions case, but maybe not others
|
Action links |
|
For extensions using the userCan hook, this should be OK on recent versions of MediaWiki.
|
Related rights |
|
If using userCan , this should be OK, but might need to write ArticleInsertComplete hook for creations and TitleMoveComplete hook for moves that call userCan to 'copy' permissions.
|
Author backdoor |
|
|
Caching |
|
Limiting article caching to anonymous users might provide most of the performance benefits for sites with mostly anonymous users (like Wikipedia), without compromising security. |
Files & Images |
|
Since uploaded files are normally served directly by the web server, not through MediaWiki, it's not easily possible for extensions to prevent access. See Manual:Image Authorisation for instructions on setting up access restrictions for images. (img_auth.php uses userCan since r52751).
|
−Redirects |
|
|
Edit Section |
|
If the security relies on tags embedded in the page code then these tags will not necessarily be present in the text you are editing, even if they are present elsewhere on the page. |
Watching Pages |
|
Needs a WatchArticle hook that will call userCan .
|
Other extensions |
|
Scribunto will respect ParserOptions::setCurrentRevisionCallback revision fetching callbacks, but other extensions probably won't |
Cache pollution |
Is there any situation where a private page could get cached by MediaWiki, with the permission checked at cache time. Then later on, another user gets the cached value without the permission check being run. | |
API:REST API |
|
Activated when VisualEditor or some other extensions are activated. |
There are probably more "holes" in the read protection system. So, denying read access should be seen as a "nothing to see here, move along," sort of thing rather than a guarantee of secrecy.