Manual:Security/hu


 * Ha úgy gondolod, hogy a MediaWiki-ben vagy a Wikimédia bármely oldalán biztonsági problémát találtál, vedd fel velünk a kapcsolatot (lásd: ) hogy hibajavítást adhassunk ki.



Maradj naprakész
A legfontosabb biztonsági szempont a szoftver naprakészen tartása. Mind a MediaWiki, mind azon szoftverek amelyektől függ, időnként frissülhetnek, amely új kiadások biztonsági foltokat is tartalmaznak.

A MediaWiki fejlesztői erősen ajánlják, hogy a szoftvert használók iratkozzanak fel a mediawiki-announce levelezőlistára. Ez egy alacsony forgalmú lista, ahol az új verziókat jelentik be.

A MediaWiki élettartam-ciklusával összhangban minden kiadáshoz egy éven át érkeznek biztonsági frissítések. A régebbi kiadásokban ismert, de javítatlan biztonsági rések lehetnek.

Ne feledkezz meg az Apache, PHP, MySQL/MariaDB és más, a szervereden futó szoftverek, az operációs rendszer és a webapplikációk frissítéséről sem.

Számos, a MediaWiki 1.3.x kiadását futtató felhasználót érintett a 2004 telén terjedő PHP-féreg, amely más, nem frissített phpBB-oldalakon jutott be a szerverre, ahol az írható PHP-fájlokba, köztük a MediaWiki 1.3 lefordított sablonjaiba is „you are hacked” („oldalad feltörve”) üzenetet helyezett el.

Légy óvatos a használt kiterjesztésekkel
Számos kiterjesztés érhető el a MediaWikihez, azonban ezek változó minőségűek. Az alacsony minőségű kiterjesztések használata a biztonsági hibák egyik leggyakoribb forrása.

Egy kiterjesztés használata előtt járj utána annak. A közösség ismert tagjai által fejlesztett eszközök általában biztonságosak, ugyanez igaz a Wikimédia Alapítvány oldalain telepített kiterjesztésekre is (természetesen erre sincs garancia). Ha egy több éve nem frissített, kevés tapasztalattal rendelkező személy által készített kiterjesztést találsz GitHubon, akkor az magas biztonsági kockázatot rejthet magában.

A nap végén vedd fontolóra a telepítéssel járó biztonsági kockázatot a más szoftvereknél megszokott módon.

A kiterjesztéseket is szükséges naprakészen tartani; a MediaWiki-szoftverrel együtt érkező bővítményekkel kapcsolatos bejelentések a mediawiki-announce levelezőlistán olvashatóak, azonban a többinél ez a lehetőség nem áll fenn. Néhány külső kiterjesztés készítője a biztonsági hibákat közzéteszi a mediawiki-l levelezőlistán.

Fájlengedélyek
Az egyik legfontosabb biztonsági tényező az, hogy a PHP- (Debian esetén gyakran www-data) és a MySQL-futtató felhasználónak ne legyen a PHP engedélyezésekor nyilvánosan hozzáférhető mappákhoz írási joga.

Unix-szerű rendszereken ehhez a MediaWiki-könyvtár tulajdonosa a webszerver- (www-data) vagy a MySQL-felhasználótól eltérő kell, hogy legyen. A telepítés módjától függően ez lehet alapértelmezés is; ha nem, a  segítségével hajtható végre a művelet, ahol a felhasználónév az előbbiektől eltérő (valószínűleg a mysql és a php nem saját neved alatt fut). Ezen lépés után szükséges lehet a képek könyvtára jogosultságának visszaállítása a PHP-felhasználóra, mivel a feltöltéshez a MediaWikinek írási jogra van szüksége (például ). Végül futtasd a  parancsot, így a tulajdonosokon kívül másnak nem lesz írási joga; ezután szükséges lehet a képek mappáján az előzőekben leírtak elvégzésére.

Azon mappák, amelyekhez a szoftvernek írási jogra van szüksége (például $wgCacheDirectory), a gyökérkönyvtáron kívül helyezkedjenek el; ez alól a képek könyvtára kivétel, amelynek a gyökérben kell lennie, viszont fontos, hogy ezen mappában tiltsd le a PHP-t. A részletek a szervertől függenek, de Apache alatt általában a .htaccess fájlban elhelyezett  a kívánt viselkedést hozza. Ha a beállítást magán a könyvtáron belül végzed el, győződj meg róla, hogy a konfigurációs fájl nem írható a webszerver által. A feltöltések biztonságáért lásd a vonatkozó szakaszt.

A LocalSettings.php fájl a PHP-felhasználó által olvasható kell, hogy legyen, azonban az adatbázis-jelszó és más érzékeny információk elrejtéséhez ne legyen írható. A többi MediaWiki-fájlhoz hasonlóan a LocalSettings.php-hoz se legyen a PHP-felhasználónak írási joga.

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

Általános PHP-javaslatok

 * 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:


 * Disable.
 * Many PHP security attacks are based on injection of global variable values, so making sure it's off can make many potential vulnerabilities toothless.
 * If you require  for another web application, consider enabling it selectively, only for the virtual host or subdirectory that requires it.
 * MediaWiki should be safe even if this is on; turning this off is a precaution against the possibility of unknown vulnerabilities.
 * 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.
 * Set  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:

register_globals = On

Change it to:

register_globals = Off

Alternatively, you could add this apache directive to turn off register_globals on a per-directory basis:

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

Általános MySQL- és MariaDB-javaslatok
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 e-mail addresses, and should generally be considered private data.

Karbantartószkriptek
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.

A MediaWiki frissítése
During upgrade, more MySQL/MariaDB rights might be needed.

A MySQL-ről és a MariaDB-ről bővebben

 * 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

Ha az adatbázis kiszivárgott
If the database has leaked to the public, in LocalSettings.php:


 * 1) Change  if that leaked too
 * 2) Change some letters in
 * 3) Reset the user_token column in your user table so that it can't be used to impersonate your users

Ha a LocalSettings.php kiszivárgott
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

Adatbázis-jelszavak
See for some precautions you may wish to take to reduce the risk of MySQL/MariaDB passwords being presented to the web.

Alternatív fájlelrendezés
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  set in your. Experiment with this as desired.

If working to improve security, keep in mind that  uses the current directory as a base. This means that only setting your  may not help to improve the security of your installation.

Érzékeny adatok mozgatása
Consider moving the database password or other potentially sensitive data from  to another file located outside of the web document root, and including that file from   (through  ). 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  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,. 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.

A DocumentRoot /dev/null-ra állítása
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.

Betöltőszkriptek
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:

Felhasználói biztonság
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.

Upload security

 * See also:

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, and .jpeg are white listed.
 * Various executable and script extensions are explicitly blacklisted even if you allow users to override the whitelist.
 * Several known image file extensions have their types verified using PHP's 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.

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

For instance, an Apache .conf file fragment to do this if your MediaWiki instance is in /Library/MediaWiki/web might look something like:

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:

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

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 for configuring a different domain to serve media files.

External programs

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