Manual:セキュリティ

This page is a translated version of the page Manual:Security and the translation is 21% complete.

MediaWiki またはウィキメディアのウェブサイト群でセキュリティ上の問題を見つけたと確信したら、セキュリティをみてその内容を送り、私たちがバグ修正版を用意できるようにしてください。

Brian Wolff presents on how to secure a MediaWiki installation at EMWCon 2018

Be careful about which extensions you use

There are a wide variety of extensions available for MediaWiki. Unfortunately these extensions are also of a wide variety of quality levels. Using a low quality extension with MediaWiki is one of the most common causes of security issues for MediaWiki.

Before deciding to use an extension, you should do basic research on the extension. Extensions made by prominent members of the MediaWiki development community are usually quite safe. Similarly any extension used on a wiki run by the Wikimedia Foundation has probably been looked at carefully, and is probably safe (There are of course no guarantees). However if you find an extension floating around github that hasn't been touched in many years and was developed by someone with little experience in web development, it is probably pretty high risk.

At the end of the day, you should evaluate the security risk of installing an extension the same way you would evaluate the security risk of installing any other piece of software.

Extensions also need to be kept up to date like any other piece of software. Extensions bundled with MediaWiki have security announcements made to mediawiki-announce mailing list, but other extensions do not. Some, but definitely not all extensions announce security issues on mediawiki-l mailing list.

File permissions

Another very important thing you should do to secure your MediaWiki installation: Make sure the user running php does not have write access to any web-accessible file or directory that php is enabled to run on.

On Debian-based systems this means the www-data user should not own the php files.

On unix-like systems, you can do this by ensuring that the mediawiki directory/files are owned by someone other than your web server user (www-data) or mysql server user. Depending on how you installed MediaWiki this may already be the case, but if not can be accomplished by doing chown -R <usernamehere> /path/to/MediaWiki/ where username is a user other than the webserver or mysql user (commonly you would use your own username provided mysql and php are not running as your username). After doing that step, you may however need to change the owner of the image directory back to the php user, as uploaded files need to go there, so MediaWiki needs to be able to write there (e.g. chown -R www-data /path/to/MediaWiki/images). Next you run chmod -R go-w /path/to/MediaWiki to remove write access from all other users besides the file owners. After doing that step you may need to re-enable write access to the images directory.

Directories that MediaWiki needs write access to (such as $wgCacheDirectory if that feature is enabled) should be located outside of the web root. The exception being the images directory, which must be in the web root. However, it is important to disable php in the images directory. The details on how to do this varies with webserver, but on apache it can sometimes be accomplished by using php_flag engine off in a .htaccess file. If you do accomplish this via a config file in the images directory itself, you should ensure the config file is not writable by the webserver. See the section below on upload security for more details.

Your LocalSettings.php file must be readable by the php user, however it should not be world readable, to prevent other processes from discovering your database password and other sensitive information. Like all MediaWiki files, the php user should not be able to write to LocalSettings.php.

トランスポート層セキュリティ (TLS、HTTPS)

To protect against firesheep style attacks and general privacy leaks, it is recommended to host your site using TLS (HTTPS). A guide for setting up TLS is out of the scope of this document, however it should be noted that this is much cheaper now that letsencrypt.org provides free certificates.

If you do setup TLS, it is important to test your site with ssllabs.com/ssltest/ to ensure that it is setup properly, as it is easy to accidentally misconfigure TLS.

If you enable TLS, you may also want to configure your webserver to send the strict-transport-security header. This will improve the security of your website against eavesdroppers quite a bit, but at the drawback that it means you cannot decide to stop using TLS for a set period of time.

General PHP recommendations

Please refer to the OWASP PHP Security Cheat Sheet

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:

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() or require(). 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.

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.

For instance if you see this line in php.ini:

allow_url_fopen = On

Change it to:

allow_url_fopen = Off

Alternatively, you could add this apache directive to turn off allow_url_fopen on a per-directory basis:

php_flag allow_url_fopen 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.

General MySQL and MariaDB recommendations

In general, you should keep access to your MySQL or MariaDB 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/MariaDB'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 the database server, a mistakenly set overly broad GRANT, or a leaked password.

If you create a new MySQL/MariaDB 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.

In particular, the FILE privilege is a common cause of security issues. You should ensure that the MySQL/MariaDB user does not have this privilege or any of the "server administration" privileges.

Note that the user table in MediaWiki's database contains hashed user passwords and may contain user email addresses, and should generally be considered private data.

メンテナンススクリプト

For the maintenance scripts, you might want to create a DB-admin-user with more rights. For this, set the following variables with the database credentials of that account:

See Manual:Maintenance scripts#Configuration for details on the needed MySQL/MariaDB rights.

MediaWiki のアップグレード

During upgrade, more MySQL/MariaDB rights might be needed.

More about MySQL and MariaDB

mysql command-line options --skip-networking.
Setting bind-address=127.0.0.1 in your my.ini (under section [mysqld]) will cause MySQL/MariaDB to only listen on the loopback interface. This is the default in the EasyPHP install for Windows. (If you are using MySQL/MariaDB on a Unix machine, the setting may be skip-networking instead in the my.cnf file.)
GRANT and REVOKE syntax

MySQL/MariaDB データベースが漏洩した場合

If the 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

LocalSettings.php が漏洩した場合

If LocalSettings.php has leaked to the public, reprotect it and:

Change $wgDBpassword
Replace $wgSecretKey with a different random string of letters and numbers
Make a different $wgSpamRegex (optional)
Reset the user_token column in your user table so that it can't be used to impersonate any users

データベースのパスワード

See Manual:データベースパスワードを安全に保管するには for some precautions you may wish to take to reduce the risk of MySQL/MariaDB passwords being presented to the web.

Alternate file layout

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

Consider moving the database password or other potentially sensitive data from LocalSettings.php to another file located outside of the web document root, and including that file from LocalSettings.php (through include()). 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 authorized 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 writable by the PHP script running within your Web server. 
 */
# $wgDebugLogFile  = "c:/Logs/mediawiki/debug.log"; // Windows
$wgDebugLogFile  = "/var/log/mediawiki/{$wgSitename}-debug.log"; // Linux

Set DocumentRoot to /dev/null

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

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');

利用者のセキュリティ

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.

アップロードのセキュリティ

関連項目: Manual:ファイルのアップロードの設定

重要なことは「ユーザが悪意のあるファイルをアップロードするのをどのようにして防ぐか」ということです。

ファイルアップロードはMediaWikiのオプション機能であり、既定では無効になっています。これを有効にする場合は、ウェブサーバー実行ユーザーがウェブルートディレクトリに書き込めるようにしておく必要があります。

これはいくつかのセキュリティ上の問題と関係します:

ディレクトリが誰でも書き込みできるようになっていたり、ウェブサーバー上の限られた利用者アカウントが所有していたりするかもしれません。マルチユーザーシステムでは、他のローカルユーザーが悪意あるファイルをアップロードディレクトリに潜り込ませることができてしまいます (上記のマルチユーザーに関する注意も参照してください)。できればディレクトリはウェブサーバのアカウントだけに書き込みを許可し、誰でも書き込めるようには設定しないでください。
PHPの設定ファイルで個々のアップロードファイルの上限サイズを設定しますが、MediaWiki では全体のアップロードサイズには制限を設けません。悪意ある（または過剰な活動をする）訪問者は大量のファイルをアップロードすることによりディスクパーティションをいっぱいにできてしまいます。

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.

初期設定では、安全のためアップロードできるファイルの種類を制限しようとしています。

初期状態では、ファイルの拡張子が .png、.gif、.jpg、.jpeg、webp のファイルが許可リスト ($wgFileExtensions )に登録されています。
例え許可リスト ($wgStrictFileExtensions ) で上書きするよう設定しても、さまざまな実行ファイルやスクリプトの拡張子は拒否リスト ($wgProhibitedFileExtensions ) に明記されます。
既知の画像ファイル拡張子のいくつかについては、PHPの getimagesize() 関数を使ってファイル形式が正しいかの検証が行われます。

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.

(It has been proposed to remove this check, see T309787).

用心のため、アップロードディレクトリ（初期設定では images）については、PHPスクリプト（やその他のスクリプト類）によるサーバサイド実行は明示的に無効化しておくべきです。 You should also instruct browsers to not "sniff" files by setting a X-Content-Type-Options: nosniff header.

例えば、MediaWiki のインスタンスが /Library/MediaWiki/web にあった場合、Apache 設定ファイル (.conf ファイル) の該当箇所は以下のようになります。

<Directory "/Library/MediaWiki/web/images">
   # Ignore .htaccess files
   AllowOverride None
   
   # Serve HTML as plaintext, don't execute SHTML
   AddType text/plain .html .htm .shtml .phtml
   
   # Don't run arbitrary PHP code.
   php_admin_flag engine off

   # Tell browsers to not sniff files
   Header set X-Content-Type-Options nosniff
   
   # If you've other scripting languages, disable them too.
</Directory>

apache設定ファイルにアクセスする権限がないが、特定のディレクトリに対する設定を上書きする .htaccess ファイルが使える場合、以下のような .htaccess ファイルをアップロードディレクトリに置いてください。

# Serve HTML as plaintext, don't execute SHTML
AddType text/plain .html .htm .shtml .phtml .php .php3 .php4 .php5 .php7

# Old way of registering php with AddHandler
RemoveHandler .php

# Recent way of registering php with SetHandler
<FilesMatch "\.ph(p[3457]?s?|tml)$">
   SetHandler None
</FilesMatch>

# If you've other scripting languages, disable them too.

ぴったりな設定は人それぞれです。特に、open_basedir オプションを使うとアップロードの制御は複雑になるでしょう。

If you use any of the above solution, you can check whether it's really working with this simple test.

Create a 'test.php' file in the upload directory.
Put <?php phpinfo(); in the file.
Visit the file path in a web browser. If you see just the text of the file you are good, otherwise something is wrong somewhere.

Nginx用のPHP解決策は無効にしてください: http://serverfault.com/a/585559/162909

セキュリティ上最も良いのはアップロードファイルを別のドメインに置くことです。完全なセキュリティのためには、サブドメインではなく完全に別のドメインにアップロードさせるのが最善ですが、サブドメインであってもセキュリティの強化にはなります。 SVGファイルのアップロードを許可するのは特に重要です。なぜならこのファイル種はHTMLファイルとよく似ているからです。 MediaWiki はセキュリティのため SVG アップロードを検査しますが、複数層での防御を行っておくのが最も良い方法です。メディアファイルを異なるドメインに置くための設定を行うには $wgUploadPath を参照してください。

外部プログラム

/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 calls latex, dvips, and convert (which calls gs).

最新の状態に保つ