Making MediaWiki secure (and fixing some config annoyances)

(this assumes you are running Debian on your server; if not, I suggest you switch)

Mediawiki. One of the world’s less secure wikis? Probably. I use and install it a lot, and it’s usually “the compromise wiki”: it’s weak at a lot of things, but it’s the “least worst overall” a lot of the time. Here’s my current standard fixes and tweaks.

Strange, given how many people use wikis as a collaboration tool, that Mediawiki doesn’t do basic security out of the box, and has no user-options to enable any of these:

• Prevent non-image uploads (i.e. viruses, rootkits, etc)
  • Actually, I don’t have a simple fix for that one yet; but with the site locked-down to only pre-authorized users, its not quite so scary
• Require login to see the wiki content
• Encrypt passwords when people login
• Prevent anyone on planet from “giving themselves” user accounts
• Basic upload / files / viruses security

By default (with no user-configurable settings for this) it also:

• Won’t let you upload most images (!)
• Has a naive idea of what an “image file” is … based on filename(!)
• Won’t let you edit the navigation bar
• Won’t give you a link to “create new user” (even though it has this feature)

So, here’s my list of fixes that I have to re-apply manually every time I install mediawiki; I do this often enough that I’m blogging it so I can just copy/paste them next time. This is tiresome; it would be nice if they just updated it to work like other webapps and have a “config” page – and even better if it did some of these by default or as options at install time.

1. Use your webserver

Assuming you use Apache (and if not, why not?), setup a virtual hosts file to force-redirect non-SSL traffic to an SSL version of the wiki domain. This *guarantees* that *all* wiki pages can’t be snooped off-the-wire, and has the benefit of preventing any cleartext sending of passwords.

Downsides: er … only one I can think of off the top of my head is that the CPU usage / traffic will increase from using “always on” encryption. Shouldn’t even be noticeable on modern server hardware…

<VirtualHost *:80>
        ServerName wiki.securedomain.com
        ServerAdmin webmaster@localhost

        Redirect permanent / https://wiki.securedomain.com/
</VirtualHost>
<VirtualHost *:443>
        ServerName wiki.securedomain.com
        ServerAdmin webmaster@localhost

        # only these two lines and the second in the file should differ
        #   from the default site
        SSLEngine on
        SSLCertificateFile /etc/apache2/ssl/apache.pem

        DocumentRoot /var/lib/mediawiki/
        ServerSignature On

</VirtualHost>

2. Change mediawiki configfile settings

You have to edit the config files manually on your webserver – if you don’t have access to your webserver files, you’re just screwed, sorry. Well, shell-access hosting is very cheap these days ($10 a month), shouldn’t be a problem…

## Adam's default settings for LocalSettings.php

## *All* the following put together will prevent everyone on the web
## reading your data without even logging in, but will also allow your
## real users to login; don't miss any of these out, or you may be unable
## to login
$wgGroupPermissions['*']['edit'] = false;
$wgWhitelistRead = array("Special:Userlogin", "-", "MediaWiki:Monobook.css" );
$wgGroupPermissions['*']['read'] = false;
$wgGroupPermissions['*']['createaccount'] = false;

## Basic obvious default: let users get rid of the ugly
##  default GUI (sidebar, stylesheets, etc)
$wgGroupPermissions['user']['editinterface'] = true;

## Put uploads ... somewhere sensible:
$wgUploadDirectory = "{$IP}/images";
$wgUploadPath = "{$wgScriptPath}/images";

## Ah, but they have a "security" system that will allow you to upload any
## virus you want, and hack the server, BUT ... it won't let you upload most
## image files. That's just ... stupid, IMHO.
$wgStrictFileExtensions = false;

## AND you can do this (note that it is STILL active even if the above flag
## is set to false).
## I was quite horrified that they use filename extensions as a security
## mechanism - this stops some kinds of simple attack (based on tricking
## the webserver - although you SHOULD already have your webserver
## setup to prevent this; if not, why not?)
## For other attacks ... Mediawiki's approach to security
## simply DOES NOT WORK. You *must* check the content
## of files, rather than the filename.
$wgFileBlacklist = array('php','phtml','php3','php4','php5','phps');

3. Setup each user by hand

To create new users, you now need to manually go to this URL on your wiki:

/index.php/Special:UserLogin

(assuming you installed the wiki on its own domain name)

4. Some final tweaks to add missing features

AND, if you want to edit the navbar, go to: (yes, this is required: go there by hand, with the following “special” URL. It’s a terrible user-interface :( )

/index.php?title=MediaWiki:Sidebar&action=edit

…but it gets worse, because that page alone uses a special syntax (not the Wiki syntax, sadly), so that adding either of the obvious misisng links is a bit of hassle. Here’s copy/pasteable working code:

* essentials
** MediaWiki:Sidebar | edit-sidebar
** Special:UserLogin|create user

(note: they BOTH have a unique syntax due to the way mediawiki is badly designed, and the first one WILL BREAK if you use the text “sidebar” instead of “edit-sidebar” (use anything, just NOT “sidebar” on its own))

More info:
http://www.mediawiki.org/wiki/Manual:Preventing_access