Handleiding:Beveiliging

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

Als u denkt dat u een beveiligingsprobleem hebt gevonden in MediaWiki of in een van de websites van Wikimedia, zie Security voor contactinformatie zodat we een release voor het oplossen van bugs kunnen voorbereiden.

Brian Wolff presenteert op EMWCon 2018 hoe een MediaWiki-installatie veilig te installeren

Bijgewerkt houden

De belangrijkste stap in de beveiliging is om uw software up-to-date te houden. Zowel MediaWiki als de software waarop het afhankelijk is, zullen af en toe nieuwe versies produceren die nieuw ontdekte beveiligingsfouten corrigeren die u kunnen beïnvloeden.

De MediaWiki-ontwikkelaars raden iedereen die MediaWiki gebruikt ten zeerste aan om zich te abonneren op de mediawiki mailinglijst voor aankondigingen. Dit is een lijst met weinig verkeer die alleen meldingen over nieuwe versies stuurt.

In overeenstemming met MediaWiki's levensduur van versies, zal elke release gedurende één jaar beveiligingsupdates ontvangen. Oudere versies kunnen bekende, maar niet opgeloste beveiligingsproblemen bevatten.

Vergeet niet ook bij te blijven met updates van Apache, PHP, MySQL/MariaDB en andere software die op uw servers wordt uitgevoerd - zowel het besturingssysteem als andere webtoepassingen.

Wees voorzichtig met welke extensies u gebruikt

Er is een grote verscheidenheid aan extensies beschikbaar voor MediaWiki. Helaas zijn deze extensies ook van een breed scala aan kwaliteitsniveaus. Het gebruik van een extensie van lage kwaliteit met MediaWiki is een van de meest voorkomende oorzaken van beveiligingsproblemen voor MediaWiki.

Voordat u besluit een extensie te gebruiken, moet u een fundamenteel onderzoek doen naar de extensie. Extensies die worden gemaakt door prominente leden van de MediaWiki-ontwikkelingsgemeenschap zijn meestal vrij veilig. Evenzo is elke extensie die wordt gebruikt op een wiki die wordt uitgevoerd door de Wikimedia Foundation waarschijnlijk zorgvuldig bekeken en waarschijnlijk veilig. (Er zijn natuurlijk geen garanties.) Maar als u een extensie vindt die rond github zweeft die al jaren niet is gewijzigd en die is ontwikkeld door iemand met weinig ervaring in webontwikkeling, geeft het gebruik ervan waarschijnlijk een vrij hoog risico.

U moet het beveiligingsrisico van het installeren van een extensie evalueren op dezelfde manier als u het beveiligingsrisico van de installatie van andere software zou evalueren.

Extensies moeten actueel blijven zoals elk ander software. Extensies die zijn gebundeld met MediaWiki hebben beveiligingsverklaringen gedaan op de mediawiki-announcing mailinglijst, maar andere extensies niet. Sommige, maar zeker niet alle extensies geven beveiligingsproblemen aan op mediawiki-l mailinglijst.

Bestandsrechten

Een ander heel belangrijk ding dat u moet doen om uw MediaWiki-installatie te beveiligen: Zorg ervoor dat de gebruiker die php draait geen schrijftoegang heeft tot elk webtoegankelijk bestand of map waarop php mag draaien.

Bij op Debian-gebaseerde systemen betekent dit dat de gebruiker www-data niet eigenaar zou moeten zijn van de php-bestanden.

Op unix-achtige systemen kunt u dit doen door ervoor te zorgen dat de mediawiki-map/bestanden eigendom zijn van iemand anders dan uw webserver-gebruiker (www-data) of mysql-server-gebruiker. Afhankelijk van hoe u MediaWiki heeft geïnstalleerd, kan dit al het geval zijn, maar als dat niet het geval is, kan dit worden bereikt door chown -R <gebruikersnaam> /path/to/MediaWiki/ te doen waarbij de gebruikersnaam een andere gebruiker is dan de webserver of mysql-gebruiker (normaal gesproken zou u uw eigen gebruikersnaam gebruiken mysql en php niet onder uw gebruikersnaam draait). Na die stap moet u de eigenaar van de map images echter terug te veranderen naar de php-gebruiker, omdat geüploade bestanden daarheen moeten gaan, zodat MediaWiki daar moet kan schrijven (bijv. chown -R www-data /path/to/MediaWiki/images). Vervolgens voert u chmod -R go-w /path/to/MediaWiki uit om de schrijftoegang te verwijderen van alle andere gebruikers behalve de bestandseigenaren. Na die stap moet u mogelijk de schrijftoegang tot de map images opnieuw toekennen.

Mappen waar MediaWiki toegang tot moet hebben (zoals $wgCacheDirectory als die functie is ingeschakeld) moeten buiten de webroot liggen. De uitzondering is de map images, die onder de webroot moet zijn. Het is echter belangrijk om php uit te schakelen in de map images. De details van hoe dit te doen variëren per webserver, maar op Apache kan het soms worden bereikt door php_flag engine off in een bestand .htaccess te gebruiken. Als u dit via een configuratiebestand in de afbeeldingsmap zelf doet, moet u ervoor zorgen dat dat bestand niet door de webserver kan worden gewijzigd. Zie het onderstaande gedeelte over uploadbeveiliging voor meer details.

Uw bestand LocalSettings.php moet leesbaar zijn voor de php-gebruiker, maar het mag niet globaal leesbaar zijn, om te voorkomen dat andere processen uw databasewachtwoord en andere gevoelige informatie ontdekken. Net als alle MediaWiki-bestanden, moet de php-gebruiker niet in staat zijn om te schrijven naar LocalSettings.php.

Transportlaag beveiliging (TLS, HTTPS)

Om u te beschermen tegen aanvallen in de stijl van firesheep en algemene privacylekken, is het aan te raden om uw site te hosten met TLS (HTTPS). Een handleiding voor het opzetten van TLS is buiten het bereik van dit document, maar het moet worden opgemerkt dat dit veel goedkoper is nu letsencrypt.org gratis certificaten biedt.

Als u TLS instelt, is het belangrijk om uw site te testen met ssllabs.com/ssltest/ om ervoor te zorgen dat het correct is ingesteld, omdat het gemakkelijk is om TLS per ongeluk verkeerd te configureren.

Als u TLS inschakelt, kunt u uw webserver ook opzetten om de header strict-transport-security te sturen. Dit zal de beveiliging van uw website tegen afluisteren een beetje verbeteren, maar het nadeel is dat u niet kunt beslissen om voor een bepaalde periode te stoppen met het gebruik van TLS.

Algemene PHP aanbevelingen

Zie de OWASP PHP Security Cheat Sheet

Deze tips zijn voor vrijwel elke PHP-omgeving en zijn niet specifiek voor MediaWiki.

PHP-configuratie aanbevelingen, voor php.ini of anderszins ingesteld:

Tenzij u dit specifiek nodig heeft, schakel allow_url_fopen uit.
- De kwetsbaarheden bij het uitvoeren van PHP-code op afstand kunnen afhangen van het toevoegen van een URL in een include()- of require(). Als u niet het bestanden opladen van een afstand nodig heeft, kan het uitschakelen ervan voorkomen dat deze soort aanvallen plaatsvinden op kwetsbare code.
- MediaWiki kan vereisen dat deze instelling is ingeschakeld voor de extensies Lucene (zoeken), OAI-harvester en TitleBlacklist. Het moet echter niet in een typische installatie vereist worden.
- MediaWiki moet veilig zijn, zelfs als dit ingeschakeld is; het uitschakelen van deze is een voorzorgsmaatregel tegen de mogelijkheid van een onbekende kwetsbaarheid.
Schakel session.use_trans_sid uit.
- Als dit is ingeschakeld, kunnen sessie-ID's worden toegevoegd aan URL's als cookies niet hun taak doen. Dan kunnen login sessie gegevens naar websites van derden worden doorgegeven met verwijzingsgegevens of delen van links.
- U moet dit altijd uitzetten als het aan is.

Als u bijvoorbeeld deze regel ziet in php.ini:

allow_url_fopen = On

Wijzig het naar:

allow_url_fopen = Off

Als alternatief kunt u deze Apache-directive toevoegen om allow_url_fopen per map uit te schakelen:

php_flag allow_url_fopen off

Start Apache dan opnieuw om de wijzigingen te herladen met apachectl reload of rcapache2 reload (SuSE).

Op een multigebruikersysteem met PHP geïnstalleerd als een Apache-module, worden alle scripts van gebruikers uitgevoerd onder hetzelfde gebruikersaccount met beperkte privileges. Dit kan andere gebruikers toegang geven om uw configuratiebestanden (inclusief database wachtwoorden) te lezen, uw loginsessiegegevens te lezen en te wijzigen of bestanden in uw uploadmap te schrijven (indien ingeschakeld).

Voor de beveiliging bij een multigebruikersysteem moet u overwegen een CGI/FastCGI-configuratie te gebruiken waarin de scripts van elke gebruiker worden uitgevoerd op hun eigen account.

Algemene MySQL en MariaDB aanbevelingen

In het algemeen moet u de toegang tot de MySQL- of MariaDB-database beperken tot een minimum. Als het alleen wordt gebruikt vanaf de enkele machine waarop het draait, overweeg dan om netwerkondersteuning uit te schakelen, of alleen lokale netwerktoegang in te schakelen (via het loopback-device, zie hieronder), zodat de server alleen kan communiceren met lokale clients via Unix-domeinsockets.

Als het wordt gebruikt via een netwerk met een beperkt aantal clientmachines, overweeg dan de IP-firewallregels te instellen om toegang tot TCP-port 3306 (MySQL/MariaDB's port) alleen van die machines of alleen van uw lokale subnet te accepteren, en verwerpt alle toegangen vanuit het grotere internet. Dit kan helpen voorkomen dat u per ongeluk toegang tot uw server opent als gevolg van een onbekende fout in de database-server, een te brede GRANT of een gelekt wachtwoord.

Als u via de installateur van MediaWiki een nieuwe MySQL/MariaDB-gebruiker voor MediaWiki maakt, krijgt u vrij liberale toegang om ervoor te zorgen dat deze vanaf een tweede server en een lokale server werkt. U kan dit handmatig beperken of zelf het gebruikersaccount aanmaken met aangepaste toestemmingen van alleen de plaatsen waarvoor het nodig is. De databasegebruiker hoeft alleen de rechten voor SELECT, INSERT, UPDATE en DELETE voor de database te hebben.

Met name het recht FILE is een veelvoorkomende oorzaak van beveiligingsproblemen. U moet ervoor zorgen dat de MySQL/MariaDB-gebruiker deze bevoegdheid of een van de rechten voor "serverbeheer" niet heeft.

Merk op dat de user tabel in de database van MediaWiki gehashde gebruikers wachtwoorden bevat en gebruikers e-mailadres kan bevatten, en over het algemeen als privégegevens moet worden beschouwd.

Onderhoudsscripts

Voor de onderhoudsscripts wilt u misschien een DB-gebruiker aanmaken met meer rechten. Hiervoor moet u de volgende variabelen in de database van dat account instellen:

Zie deze configuratie voor details over de benodigde MySQL/MariaDB rechten.

MediaWiki upgraden

Tijdens de upgrade kunnen meer MySQL/MariaDB-rechten nodig zijn.

Meer over MySQL en 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:

Change $wgDBpassword if that leaked too
Change some letters in $wgSecretKey
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:

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

Database passwords

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

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

User security

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.

Upload security

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

If at all possible, make the directory writable only by the web server's account, don't make the directory world-writable.

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, .jpeg and webp are white listed ($wgFileExtensions ).

Various executable and script extensions are explicitly prohibited ($wgProhibitedFileExtensions ) even if you allow users to override the allowlist ($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.

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

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, images). You should also instruct browsers to not "sniff" files by setting a X-Content-Type-Options: nosniff header.

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

If you don't have access to apache configuration files, but you can use .htaccess files to override configuration settings on specific directories, you can put an .htaccess file on the upload directory that looks like this:

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

Your exact configuration may vary. In particular, the use of open_basedir options may complicate handling of uploads.

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.

Disable PHP solution for Nginx: http://serverfault.com/a/585559/162909

For best security, you should also consider using a separate domain for uploaded files. 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. This is especially important if you allow uploading SVG files since that file format is so similar to HTML. MediaWiki checks SVG uploads for security, but it is best to have multiple layers of defense. See $wgUploadPath for configuring a different domain to serve media files.

External programs

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