אם אתם סבורים שמצאתם בעיית אבטחה במדיה-ויקי או באחד מאתרי האינטרנט של ויקימדיה, עיינו ב-Security לקבלת פרטי קשר כדי שנוכל להכין גרסה לתיקון באגים.

הישארו מעודכנים

צעד האבטחה החשוב ביותר שתוכלו לנקוט הוא לעדכן את התוכנה שלכם. גם מדיה-ויקי וגם התוכנה עליה היא תלויה יפיקו מדי פעם גרסאות חדשות לתיקון פגיעויות אבטחה שהתגלו לאחרונה ועשויות להשפיע עליך.

מפתחי מדיה-ויקי ממליצים בחום שכל מי שמפעיל את מדיה-ויקי יירשם לרשימת התפוצה mediawiki-announce. זוהי רשימה בעלת תנועה נמוכה ששולחת רק הכרזות על גרסאות חדשות.

בהתאם למחזור חיי הגרסה של מדיה-ויקי, כל גרסה תקבל עדכוני אבטחה למשך שנה אחת. גרסאות ישנות יותר עשויות להכיל פרצות אבטחה ידועות אך שלא תוקנו.

אל תשכחו גם להתעדכן בעדכונים של Apache, PHP, MySQL/MariaDB וכל תוכנה אחרת שפועלת בשרתים שלכם - הן מערכת ההפעלה והן יישומי אינטרנט אחרים.

היזהרו באילו הרחבות אתם משתמשים

יש מגוון רחב של הרחבות זמינות עבור מדיה-ויקי. למרבה הצער, הרחבות אלו הן גם ברמות איכות שונות. שימוש בהרחבה באיכות נמוכה במדיה-ויקי הוא אחד הגורמים הנפוצים ביותר לבעיות אבטחה עבור מדיה-ויקי.

לפני שתחליטו להשתמש בהרחבה, עליכם לבצע מחקר בסיסי על ההרחבה. הרחבות שנוצרו על ידי חברים בולטים בקהילת הפיתוח של מדיה-ויקי הן בדרך כלל בטוחות למדי. באופן דומה, כל הרחבה המשמשת בויקי המנוהל על ידי קרן ויקימדיה כנראה נבדקה בקפידה, וכנראה היא בטוחה (כמובן שאין ערבויות לכך). עם זאת, אם אתם מוצאים הרחבה שמסתובבת ב-GitHub שלא נגעו בה במשך שנים רבות ופותחה על ידי מישהו עם מעט ניסיון בפיתוח אתרים, זה כנראה מהווה סיכון גבוה למדי.

בסופו של דבר, עליכם להעריך את סיכון האבטחה של התקנת הרחבה באותו אופן שבו הייתם מעריכים את סיכון האבטחה של התקנת כל תוכנה אחרת.

יש לעדכן גם הרחבות כמו כל תוכנה אחרת. הרחבות המצורפות למדיה-ויקי כוללות הודעות אבטחה לרשימת התפוצה של mediawiki-announce, אך הרחבות אחרות לא. חלק מההרחבות, אך בהחלט לא כולן, מכריזות על בעיות אבטחה ברשימת התפוצה של mediawiki-l.

הרשאות קבצים

דבר חשוב נוסף שעליכם לעשות כדי לאבטח את התקנת המדיה-ויקי שלכם: ודאו שלמשתמש שמפעיל את php אין גישת "כתיבה" (write) לכל קובץ או ספרייה נגישים לאינטרנט ש-php מורשה לפעול עליהם.

במערכות מבוססות דביאן, פירוש הדבר שמשתמש www-data לא אמור להיות הבעלים של קבצי ה-php.

במערכות דמויות יוניקס, ניתן לעשות זאת על ידי וידוא שספריית/קבצי mediawiki נמצאים בבעלות מישהו שאינו משתמש שרת האינטרנט שלך (www-data) או משתמש שרת mysql. תלוי באופן שבו התקנת את מדיה-ויקי, ייתכן שזה כבר המצב, אך אם לא, ניתן לעשות זאת על ידי ביצוע הפקודה chown -R <usernamehere> /path/to/MediaWiki/ כאשר שם המשתמש הוא משתמש שאינו שרת האינטרנט או משתמש mysql (בדרך כלל תשתמש בשם המשתמש שלך, בתנאי ש-mysql ו-php אינם פועלים כשם המשתמש שלך). לאחר ביצוע שלב זה, ייתכן שתצטרכו לשנות את הבעלים של ספריית התמונות בחזרה למשתמש php, מכיוון שקבצים שהועלו צריכים להגיע לשם, ולכן מדיה-ויקי צריכה להיות מסוגלת לכתוב לשם (למשל chown -R www-data /path/to/MediaWiki/images). לאחר מכן, הפעל את הפקודה chmod -R go-w /path/to/MediaWiki כדי להסיר גישת ה"כתיבה" מכל המשתמשים האחרים מלבד בעלי הקובץ. לאחר ביצוע שלב זה, ייתכן שתצטרך להפעיל מחדש גישת "כתיבה" לתיקיית התמונות.

ספריות שמדיה-ויקי זקוקה להן לגישת "כתיבה" (כגון $wgCacheDirectory אם תכונה זו מופעלת) צריכות להיות ממוקמות מחוץ ל"שורש" האינטרנט. 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 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.

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

Please refer to the OWASP PHP Security Cheat Sheet

allow_url_fopen = On

allow_url_fopen = Off

php_flag allow_url_fopen off

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

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.

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:

• Manual:$wgDBadminuser
• Manual:$wgDBadminpassword

• 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

1. Change $wgDBpassword if that leaked too.
2. Change some letters 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.

1. Change $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

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

<?php
chdir('/path/to/wiki');
require('./index.php');

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.

See also: מדריך:הגדרת העלאות קבצים

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

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

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

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

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

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

• General
  • Category:User access extensions
  • Configuration Settings: Access
• Planning/Requirements gathering
  • מדריך:דרישות התקנה
• User authorization
  • AuthManager – describes plug-in architecture for determining user identity
  • Manual:$wgAuthManagerConfig – configuration variable used by plug-in architecture
  • קטגוריה:אימות וכניסה – authorization extensions available
  • מדריך:איפוס סיסמאות – reseting a MediaWiki user's password
• Monitoring user activity
  • Category:User activity extensions
• Assignment of access rights by IP, user identity
  • FAQ/Initial user was not created by installer
  • FAQ/Anti-spam
  • Manual:User rights – describes configuration of the default MediaWiki rights architecture
  • Manual:Preventing access – various tips and how-to guides
  • Manual:Image authorization – IP/user-based restrictions on access to images
  • Security issues with authorization extensions
  • Category:User rights extensions – extensions that assist in user rights management
  • Extension:Lockdown
  • Configuration variables: $wgGroupPermissions , $wgAddGroups , $wgRemoveGroups , $wgImplicitGroups
• Security-enhanced MediaWiki versions/sample installations
• Security alerts
  • Security – how to report problems, receive notifications
  • Category:Extensions with security vulnerabilities
  • ModSecurity
• Technical details
  • database schema: Manual:User groups table , Manual:User table , Manual:Revision table , Manual:Recentchanges table
  • hooks: UserLoginComplete , UserLogout , UserLogoutComplete , UserEffectiveGroups , UserGetRights
  • code: User.php
  • Manual:Special pages – instructions for designing access rights-aware special pages.
• Open Web Application Security Project (OWASP)
• Web Application Security - Modsecurity Rules (WAS)
• Security for developers – for developers