Jump to content

手册:安全

From mediawiki.org
This page is a translated version of the page Manual:Security and the translation is 63% complete.
Outdated translations are marked like this.
Languages:
如果你认为自己在MediaWiki或维基媒体网站中发现了安全问题，请参阅安全 以获得联系信息，以便我们修复错误。
Brain Wolff 在 EMWCon 2018 上演示了如何确保 MediaWiki 安装的安全性。

保持最新

您可以采取的最重要的安全措施是使您的软件保持最新， MediaWiki和它的依赖的软件偶尔会发布新版本，修复新发现的安全漏洞，这些漏洞可能会影响到您。

MediaWiki开发人员强烈建议任何运行MediaWiki的人订阅mediawiki-announce邮件列表， 这是一个低流量列表，仅发送新版本公告。

根据MediaWiki的版本生命周期，每个版本将获得一年的安全更新。较旧的版本可能包含已知但未修补的安全漏洞。 旧版本可能包含已知但未修补的安全漏洞。

不要忘记及时升级 Apache、PHP、MySQL/MariaDB 以及其他运行在服务器上的软件，包括操作系统和其他应用程序。

请注意您使用了哪些扩展

有许多不同类型的扩展可用于MediaWiki。不幸的是，这些扩展的质量水平也各不相同。在MediaWiki中使用低质量的扩展是导致安全问题最常见的原因之一。

在决定使用扩展之前，您应该对该扩展进行基本研究。 通常情况下，由MediaWiki开发社区的知名成员开发的扩展是相当安全的。 同样，任何在由维基媒体基金会运营的维基上使用的扩展都可能经过仔细审查，也可能是安全的（当然，这没有任何保证）。 然而，如果你在 Github 上找到一个很久都没有更新过且由一个经验不足的 Web 开发者开发的扩展程序，那么它很可能存在较高的风险。

最终，你应该以与安装任何其他软件相同的方式评估安装扩展的安全风险。

扩展程序和其他软件一样需要及时更新。MediaWiki捆绑的扩展程序会在mediawiki-announce邮件列表中发布安全公告，但其他扩展程序则没有。其中一些扩展程序会在mediawiki-l邮件列表上公布安全问题，但肯定不是所有扩展程序都会这样做。

文件权限

另一个非常重要的事情，你应该做的是保护你的MediaWiki安装：确保运行php的用户没有写入权限到任何php能够运行的可访问的文件或目录。

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

在类Unix系统上，您可以通过确保mediawiki目录/文件的所有者不是您的Web服务器用户（www-data）或MySQL服务器用户来实现此目的。 根据你安装MediaWiki的方式，这可能已经实现了。如果没有，可以通过chown -R <usernamehere> /path/to/MediaWiki/来完成，其中用户名是除了web服务器或mysql用户以外的用户（通常情况下，如果mysql和php不是以你的用户名运行，你会使用自己的用户名）。 完成这一步骤后，你可能需要将图像目录的所有者改回php用户，因为上传的文件需要放在那里，所以MediaWiki需要能够在那里写入（例如chown -R www-data /path/to/MediaWiki/images）。 接下来，您需要运行chmod -R go-w /path/to/MediaWiki，以删除除文件所有者以外的所有其他用户的写访问权限。完成此步骤后，您可能需要重新启用图像目录的写访问权限。

MediaWiki需要写入访问权限的目录（例如启用了$wgCacheDirectory功能的目录）应该位于网站根目录之外。 例外是图片目录，它必须在网站根目录下。 然而，重要的是要在图像目录中禁用php运行。 如何完成这个任务的细节因Web服务器而异，在Apache上，有时可以通过在.htaccess文件中使用php_flag engine off来实现。 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）

为了防范类似firesheep的攻击和保护隐私泄露，建议启用TLS（HTTPS）来托管您的网站。 本文档不包括设置TLS的指南，但应该注意到现在使用letsencrypt.org提供的免费证书会便宜很多。

如果你设置了TLS，重要的是使用ssllabs.com/ssltest/测试你的网站以确保它已正确设置，因为意外地配置错误TLS很容易发生。

如果启用了TLS，您可能还想配置您的Web服务器发送strict-transport-security头。 这将大大提高你的网站针对窃听者的防护，但缺点是你不能决定在一段时间内停止使用TLS。

通用的PHP建议

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:

    • 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.
    • 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

然后将其改为： 

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

升级期间可能需要更多的MySQL/MariaDB权限。

關於MySQL和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

If the MySQL or MariaDB database has leaked

If the database has leaked to the public, in LocalSettings.php:

  1. Change $wgDBpassword if that leaked too
  2. 改變一些在$wgSecretKey 裡面的字母
  3. Set $wgAuthenticationTokenVersion to an unpredictable value to ensure that user_token values in your database can't be used to impersonate your users


If LocalSettings.php has leaked

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

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

数据库密碼

请参阅手册:保护数据库密码 ，以了解您可能希望采取的一些预防措施，以减少MySQL/MariaDB密码被呈现到网络的风险。

替代文件布局

MediaWiki 被设计为在从分发压缩包中提取后就地运行。这种方法很方便，但会导致安全性降低或不必要的文件重复。

为了安全起见，您可以通过手动重定位或合并各种文件来避免批量安装中的重复文件或将敏感文件保留在 Web 根目录之外。

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.

如果要提高安全性，请记住 WebStart.php 使用当前目录作为基础。这意味着仅设置 include_path 可能无助于提高安装的安全性。

移动敏感信息

考虑将数据库密码或其他潜在敏感数据从 LocalSettings.php 移动到位于 Web 文档根目录之外的另一个文件，并将该文件嵌入在 LocalSettings.php（通过 include()）。 如果 Web 服务器配置错误禁用 PHP 执行并显示文件的源文本，这有助于确保您的数据库密码不会泄露。

同样，用一些文本编辑器编辑 LocalSettings.php 会在同一目录下留下一个文件扩展名被改变的备份文件，例如 LocalSettings.php~；如果有人请求，会导致该副本被当作纯文本提供。 如果您使用这样的编辑器，请务必禁用备份生成或将敏感数据移出 Web 根目录。

MediaWiki 调试日志文件也包含敏感数据。 确保始终按照说明禁止非授权人员和公众访问，在不需要时删除此类日志文件的剩余部分，并注释或清除 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 certain system messages in the MediaWiki: namespace can introduce arbitrary JavaScript and CSS code into page output. This includes wiki users who have the editsitejs/editsitecss permissions, as well as anyone with direct write access to the text table in the database.

These are mostly disabled 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.

上传安全

参见： 手册:配置文件上传

主要关注的问题是：我们如何防止用户上传恶意文件？

文件上传是 MediaWiki 的可选功能，默认情况下是禁用的。如果启用它们，您还需要在 Web 根目录中创建一个 Web 服务器用户可写的目录。

这可能会牵扯出几个安全隐患：

  • 这个目录可能会被设置为所有人可写，或者只被 Web 服务器指定的用户帐户拥有。在多用户系统中，其它本地用户可能会将恶意软件偷偷放入你的上传目录。（见上述多用户说明。） 请尽量将目录设置为 Web 服务器用户可写，不要设置为所有人可写。
  • 虽然 PHP 的配置限制了可以上传的单个文件大小，MediaWiki 并没有对总上传设置任何限制。恶意用户（或者过于热心的用户）可能会上传大量的文件填满硬盘空间。
  • 生成的缩略图和上传的用于覆盖确认的文件可能会保存在 images/thumb 和 images/tmp 目录中，而不会在 MediaWiki 中显式通知。最好注意它们的大小。

默认配置会限制可以上传的文件类型以确保安全：

  • 默认设置下，png、gif、jpg、jpeg 和 webp 类型的文件会在白名单列表（$wgFileExtensions ）。
  • 各种可执行文件和脚本扩展被明确列入黑名单（$wgProhibitedFileExtensions ），即使您允许用户覆盖白名单（$wgStrictFileExtensions ）。
  • 几个已知的图像文件扩展名使用 PHP 的 getimagesize() 函数验证了它们的类型。
  • 上传的文件已被检查，确保不会遇到 Internet Explorer 和 Safari 中的文件类型检测错误，这可能导致它们显示为 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 选项可能会使上传处理复杂化。

如果您使用上述任何一种解决方案，您可以通过这个简单的测试来检查它是否真的有效。

  • 在上传目录中创建一个“test.php”文件。
  • 将 <?php phpinfo(); 放入文件中。
  • 在网络浏览器中访问文件路径。 如果您只看到文件的文本，则配置正确；否则配置某处有问题。

在 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.
  • This list is incomplete.

You can use Shellbox to provide a more locked-down running environment for external commands.

参见

Retrieved from "https://www.mediawiki.org/w/index.php?title=Manual:Security/zh&oldid=6872182"