Jump to content

Handbuch:Sicherheit

From mediawiki.org
This page is a translated version of the page Manual:Security and the translation is 29% complete.
Outdated translations are marked like this.
Languages:
Wenn Du der Meinung bist, dass Du ein Sicherheitsproblem in MediWiki oder einer von Wikimedias Webseiten gefunden hast, findest Du auf Sicherheit die Kontaktinformationen, sodass wir ein Bugfix-Release vorbereiten können.
Brian Wolff hält auf der EMWCon 2018 einen Vortrag, wie eine MediaWiki Installation abgesichert werden kann.

Bleibe auf dem Laufenden

Die wichtigste Sicherheitsmaßnahme ist, die Software auf dem neuesten Stand zu halten. MediaWiki und die Software, auf der MediaWiki basiert, werden manchmal neue Versionen herausbringen, die neuentdeckte Sicherheitslücken korrigieren, welche eine Auswirkung auf Dich haben können.

Die MediaWiki-Entwickler empfehlen jedem MediaWiki-Betreiber dringend, sich bei der mediawiki-announce mailing list zu registrieren. Diese Liste versendet nur Ankündigungen für neue Versionen (low-traffic list).

Gemäß dem Versionslebenszyklus von MediaWiki erhält jede Version ein Jahr lang Sicherheitsupdates. Ältere Versionen können bekannte, aber ungepatchte Sicherheitslücken enthalten.

Vergiss nicht, auch die Updates für Apache, PHP, MySQL/MariaDB und jede andere Software, die auf deinen Servern ausgeführt wird, auf dem Laufenden zu halten – sowohl das Betriebssystem als auch andere Webanwendungen.

Sei vorsichtig, welche Erweiterung du benutzt

Es gibt eine Vielzahl von Erweiterungen für MediaWiki. Leider gibt es diese Erweiterungen auch in sehr unterschiedlichen Qualitätsstufen. Die Verwendung einer minderwertigen Erweiterung mit MediaWiki ist eine der häufigsten Ursachen für Sicherheitsprobleme bei MediaWiki.

Bevor du dich entscheidest, eine Erweiterung zu verwenden, solltest du grundlegende Informationen über die Erweiterung einholen. Erweiterungen, die von prominenten Mitgliedern der MediaWiki-Entwicklergemeinschaft erstellt wurden, sind normalerweise ziemlich sicher. In ähnlicher Weise wurde jede Erweiterung, die in einem von der Wikimedia Foundation betriebenen Wiki verwendet wird, wahrscheinlich sorgfältig geprüft und ist wahrscheinlich sicher (es gibt natürlich keine Garantien). Wenn du jedoch eine Erweiterung auf Github findest, die seit vielen Jahren nicht mehr angefasst und von jemandem entwickelt wurde, der nur wenig Erfahrung in der Webentwicklung hat, ist das Risiko wahrscheinlich ziemlich hoch.

Letztendlich solltest du das Sicherheitsrisiko bei der Installation einer Erweiterung genauso einschätzen wie das Sicherheitsrisiko bei jeder anderen Software.

Erweiterungen müssen wie jede andere Software auch auf dem neuesten Stand gehalten werden. Erweiterungen, die mit MediaWiki gebündelt sind, haben Sicherheitsankündigungen auf der Mailingliste mediawiki-announce, aber andere Erweiterungen nicht. Einige, aber definitiv nicht alle Erweiterungen geben Sicherheitsprobleme auf der Mailingliste mediawiki-l bekannt.

Dateiberechtigungen

Eine weitere sehr wichtige Sache, die du tun solltest, um deine MediaWiki-Installation abzusichern: „Achte darauf, dass der Benutzer, der php ausführt, keinen Schreibzugriff auf eine vom Web aus zugängliche Datei oder ein Verzeichnis hat, auf dem php ausgeführt werden kann.“

Auf Debian-basierten Systemen bedeutet dies, dass der Benutzer www-data nicht Besitzer der PHP-Dateien sein sollte.

Auf unixähnlichen Systemen müssen dafür die MediaWiki-Verzeichnisse/Dateien einem anderen Benutzer als dem Webserver-Benutzer (www-data) oder dem mysql-Server-Benutzer gehören. Je nachdem, wie MediaWiki installiert wurde, kann dies bereits der Fall sein, aber wenn nicht, kann dies durch chown -R <hier_Benutzername> /path/to/MediaWiki/ erreicht werden, wobei Benutzername ein anderer Benutzer als der Webserver- oder mysql-Benutzer ist (normalerweise würde man seinen eigenen Benutzernamen verwenden, vorausgesetzt mysql und php laufen nicht unter dem eigenen Benutzernamen). Nach diesem Schritt musst du allerdings den Besitzer des Bilder-Verzeichnisses wieder auf den PHP-Benutzer zurückändern, da hochgeladene Dateien dorthin gelangen müssen, so dass MediaWiki in der Lage sein muss, dorthin zu schreiben (z.B. chown -R www-data /path/to/MediaWiki/images). Als Nächstes lässt man chmod -R go-w /path/to/MediaWiki laufen, um den Schreibzugriff für alle anderen Benutzer außer den Besitzern der Datei zu entfernen. Nach diesem Schritt muss eventuell der Schreibzugriff auf das Bilder-Verzeichnis wieder aktiviert werden.

Verzeichnisse, auf die MediaWiki Schreibzugriff benötigt (wie z.B. $wgCacheDirectory, falls diese Funktion aktiviert ist), sollten sich außerhalb der Web-Root befinden. Die Ausnahme ist das Bilder-Verzeichnis, das sich im Web-Root befinden muss. Es ist jedoch wichtig, dass PHP im Bilder-Verzeichnis deaktiviert wird. 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.


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

Allgemeine PHP-Empfehlungen

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

Ändere es zu: 

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

Generell solltest du Zugriff zu deiner MySQL- oder MariaDB-Datenbank auf einen Minimum beschränken. 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.

Wartungsskripte

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.

Upgrade vom MediaWiki

Während des Upgrades werden mehr MySQL/MariaDB-Rechte benötigt.

Mehr über MySQL und 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

Wenn die MySQL- oder MariaDB-Datenbank geleakt wurde

Wenn die Datenbank an die Öffentlichkeit geleakt wurde, mache folgendes in LocalSettings.php:

  1. Ändere $wgDBpassword , falls dies auch geleakt wurde
  2. Ändere ein paar Zeichen in $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


Falls LocalSettings.php geleakt wurde

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

  1. Ändere $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

Datenbankpasswörter

See Handbuch:Datenbankpasswörter sichern for some precautions you may wish to take to reduce the risk of MySQL/MariaDB passwords being presented to the web.

Alternatives Dateilayout

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.

Verschiebe sensible Informationen

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

Siehe auch: Handbuch:Datei-Uploads konfigurieren

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

Externe Programme

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

Siehe auch

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