Manual:Security/zh


 * 如果你认为自己在MediaWiki或维基媒体网站中发现了安全问题，请参阅以获得联系信息，以便我们修复错误. 



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

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

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

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

在2004年秋季，一些人的MediaWiki 1.3.x安装受到了蠕虫病毒的影响，该病毒利用phpBB的漏洞进行攻击. 一旦通过其他用户未修补的phpBB网站进入系统，它就会向其他可写的.php文件添加“你已被黑客入侵”的消息，包括MediaWiki 1.3使用的编译模板.



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

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

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

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



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

On Debian-based systems this means the  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 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. ). Next you run  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  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.

Transport Layer Security (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  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 or set otherwise:


 * Unless you require it specifically, disable.
 * Remote PHP code execution vulnerabilities may depend on being able to inject a URL into a  or  . 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.
 * 設置  為 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

然后将其改为：

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



關於MySQL和MariaDB的更多

 * mysql command-line options.
 * Setting  in your my.ini (under section  ) 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   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  if that leaked too
 * 2) 改變一些在裡面的字母
 * 3) Reset the user_token column in your user table so that it 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
 * 2) Replace  with a different random string of letters and numbers
 * 3) Make a different  (optional)
 * 4) Reset the user_token column in your user table so that it can't be used to impersonate any users



数据库密碼
See for some precautions you may wish to take to reduce the risk of MySQL/MariaDB passwords being presented to the web.



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

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

Moving the main includes and skin files may require carefully picking and choosing and altering the  set in your. Experiment with this as desired.

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



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

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

MediaWiki 调试日志文件也包含敏感数据. 确保始终按照说明禁止非授权人员和公众访问，在不需要时删除此类日志文件的剩余部分，并注释或清除  中的日志文件行.

Set DocumentRoot to /dev/null
A more secure option for the Apache Web Server is to set the  to an empty or non-existent directory, and then use   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  to a specific directory and then require one or more source files. For example:



用户脚本
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.



上传安全

 * 参见：

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

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

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


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

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


 * 默认设置下，png、gif、jpg、jpeg 和 webp 类型的文件会在白名单列表（）.
 * 各种可执行文件和脚本扩展被明确列入黑名单（），即使您允许用户覆盖白名单（）.
 * 几个已知的图像文件扩展名使用 PHP 的 函数验证了它们的类型.
 * 上传的文件已被检查，确保不会遇到 Internet Explorer 和 Safari 中的文件类型检测错误，这可能导致它们显示为 HTML. (It has been proposed to remove this check, see T309787).

作为预防措施，您应该在上传目录（默认情况下为 ）中明确禁用服务器端执行 PHP 脚本（以及可能的任何其他脚本类型）. You should also instruct browsers to not "sniff" files by setting a  header.

例如，如果您的 MediaWiki 实例位于 /Library/MediaWiki/web 中，执行此操作的 Apache .conf 文件片段可能类似于：

如果您无权访问 Apache 配置文件，可以使用 .htaccess 文件覆盖特定目录的配置设置——将 .htaccess 文件放在上传目录中，如下所示：

您的确切配置可能会有所不同. 特别是，使用 选项可能会使上传处理复杂化.

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


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

在 Nginx 上禁用 PHP 的解决方案： http://serverfault.com/a/585559/162909

为了获得最佳安全性，您还应该考虑为上传的文件使用单独的域. 为了完全安全，最好从一个完全独立的域而不是子域提供上传服务，但即使是子域也会提供额外的安全性. 如果您允许上传 SVG 文件，这一点尤其重要，因为该文件格式与 HTML 非常相似. MediaWiki 检查 SVG 上传的安全性，但最好有多层防御. 请参阅 以配置不同的域来提供媒体文件.



外部链接

 * may be executed for edit conflict merging.
 * If ImageMagick support for thumbnails or SVG images is enabled,  may be run on uploaded files.
 * If enabled, Math extension will call  executable, which calls ,  , and   (which calls  ).



参见

 *  General 
 * Configuration Settings: Access
 * meta:Category:MediaWiki authentication
 *  Planning/Requirements gathering 
 *  User authorization 
 * AuthManager - describes plug-in architecture for determining user identity
 * - configuration variable used by plug-in architecture
 * - authorization extensions available
 * - reseting a MediaWiki user's password
 *  Monitoring user activity 
 *  Assignment of access rights by IP, user identity 
 * Access control
 * FAQ/Initial user was not created by installer
 * FAQ/Anti-spam
 * - describes configuration of the default MediaWiki rights architecture
 * - various tips and how-to guides
 * - IP/user-based restrictions on access to images
 * - extensions that assist in user rights management
 * Configuration variables:, , ,
 *  Security-enhanced MediaWiki versions/sample installations 
 *  Security alerts 
 * - how to report problems, receive notifications
 * ModSecurity
 *  Technical details 
 * database schema: User groups table, User table, Revision table, Recentchanges table
 * hooks:, , , ,
 * code:
 * - instructions for designing access rights-aware special pages.
 *  Open Web Application Security Project (OWASP) 
 *  Web Application Security - Modsecurity Rules (WAS) 
 *  - for developers
 * ModSecurity
 *  Technical details 
 * database schema: User groups table, User table, Revision table, Recentchanges table
 * hooks:, , , ,
 * code:
 * - instructions for designing access rights-aware special pages.
 *  Open Web Application Security Project (OWASP) 
 *  Web Application Security - Modsecurity Rules (WAS) 
 *  - for developers