Security for Mediawiki with Apache

Revision as of 18:07, 26 January 2020 by Root (talk | contribs) (Created page with "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 t...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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