Security for Mediawiki with Apache

A flaw was recently found in the way files were handled that could compromise the security of this site. It's been corrected, so there is no risk in disclosing it. In fact there's a good reason for disclosing it. And that is to possibly point out a flaw in how other people may handle the security for their Mediawiki website. Assuming someone else does something similar to what was done on this site. So what was done?

What was done...

Whenever a new version of Mediawiki is released, the version of this website is upgraded too. Well, eventually. As part of that upgrade process, backups are made of the database and website files. Inevitably extensions need to be upgraded too. One other item that seems like it should be an important part of the upgrade process is the LocalSettings.php file. After all, if new functionality is being introduced or an existing setting has been changed for security reasons, or really anything else one could think of, then there might be changes to the LocalSettings.php file. It's an issue because there are custom settings (database info, etc.) in that file, plus any custom settings (extensions added, default behavior changes, etc.).

The method used on this site has always been to generate a new "stock / virgin" LocalSettings.php and look for differences. Side recommendation here: It's always a good idea to keep changes, custom additions, etc. separate from the "stock / virgin" settings. The methodology used on this site is to comment out any variables whose default values are changed and then add them to the bottom of the file. If one forgets to comment out a variable, the last one in the file takes precedence. Also put custom additions (like extensions) at the end. Never intermingle changes / custom additions with the "stock / virgin" settings. That way if there are any additional settings included with an upgrade, they'll be in the new LocalSettings.php file. Oh, and lots of comments. Always put in lots of comments so if you go back later and look at something, you'll know why it was done that way.

So what's the flaw mentioned earlier?

Well as part of the effort in getting everything working with an upgraded version of the Mediawiki software there seem to be slight changes that need to be made to customized settings that are added to the file. For instance, if an older extension that isn't compatible with a newer version of Mediawiki because the developer hasn't release a new version and it has to be disabled. That means erasing or commenting out the added settings in the LocalSettings.php file for that extension. Or, sometimes instead of completely commenting out an item, its value needs to be changed slightly. There are lots of reasons. During this phase of testing / getting everything to work, it is sometimes worth while to have multiple copies of the LocalSettings.php file with different names. This allows them to be swapped out when testing different settings. Once everything is work, there is sometimes a trail of LocalSettings.php files like this: LocalSettings.php.SiteHosed, LocalSettings.php.MostlyWorking, LocalSettings.php.XisBroken, LocalSettings.php.XisFixed-NowYisBroken, LocalSettings.php.MaybeItWillWorkOnTheNextUpgrade, etc. Sometimes those files get left behind by mistake or even on purpose (there's lots of good reason).

Flaw Revealed

It seems obvious in hind site, but wasn't considered until just recently. Those LocalSettings.php.RENAMED files contain some important information, including the database name, password, etc. If someone guessed the name of one of those files, they could be read. We found some circumstances (not saying how) where even if a file ended in .php and displayed a blank page when viewed, still had source code that could be read. Not good.

The Solution?

Fix it with Apache (HTTPD) settings.

Frustrating Issue

One frustrating issue that again seems obvious in hind site was a bit difficult to figure out.

The Issue

Redirects were not working. Specifically, this site conforms to the Mediawiki "best practices" of having not having the wiki in the root folder of a website. IE, our URL is https://Wiki.TerraBase.info/wiki, not https://Wiki.TerraBase.info. Prior to these "security upgrades", via Apache configuration changes, if someone entered Wiki.TerraBase.info into their browser, it would redirect to https://Wiki.TerraBase.info/wiki. But it didn't work after the security settings were tightened up.

What Doesn't Work?

Well, without laboriously explaining it, how about an example? The below results in a "forbidden" error and redirect does not work if someone types in Wiki.TerraBase.info as the URL (the redirect.html and redirect.php files contain code that redirects to https://Wiki.TerraBase.info);

DocumentRoot		/var/www/html/WhatEverDirectory
DirectoryIndex		redirect.html redirect.php index.php
Alias			/wiki /var/www/html/WhatEverDirectory

<Files "redirect.html">
	Require all granted
</Files>

<Files "redirect.php">
	Require all granted
</Files>

<Directory "/var/www/html/WhatEverDirectory">
	AllowOverride ALL
	Require all denied
</Directory>

<Location "/wiki">
			AllowOverride ALL
			Require all granted	
</Location>

Why Doesn't it Work?

Again, the answer seemed obvious in hind site. It was the end of the "forbidden" error message that indicated the solution. The error message said this file was forbidden: / (a forward slash). But that wasn't completely true as the / (forward slash) is there no matter what file or path is forbidden, so adding the below code didn't fix the issue;

<Files "/">
	Require all granted
</Files>

And again, it seems obvious in hind site that the above code wouldn't work because a / (forward slash) is not a file. It's a separator / division between directories or directories and files. So how can it be fixed? What comes after the / (forward slash). Answer: Nothing. And that's how the issue was solved.

<Files "">
			Require all granted
</Files>

It seems completely illogical when one states the above code out loud: Allow access to nothing for everyone. But everyone knows there are concepts like null, blank, etc. that have valid values in programming, even though it makes no sense in the real world. So the conclusion on that is: Don't think about how things are supposed to be logical in the "real world", think about how they really are.

Final Salt in the Wound

Try searching for this on Google: "<Files "">" (Sorry, escaping the inner two double quotation marks next to each other with nothing in between a \ (backslash) won't work as Google doesn't seem to support regular expressions). Wow, those few characters are impossible to find via Google.

Out of curiosity a search on Google for: "" (double quotation marks next to each other with nothing in between) has ZERO results. So that means this web page must be the first in the world to do this: "" Searching for: double quotation marks next to each other, returned a picture of Dr. Evil in Austin Powers. It just got worse from there. Until going to Bing that is. And then it just got stupid.

This subject probably deserves its own article. But the problem is, no one could find it if they searched for it.

What else is hidden like that. One things for sure, you won't know until you don't find it (which again, only applies in the computer programming world, not in the real world).