Manual:Security
- If you believe you have found a security problem in MediaWiki or in one of Wikimedia's web sites, see Security for contact information so we can prepare a bug fix release.
Contents
Stay up to date[edit | edit source]
The most important security step you can take is to keep your software up to date. Both MediaWiki and the software it depends on will occasionally produce new versions correcting newly-discovered security vulnerabilities which may affect you.
The MediaWiki developers strongly recommend that anyone running MediaWiki subscribe to the mediawiki-announce mailing list. This is a low-traffic list that sends out only new version announcements.
In accordance with MediaWiki's version lifecycle, each release will receive security updates for one year. Older releases may contain known-but-unpatched security holes.
Don't forget to also keep up with updates to Apache, PHP, MySQL, and any other software running on your servers – both the operating system and other web applications. Several people's MediaWiki 1.3.x installations were affected in Fall 2004 by a worm attacking a flaw in phpBB; once it had gotten in through other customers' unpatched phpBB sites it added a "you are hacked" message to other writable .php files on the system, including the compiled templates that MediaWiki 1.3 used.
General PHP recommendations[edit | edit source]
These bits of advice go for pretty much any PHP environment, and are not necessarily specific to MediaWiki.
PHP configuration recommendations, for php.ini or set otherwise:
- Disable
register_globals
.- Many PHP security attacks are based on injection of global variable values, so making sure it's off can make many potential vulnerabilities toothless.
- If you require
register_globals
for another web application, consider enabling it selectively, only for the virtual host or subdirectory that requires it. - MediaWiki should be safe even if this is on; turning this off is a precaution against the possibility of unknown vulnerabilities.
- Unless you require it specifically, disable
allow_url_fopen
.- Remote PHP code execution vulnerabilities may depend on being able to inject a URL into a
include()
orrequire()
. If you don't require the use of remote file loading, turning this off can prevent attacks of this kind on vulnerable code. - MediaWiki may require this setting to be on for the Lucene search extension, the OAI harvester extension, the TitleBlacklist extension, and certain uses of Special:Import in 1.5. It should not however be required in a typical installation.
- MediaWiki should be safe even if this is on; turning this off is a precaution against the possibility of unknown vulnerability.
- Remote PHP code execution vulnerabilities may depend on being able to inject a URL into a
- Set
session.use_trans_sid
off.- If this is on, session IDs may be added to URLs sometimes if cookies aren't doing their thing. That can leak login session data to third-party sites through referrer data or cut-and-paste of links.
- You should always turn this off if it's on.
Your php.ini may be located in:
- /etc/php.ini (Red Hat Linux, SuSE / Novell Linux)
- /etc/php4/apache/php.ini (Debian woody and sarge, Ubuntu 6.10 with php4 and apache 1.3)
- /etc/php5/apache2/php.ini (Ubuntu 6.10 with php5 and apache2, Debian etch)
- /etc/httpd/php.ini (Trustix Secure Linux 3.0)
- /usr/local/php/lib/php.ini (Mac OS X using Marc Liyanage's PHP package)
- /opt/local/etc/php5/php.ini (Mac OS X if using Macports)
- /Applications/MAMP/conf/php5/php.ini (Mac OS X 10.5/10.6 mit MAMP)
- /etc/apache/php.ini (Slackware 10.x), /etc/httpd/php.ini (on later Slackware versions)
- /var/www/conf/php.ini (OpenBSD)
- /usr/local/etc/php.ini (FreeBSD)
- /usr/pkg/etc/php.ini (NetBSD)
- /usr/syno/etc/php.ini (Synology NAS)
- Gentoo Linux:
- /etc/php/apache2-php4/php.ini
- /etc/php/cli-php4/php.ini
- /etc/apache2/php.ini
- c:\windows\php.ini (Windows)
For instance if you see this line in php.ini:
register_globals = On
Change it to:
register_globals = Off
Alternatively, you could add this apache directive to turn off register_globals on a per-directory basis:
php_flag register_globals off
Then restart Apache to reload the changes by apachectl reload
or rcapache2 reload
(SuSE).
On a multiuser system with PHP installed as an Apache module, all users' scripts will run under the same reduced-privilege user account. This may give other users access to read your configuration files (including database passwords), read and modify your login session data, or write files into your upload directory (if enabled).
For multiuser security, consider using a CGI/FastCGI configuration in which each user's scripts run under their own account, or enabling Safe Mode to limit script access to other users' files. Note that safe mode may interfere with some features of MediaWiki such as uploading and extensions which shell out to other programs.
General MySQL recommendations[edit | edit source]
In general, you should keep access to your MySQL database to a minimum. If it will only be used from the single machine it's running on, consider disabling networking support, or enabling local networking access only (via the loopback device, see below), so the server can only communicate with local clients over Unix domain sockets.
If it will be used over a network with a limited number of client machines, consider setting the IP firewall rules to accept access to TCP port 3306 (MySQL's port) only from those machines or only from your local subnet, and reject all accesses from the larger internet. This can help prevent accidentally opening access to your server due to some unknown flaw in MySQL, a mistakenly set overly broad GRANT, or a leaked password.
If you create a new MySQL user for MediaWiki through MediaWiki's installer, somewhat liberal access is granted to it to ensure that it will work from a second server as well as a local one. You might consider manually narrowing this or establishing the user account yourself with custom permissions from just the places you need. The database user only needs to have SELECT, INSERT, UPDATE and DELETE permissions for the database.LocalSettings.php#Security
Note that the user
table in MediaWiki's database contains hashed user passwords and may contain user e-mail addresses, and should generally be considered private data.
Maintenance scripts[edit | edit source]
For the maintenance scripts, you might want to create a DB-admin-user with more rights. For this, set the following variables with the MySQL credentials of that account:
See Manual:Maintenance scripts#Configuration for details on the needed MySQL rights.
Upgrade of MediaWiki[edit | edit source]
During upgrade, more MySQL rights might be needed.
More about MySQL[edit | edit source]
- mysql command-line options
--skip-networking
. - Setting
bind-address=127.0.0.1
in your my.ini (under section[mysqld]
) will cause MySQL to only listen on the loopback interface. This is the default in the EasyPHP install for Windows. (If you are using MySQL on a Unix machine, the setting may beskip-networking
instead in the my.cnf file.) - GRANT and REVOKE syntax
If the MySQL database has leaked[edit | edit source]
If the mysql database has leaked to the public, in LocalSettings.php:
- Change $wgDBpassword if that leaked too
- Change some letters in $wgSecretKey
- Reset the user_token column in your user table so that it can't be used to impersonate your users
Manual installation[edit | edit source]
If you use the web-based installer, you may be vulnerable to attack by somebody else running the installer on your server between the time you make the config
directory writable and the time the LocalSettings.php
file is written out.
Usually this should not be a very large risk, but if it's unacceptable to you (or if you need to do a batch install of many wikis), consider doing an installation manually:
- Create a database
- Grant user permissions. The database user only needs to have SELECT, INSERT, UPDATE and DELETE permissions for the database.LocalSettings.php#Security
- Source
maintenance/tables.sql
to create the tables. - Create a
LocalSettings.php
based on a sample or the generation code inconfig/index.php
.
AdminSettings.php
(along with supporting file AdminSettings.sample
) was removed in MediaWiki 1.16. Prior to MediaWiki 1.16, AdminSettings.php
was used to store database authentication credentials for maintenance scripts and to control the availability of profileinfo.php
. Details can still be found in Manual:AdminSettings.php.cd maintenance && php update.php
If PHP is running as an Apache module, the LocalSettings.php generated by the web installer will usually be owned by the Apache user account. To ensure that it can't be changed again by another user (see notes above about multiuser systems) or by malicious code injected to a vulnerable web application, you should reassign it to another account. (If you have only limited access, consider copying instead of moving the file; the new copy will be under your other account.)
If LocalSettings.php has leaked[edit | edit source]
If LocalSettings.php has leaked to the public, reprotect it and:
- Change $wgDBpassword
- Change some letters in $wgSecretKey
- Possibly make a slightly different $wgSpamRegex
- Reset the user_token column in your user table so that it can't be used to impersonate your users
Database passwords[edit | edit source]
See Manual:Securing database passwords for some precautions you may wish to take to reduce the risk of MySQL passwords being presented to the web.
Alternate file layout[edit | edit source]
MediaWiki is designed to run in-place after being extracted from the distribution archive. This approach is convenient, but can result in reduced security or unnecessarily duplicated files.
You avoid duplicates in a mass installation or to keep sensitive files out of the web root for safety by manually relocating or consolidating various files.
Moving the main includes and skin files may require carefully picking and choosing and altering the include_path
set in your LocalSettings.php
. Experiment with this as desired.
If working to improve security, keep in mind that WebStart.php
uses the current directory as a base. This means that only setting your include_path
may not help to improve the security of your installation.
Move sensitive information[edit | edit source]
Consider moving the database password or other potentially sensitive data from LocalSettings.php
to another file located outside of the web document root, and include()
ing that file from LocalSettings.php
. This can help to ensure that your database password will not be compromised if a web server configuration error disables PHP execution and reveals the file's source text.
Similarly, editing LocalSettings.php
with some text editors will leave a backup file in the same directory with an altered file extension, causing the copy to be served as plain text if someone requests, for example, LocalSettings.php~
. If you use such an editor, be sure to disable backup generation or move sensitive data outside the web root.
A MediaWiki debug logfile as it is used for debugging also contains sensitive data. Make sure to always disallow access for non authorised persons and the public as explained, delete remains of such logfiles when they are not needed, and comment or clear the logfile lines in your LocalSettings.php
.
/** * The debug log file should never be publicly accessible if it is used, as it * may contain private data. But it must be in a directory writeable by the * PHP script runing within your Web server. */ # $wgDebugLogFile = "c:/Program Files/Apache Group/htdocs/mediawiki/debug.log" // Windows; $wgDebugLogFile = "/tmp/{$wgSitename}-debug.log" // Linux;
Set DocumentRoot to /dev/null[edit | edit source]
A more secure option for the Apache Web Server is to set the DocumentRoot
to an empty or non-existent directory, and then use Alias
directives in the Apache configuration to expose only the scripts and directories that need to be web-accessible.
Loader scripts[edit | edit source]
A PHP-only solution that will work with any web server is to write a series of scripts that explicitly chdir()
to a specific directory and then require one or more source files. For example:
<?php chdir('/path/to/wiki'); require('./index.php');
User security[edit | edit source]
Anyone able to edit the user-interface system messages in the MediaWiki: namespace can introduce arbitrary HTML and JavaScript code into page output. This includes wiki users who have the editinterface permission, as well as anyone with direct write access to the text table in the database.
HTML is disabled on many system messages, particularly those displayed at the login screen, so the risk of password-snarfing JavaScript should be minimal. Malicious code could still attempt to exploit browser vulnerabilities (install spyware, etc), though, so, you should make sure that only trusted people can modify system messages.
Upload security[edit | edit source]
- see also → Manual:Configuring file uploads
The main concern is: How do we prevent users from uploading malicious files?
File uploads are an optional feature of MediaWiki and are disabled by default. If you enable them, you also need to provide a directory in the web root which is writable by the web server user.
This has several implications for security:
- The directory may have to be world-writable, or else owned by the web server's limited user account. On a multiuser system it may be possible for other local users to slip malicious files into your upload directory (see multiuser notes above)
- While PHP's configuration sets a file size limit on individual uploads, MediaWiki doesn't set any limit on total uploads. A malicious (or overzealous) visitor could fill up a disk partition by uploading a lot of files.
- Generated thumbnails and uploaded files held for overwrite confirmation may be kept in images/thumb and images/tmp without visible notice in the MediaWiki web interface. Keep an eye on their sizes as well.
The default configuration makes an attempt to limit the types of files which can be uploaded for safety:
- By default, file extensions .png, .gif, .jpg, and .jpeg are white listed ($wgFileExtensions).
- Various executable and script extensions are explicitly blacklisted ($wgFileBlacklist) even if you allow users to override the whitelist ($wgStrictFileExtensions).
- Several known image file extensions have their types verified using PHP's getimagesize function.
- Uploaded files are checked to see if they could trip file type detection bugs in Internet Explorer and Safari which might cause them to display as HTML.
In case these checks turn out to be insufficient, you can gain further protection by explicitly disabling server-side execution of PHP scripts (and any other scripting types you may have) in the uploads directory (by default, images
).
For instance, an Apache .conf file fragment to do this if your MediaWiki instance is in /Library/MediaWiki/web might look something like:
<Directory "/Library/MediaWiki/web/images"> # Ignore .htaccess files AllowOverride None # Serve HTML as plaintext, don't execute SHTML AddType text/plain .html .htm .shtml .php # Don't run arbitrary PHP code. php_admin_flag engine off # If you've other scripting languages, disable them too. </Directory>
Your exact configuration may vary. In particular, the use of PHP's safe mode or open_basedir options may complicate handling of uploads.
External programs[edit | edit source]
/usr/bin/diff3
may be executed for edit conflict merging.- If ImageMagick support for thumbnails or SVG images is enabled,
convert
may be run on uploaded files. - If enabled, Math extension will call
texvc
executable, which callslatex
,dvips
, andconvert
(which callsgs
).
See also[edit | edit source]
- General
- Planning/Requirements gathering
- User authorization
- Authentication
- AuthPlugin - describes plug-in architecture for determining user identity
- Manual:$wgAuth - configuration variable used by plug-in architecture
- Category:Authentication and login - authorization extensions available
- Manual:Resetting passwords - reseting a MediaWiki user's password
- Monitoring user activity
- Assignment of access rights by IP, user identity
- meta:Access control
- Manual:FAQ#Initial user was not created by installer
- Manual:FAQ#Anti-spam
- Manual:User rights - describes configuration of the default MediaWiki rights architecture
- Manual:Preventing access - various tips and how-tos
- Manual:Image Authorization - IP/user-based restrictions on access to images
- Security issues with authorization extensions
- Category:User rights extensions - extensions that assist in user rights management
- Extension:Hidden pages
- Extension:Page access restriction
- Configuration variables: $wgGroupPermissions, $wgAddGroups, $wgRemoveGroups
- Security-enhanced MediaWiki versions/sample installations
- Security alerts
- Security - how to report problems, receive notifications
- Template:Security alert
- Template:XSS alert
- Category:Extensions with XSS vulnerabilities
- ModSecurity
- Technical details
- database schema: User groups table, User table, Revision table, Recentchanges table
- hooks: UserLoginForm, UserLoginComplete, UserLogout, UserLogoutComplete, UserEffectiveGroups, UserGetImplicitGroups, UserGetRights
- code: User.php
- Manual:Special pages - instructions for designing access rights-aware special pages.
- Open Web Application Security Project (OWASP)
- Manual:MediaWiki Security Guide - for developers
Language: | English • Deutsch • Bahasa Indonesia • 日本語 • русский |
---|