View source for Manual:Security/id

<languages />
:'''Jika Anda yakin telah menemukan masalah keamanan di MediaWiki atau di salah satu situs web Wikimedia, lihat {{ll|Security}} untuk informasi kontak sehingga kami dapat menyiapkan rilis perbaikan bug.'''
[[File:Securing MediaWiki Installation - EMWCon 2018.webm|thumb|Brian Wolff mempresentasikan tentang cara mengamankan instalasi MediaWiki di EMWCon 2018]]
<span id="Stay_up_to_date"></span>
== Tetap terkini ==
Langkah keamanan terpenting yang dapat Anda lakukan adalah selalu memperbarui perangkat lunak Anda.
<span lang="en" dir="ltr" class="mw-content-ltr">Both MediaWiki and the software it depends on will occasionally produce new versions correcting newly-discovered security vulnerabilities which may affect you.</span>

<span lang="en" dir="ltr" class="mw-content-ltr">The MediaWiki developers strongly recommend that anyone running MediaWiki subscribe to the [[mail:mediawiki-announce|mediawiki-announce mailing list]].</span>
<span lang="en" dir="ltr" class="mw-content-ltr">This is a low-traffic list that sends out only new version announcements.</span>

<span lang="en" dir="ltr" class="mw-content-ltr">In accordance with MediaWiki's [[Special:MyLanguage/Version lifecycle|version lifecycle]], each release will receive security updates for one year.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">Older releases may contain known-but-unpatched security holes.</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
Don't forget to also keep up with updates to Apache, PHP, MySQL/MariaDB, and any other software running on your servers &ndash; both the operating system and other web applications.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<span id="Be_careful_about_which_extensions_you_use"></span>
== Berhati-hatilah dengan ekstensi yang Anda gunakan ==

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<span lang="en" dir="ltr" class="mw-content-ltr">Before deciding to use an extension, you should do basic research on the extension.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">Extensions made by prominent members of the MediaWiki development community are usually quite safe.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">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).</span>
<span lang="en" dir="ltr" class="mw-content-ltr">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.</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<span id="File_permissions"></span>
== Izin file ==

<div lang="en" dir="ltr" class="mw-content-ltr">
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.''
</div>

<span lang="en" dir="ltr" class="mw-content-ltr">On Debian-based systems this means the <code>www-data</code> user '''should not''' own the php files.</span>

<span lang="en" dir="ltr" class="mw-content-ltr">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.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">Depending on how you installed MediaWiki this may already be the case, but if not can be accomplished by doing {{tmpl|0=<code>chown -R &lt;$1> /path/to/MediaWiki/</code>|usernamehere}} 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).</span>
<span lang="en" dir="ltr" class="mw-content-ltr">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. <code>chown -R www-data /path/to/MediaWiki/images</code>).</span>
<span lang="en" dir="ltr" class="mw-content-ltr">Next you run <code>chmod -R go-w /path/to/MediaWiki</code> 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.</span>

<span lang="en" dir="ltr" class="mw-content-ltr">Directories that MediaWiki needs write access to (such as $wgCacheDirectory if that feature is enabled) should be located outside of the web root.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">The exception being the images directory, which must be in the web root.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">However, it is important to disable php in the images directory.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">The details on how to do this varies with webserver, but on apache it can sometimes be accomplished by using <code>php_flag engine off</code> in a .htaccess file.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">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.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">See the section below on upload security for more details.</span>

<span lang="en" dir="ltr" class="mw-content-ltr">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.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">Like all MediaWiki files, the php user should not be able to write to LocalSettings.php.</span>

<span id="Transport_Layer_Security_(TLS,_HTTPS)"></span>
== Keamanan Lapisan Transportasi (TLS, HTTPS) ==
<span lang="en" dir="ltr" class="mw-content-ltr">To protect against [[w:firesheep|firesheep]] style attacks and general privacy leaks, it is recommended to host your site using TLS (HTTPS).</span>
<span lang="en" dir="ltr" class="mw-content-ltr">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 [https://letsencrypt.org letsencrypt.org] provides free certificates.</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you do setup TLS, it is important to test your site with [https://www.ssllabs.com/ssltest/ ssllabs.com/ssltest/] to ensure that it is setup properly, as it is easy to accidentally misconfigure TLS.
</div>

<span lang="en" dir="ltr" class="mw-content-ltr">If you enable TLS, you may also want to configure your webserver to send the <code>strict-transport-security</code> header.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">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.</span>

<span id="General_PHP_recommendations"></span>
== Rekomendasi umum PHP ==

:''Silakan merujuk ke OWASP [https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet Lembar Cheat Keamanan PHP]''

<div lang="en" dir="ltr" class="mw-content-ltr">
These bits of advice go for pretty much any PHP environment, and are not necessarily specific to MediaWiki.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
PHP configuration recommendations, for {{ll|Manual:Php.ini|php.ini}} or set otherwise:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* Unless you require it specifically, disable <code>{{php-ini|allow_url_fopen}}</code>.
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
** Remote PHP code execution vulnerabilities may depend on being able to inject a URL into a {{phpi|include()}} or {{phpi|require()}}. If you don't require the use of remote file loading, turning this off can prevent attacks of this kind on vulnerable code.
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
** 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.
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
** MediaWiki should be safe even if this is on; turning this off is a precaution against the possibility of unknown vulnerability.
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
* Set <code>{{php-ini|session.use_trans_sid}}</code> off.
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
** 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.
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
** You should always turn this off if it's on.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For instance if you see this line in php.ini:
</div>

 allow_url_fopen = On

<div lang="en" dir="ltr" class="mw-content-ltr">
Change it to:
</div>

 allow_url_fopen = Off

<div lang="en" dir="ltr" class="mw-content-ltr">
Alternatively, you could add this apache directive to turn off allow_url_fopen on a per-directory basis:
</div>

 php_flag allow_url_fopen off

<div lang="en" dir="ltr" class="mw-content-ltr">
Then restart Apache to reload the changes by <code>apachectl reload</code> or <code>rcapache2 reload</code> (SuSE).
</div>

<span lang="en" dir="ltr" class="mw-content-ltr">On a multiuser system with PHP installed as an Apache module, all users' scripts will run under the same reduced-privilege user account.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">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).</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
For multiuser security, consider using a CGI/FastCGI configuration in which each user's scripts run under their own account.
</div>

{{anchor|General MySQL recommendations}}
<div lang="en" dir="ltr" class="mw-content-ltr">
== General MySQL and MariaDB recommendations ==
</div>
<span lang="en" dir="ltr" class="mw-content-ltr">In general, you should keep access to your MySQL or MariaDB database to a minimum.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">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.</span>

<span lang="en" dir="ltr" class="mw-content-ltr">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.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">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.</span>

<span lang="en" dir="ltr" class="mw-content-ltr">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.</span> <span lang="en" dir="ltr" class="mw-content-ltr">You might consider manually narrowing this or establishing the user account yourself with custom permissions from just the places you need.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">The database user only needs to have SELECT, INSERT, UPDATE and DELETE permissions for the database.</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
In particular, the [https://dev.mysql.com/doc/refman/5.7/en/privileges-provided.html#priv_file 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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Note that the <code>user</code> table in MediaWiki's database contains hashed user passwords and may contain user email addresses, and should generally be considered private data.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
=== Maintenance scripts ===
</div>
<span lang="en" dir="ltr" class="mw-content-ltr">For the [[Special:MyLanguage/Manual:Maintenance scripts|maintenance scripts]], you might want to create a DB-admin-user with more rights.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">For this, set the following variables with the database credentials of that account:</span>

* {{ll|Manual:$wgDBadminuser}}
* {{ll|Manual:$wgDBadminpassword}}

<div lang="en" dir="ltr" class="mw-content-ltr">
See [[Special:MyLanguage/Manual:Maintenance scripts#Configuration|Manual:Maintenance scripts#Configuration]] for details on the needed MySQL/MariaDB rights.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
=== Upgrade of MediaWiki ===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
During upgrade, more MySQL/MariaDB rights might be needed.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
=== More about MySQL and MariaDB===
</div>
* [http://dev.mysql.com/doc/mysql/en/server-options.html mysql command-line options]  <code>--skip-networking</code>.
* <span lang="en" dir="ltr" class="mw-content-ltr">Setting <code>bind-address=127.0.0.1</code> in your my.ini (under section <code>[mysqld]</code>) will cause MySQL/MariaDB to only listen on the loopback interface.</span> <span lang="en" dir="ltr" class="mw-content-ltr">This is the default in the EasyPHP install for Windows. (If you are using MySQL/MariaDB on a Unix machine, the setting may be <code>skip-networking</code> instead in the my.cnf file.)</span>
* [http://dev.mysql.com/doc/mysql/en/grant.html <span lang="en" dir="ltr" class="mw-content-ltr">GRANT and REVOKE syntax</span>]

<div lang="en" dir="ltr" class="mw-content-ltr">
===If the MySQL or MariaDB database has leaked===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If the database has leaked to the public, in LocalSettings.php:
</div>

# <span lang="en" dir="ltr" class="mw-content-ltr">Change {{ll|Manual:$wgDBpassword|$wgDBpassword}} if that leaked too</span>
# <span lang="en" dir="ltr" class="mw-content-ltr">Change some letters in {{ll|Manual:$wgSecretKey|$wgSecretKey}}</span>
# <span lang="en" dir="ltr" class="mw-content-ltr">[[Special:MyLanguage/Manual:ResetUserTokens.php|Reset the user_token column]] in your user table so that it can't be used to impersonate your users</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
=== If LocalSettings.php has leaked ===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If LocalSettings.php has leaked to the public, reprotect it and:
</div>

# <span lang="en" dir="ltr" class="mw-content-ltr">Change {{ll|Manual:$wgDBpassword|$wgDBpassword}}</span>
# <span lang="en" dir="ltr" class="mw-content-ltr">Replace {{ll|Manual:$wgSecretKey|$wgSecretKey}} with a different random string of letters and numbers</span>
# <span lang="en" dir="ltr" class="mw-content-ltr">Make a different {{ll|Manual:$wgSpamRegex|$wgSpamRegex}} (optional)</span>
# <span lang="en" dir="ltr" class="mw-content-ltr">Reset the user_token column in your user table so that it can't be used to impersonate any users</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Database passwords ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
See {{ll|Manual:Securing database passwords}} for some precautions you may wish to take to reduce the risk of MySQL/MariaDB passwords being presented to the web.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Alternate file layout ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Moving the main includes and skin files may require carefully picking and choosing and altering the <code>include_path</code> set in your <code>LocalSettings.php</code>.  Experiment with this as desired.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If working to improve security, keep in mind that <code>{{ll|Manual:WebStart.php|WebStart.php}}</code> uses the current directory as a base. This means that only setting your <code>include_path</code> may not help to improve the security of your installation.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
=== Move sensitive information ===
</div>
<span lang="en" dir="ltr" class="mw-content-ltr">Consider moving the database password or other potentially sensitive data from <code>{{ll|Manual:LocalSettings.php|LocalSettings.php}}</code> to another file located outside of the web document root, and including that file from <code>LocalSettings.php</code> (through <code>include()</code>).</span>
<span lang="en" dir="ltr" class="mw-content-ltr">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.</span>

<span lang="en" dir="ltr" class="mw-content-ltr">Similarly, editing <code>LocalSettings.php</code> 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, <code>LocalSettings.php~</code>.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">If you use such an editor, be sure to disable backup generation or move sensitive data outside the web root.</span>

<span lang="en" dir="ltr" class="mw-content-ltr">A MediaWiki [[Special:MyLanguage/Manual:How to debug#Logging|debug logfile]] as it is used for debugging also contains sensitive data.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">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 <code>LocalSettings.php</code>.</span>

<syntaxhighlight lang="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
</syntaxhighlight>

<div lang="en" dir="ltr" class="mw-content-ltr">
=== Set DocumentRoot to /dev/null ===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
A more secure option for the Apache Web Server is to set the <code>DocumentRoot</code> to an empty or non-existent directory, and then use <code>Alias</code> directives in the Apache configuration to expose only the scripts and directories that need to be web-accessible.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
=== Loader scripts ===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
A PHP-only solution that will work with any web server is to write a series of scripts that explicitly <code>chdir()</code> to a specific directory and then require one or more source files. For example:
</div>

<syntaxhighlight lang="php">
<?php
chdir('/path/to/wiki');
require('./index.php');
</syntaxhighlight>

<div lang="en" dir="ltr" class="mw-content-ltr">
== User security ==
</div>
<span lang="en" dir="ltr" class="mw-content-ltr">Anyone able to edit the user-interface [[Special:MyLanguage/Help:System message|system messages]] in the MediaWiki: namespace can introduce arbitrary HTML and JavaScript code into page output.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">This includes wiki users who have the ''editinterface'' permission, as well as anyone with direct write access to the text table in the database.</span>

<span lang="en" dir="ltr" class="mw-content-ltr">HTML is disabled on many system messages, particularly those displayed at the login screen, so the risk of password-snarfing JavaScript should be minimal.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">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.</span>

{{anchor|Upload security}}
<div lang="en" dir="ltr" class="mw-content-ltr">
== Upload security ==
</div>
: <span lang="en" dir="ltr" class="mw-content-ltr">See also:</span> {{ll|Manual:Configuring file uploads}}

<div lang="en" dir="ltr" class="mw-content-ltr">
The main concern is: How do we prevent users from uploading malicious files?
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This has several implications for security:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* 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).
</div> <span lang="en" dir="ltr" class="mw-content-ltr">If at all possible, make the directory writable only by the web server's account, don't make the directory world-writable.</span>
<div lang="en" dir="ltr" class="mw-content-ltr">
* 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.
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
* 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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The default configuration makes an attempt to limit the types of files which can be uploaded for safety:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* By default, file extensions .png, .gif, .jpg, .jpeg and webp are white listed ({{ll|Manual:$wgFileExtensions|$wgFileExtensions}}).
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
* Various executable and script extensions are explicitly prohibited ({{ll|Manual:$wgProhibitedFileExtensions|$wgProhibitedFileExtensions}}) even if you allow users to override the allowlist ({{ll|Manual:$wgStrictFileExtensions|$wgStrictFileExtensions}}).
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
* Several known image file extensions have their types verified using PHP's {{php|getimagesize}} function.
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
* 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.
</div> <span lang="en" dir="ltr" class="mw-content-ltr">(It has been proposed to remove this check, see [[phab:T309787|T309787]]).</span>

<span lang="en" dir="ltr" class="mw-content-ltr">As a precaution, you should explicitly disable server-side execution of PHP scripts (and any other scripting types you may have) in the uploads directory (by default, <code>images</code>).</span>
<span lang="en" dir="ltr" class="mw-content-ltr">You should also instruct browsers to not "sniff" files by setting a <code>X-Content-Type-Options: nosniff</code> header.</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
For instance, an Apache .conf file fragment to do this if your MediaWiki instance is in /Library/MediaWiki/web might look something like:
</div>

<syntaxhighlight lang="apache">
<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>
</syntaxhighlight>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you don't have access to apache configuration files, but you can use <kbd>.htaccess</kbd> files to override configuration settings on specific directories, you can put an <kbd>.htaccess</kbd> file on the upload directory that looks like this:
</div>

<syntaxhighlight lang="apache">
# 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.
</syntaxhighlight>

<div lang="en" dir="ltr" class="mw-content-ltr">
Your exact configuration may vary. In particular, the use of {{php-ini|open_basedir}} options may complicate handling of uploads.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you use any of the above solution, you can check whether it's really working with this simple test.
</div> 

* <span lang="en" dir="ltr" class="mw-content-ltr">Create a 'test.php' file in the upload directory.</span>
* <span lang="en" dir="ltr" class="mw-content-ltr">Put <syntaxhighlight lang=html inline><?php phpinfo();</syntaxhighlight> in the file.</span>
* <span lang="en" dir="ltr" class="mw-content-ltr">Visit the file path in a web browser.</span> <span lang="en" dir="ltr" class="mw-content-ltr">If you see just the text of the file you are good, otherwise something is wrong somewhere.</span>

'''<span lang="en" dir="ltr" class="mw-content-ltr">Disable PHP solution for Nginx:</span>'''
http://serverfault.com/a/585559/162909

<span lang="en" dir="ltr" class="mw-content-ltr">For best security, you should also consider using a separate domain for uploaded files.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">For full security it is best to have uploads served from an entirely separate domain, not a subdomain, but even a subdomain will provide additional security.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">This is especially important if you allow uploading SVG files since that file format is so similar to HTML.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">MediaWiki checks SVG uploads for security, but it is best to have multiple layers of defense.</span>
<span lang="en" dir="ltr" class="mw-content-ltr">See {{ll|Manual:$wgUploadPath|$wgUploadPath}} for configuring a different domain to serve media files.</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
== External programs ==
</div>
* <span lang="en" dir="ltr" class="mw-content-ltr"><code>/usr/bin/diff3</code> may be executed for edit conflict merging.</span>
* <span lang="en" dir="ltr" class="mw-content-ltr">If ImageMagick support for thumbnails or SVG images is enabled, <code>convert</code> may be run on uploaded files.</span>
* <span lang="en" dir="ltr" class="mw-content-ltr">If enabled, [[Special:MyLanguage/Extension:Math|Math extension]] will call <code>texvc</code> executable, which calls <code>latex</code>, <code>dvips</code>, and <code>convert</code> (which calls <code>gs</code>).</span>

<div lang="en" dir="ltr" class="mw-content-ltr">
==See also==
</div>
* '''<span lang="en" dir="ltr" class="mw-content-ltr">General</span>'''
** {{ll|Category:User access extensions}}
** <span lang="en" dir="ltr" class="mw-content-ltr">[[Special:MyLanguage/Manual:Configuration settings#Access|Configuration Settings: Access]]</span>
** [[meta:Category:MediaWiki authentication]]
* '''<span lang="en" dir="ltr" class="mw-content-ltr">Planning/Requirements gathering</span>'''
** {{ll|Manual:Installation requirements}}
* '''<span lang="en" dir="ltr" class="mw-content-ltr">User authorization</span>'''
** [[AuthManager]] - <span lang="en" dir="ltr" class="mw-content-ltr">describes plug-in architecture for determining user identity</span>
** {{ll|Manual:$wgAuthManagerConfig}} - <span lang="en" dir="ltr" class="mw-content-ltr">configuration variable used by plug-in architecture</span>
** {{ll|Category:Authentication and login}} - <span lang="en" dir="ltr" class="mw-content-ltr">authorization extensions available</span>
** {{ll|Manual:Resetting passwords}} - <span lang="en" dir="ltr" class="mw-content-ltr">reseting a MediaWiki user's password</span> 
* '''<span lang="en" dir="ltr" class="mw-content-ltr">Monitoring user activity</span>'''
** {{ll|Category:User activity extensions}}
* '''<span lang="en" dir="ltr" class="mw-content-ltr">Assignment of access rights by IP, user identity</span>'''
** [[meta:Access control]]
** <span lang="en" dir="ltr" class="mw-content-ltr">[[Special:MyLanguage/Manual:FAQ#Initial user was not created by installer|FAQ/Initial user was not created by installer]]</span>
** <span lang="en" dir="ltr" class="mw-content-ltr">[[Special:MyLanguage/Manual:FAQ#Anti-spam|FAQ/Anti-spam]]</span>
** {{ll|Manual:User rights}} - <span lang="en" dir="ltr" class="mw-content-ltr">describes configuration of the default MediaWiki rights architecture</span>
** {{ll|Manual:Preventing access}} - <span lang="en" dir="ltr" class="mw-content-ltr">various tips and how-to guides</span>
** {{ll|Manual:Image authorization}} - <span lang="en" dir="ltr" class="mw-content-ltr">IP/user-based restrictions on access to images</span>
** {{ll|Security issues with authorization extensions}}
** {{ll|Category:User rights extensions}} - <span lang="en" dir="ltr" class="mw-content-ltr">extensions that assist in user rights management</span>
** {{ll|Extension:Lockdown}}
** <span lang="en" dir="ltr" class="mw-content-ltr">Configuration variables:</span> {{ll|Manual:$wgGroupPermissions|$wgGroupPermissions}}, {{ll|Manual:$wgAddGroups|$wgAddGroups}}, {{ll|Manual:$wgRemoveGroups|$wgRemoveGroups}}, {{ll|Manual:$wgImplicitGroups|$wgImplicitGroups}}
* '''<span lang="en" dir="ltr" class="mw-content-ltr">Security-enhanced MediaWiki versions/sample installations</span>'''
** {{ll|Extension:GroupWikiBase}}
* '''<span lang="en" dir="ltr" class="mw-content-ltr">Security alerts</span>'''
** {{ll|Security}} - <span lang="en" dir="ltr" class="mw-content-ltr">how to report problems, receive notifications</span>
** {{ll|Template:Security alert}}
** {{ll|Template:XSS alert}}
** {{ll|Category:Extensions with XSS vulnerabilities}}
** [[ModSecurity]]
* '''<span lang="en" dir="ltr" class="mw-content-ltr">Technical details</span>'''
** <span lang="en" dir="ltr" class="mw-content-ltr">database schema:</span> [[User groups table]], [[User table]], [[Revision table]], [[Recentchanges table]]
** <span lang="en" dir="ltr" class="mw-content-ltr">hooks:</span> {{ll|Manual:Hooks/UserLoginComplete|UserLoginComplete}}, {{ll|Manual:Hooks/UserLogout|UserLogout}}, {{ll|Manual:Hooks/UserLogoutComplete|UserLogoutComplete}}, {{ll|Manual:Hooks/UserEffectiveGroups|UserEffectiveGroups}}, {{ll|Manual:Hooks/UserGetRights|UserGetRights}}
** <span lang="en" dir="ltr" class="mw-content-ltr">code:</span> {{file doclink|User}}
** {{ll|Manual:Special pages}} - <span lang="en" dir="ltr" class="mw-content-ltr">instructions for designing access rights-aware special pages.</span>
* '''<span lang="en" dir="ltr" class="mw-content-ltr">[https://www.owasp.org/ Open Web Application Security Project] (OWASP)</span>'''
* '''<span lang="en" dir="ltr" class="mw-content-ltr">[https://modsecurity.comodo.com/ Web Application Security - Modsecurity Rules] (WAS)</span>'''
* '''{{ll|Security for developers}}''' - <span lang="en" dir="ltr" class="mw-content-ltr">for developers</span>

[[Category:Security{{#translation:}}|*]]
[[Category:Installation{{#translation:}}]]