Jika Anda yakin telah menemukan masalah keamanan di MediaWiki atau di salah satu situs web Wikimedia, lihat Keamanan untuk informasi kontak sehingga kami dapat menyiapkan rilis perbaikan bug.

Tetap terkini

Langkah keamanan terpenting yang dapat Anda lakukan adalah selalu memperbarui perangkat lunak Anda. Baik MediaWiki maupun perangkat lunak yang menjadi dasarnya terkadang akan menghasilkan versi baru yang memperbaiki kerentanan keamanan yang baru ditemukan yang mungkin memengaruhi Anda.

Pengembang MediaWiki sangat menyarankan agar siapa pun yang menjalankan MediaWiki berlangganan milis mediawiki-announce. Ini adalah daftar dengan lalu lintas rendah yang hanya mengirimkan pengumuman versi baru.

Sesuai dengan siklus hidup versi MediaWiki, setiap rilis akan menerima pembaruan keamanan selama satu tahun. Rilisan lama mungkin mengandung celah keamanan yang diketahui tetapi belum ditambal.

Jangan lupa untuk terus mengikuti pembaruan pada Apache, PHP, MySQL/MariaDB, dan perangkat lunak lainnya yang berjalan di server Anda – baik sistem operasi maupun aplikasi web lainnya.

Berhati-hatilah dengan ekstensi yang Anda gunakan

Ada berbagai macam ekstensi yang tersedia untuk MediaWiki. Sayangnya, ekstensi-ekstensi ini juga memiliki berbagai macam tingkat kualitas. Menggunakan ekstensi berkualitas rendah dengan MediaWiki merupakan salah satu penyebab paling umum masalah keamanan untuk MediaWiki.

Sebelum memutuskan untuk menggunakan ekstensi, Anda harus melakukan penelitian dasar tentang ekstensi tersebut. Ekstensi yang dibuat oleh anggota terkemuka komunitas pengembang MediaWiki biasanya cukup aman. Demikian pula setiap ekstensi yang digunakan pada wiki yang dikelola oleh Wikimedia Foundation mungkin telah diteliti secara cermat, dan mungkin aman (Tentu saja tidak ada jaminan). Namun jika Anda menemukan suatu ekstensi beredar di GitHub yang belum tersentuh selama bertahun-tahun dan dikembangkan oleh seseorang dengan sedikit pengalaman dalam pengembangan web, mungkin itu berisiko cukup tinggi.

Pada akhirnya, Anda harus mengevaluasi risiko keamanan dalam menginstal ekstensi dengan cara yang sama seperti Anda mengevaluasi risiko keamanan dalam menginstal perangkat lunak lainnya.

Ekstensi juga perlu terus diperbarui seperti perangkat lunak lainnya. Ekstensi yang dibundel dengan MediaWiki memiliki pengumuman keamanan yang dibuat di milis mediawiki-announce, tetapi ekstensi lainnya tidak. Beberapa, tetapi tentu saja tidak semua ekstensi mengumumkan masalah keamanan di milis mediawiki-l.

Izin berkas

Hal lain yang sangat penting yang harus Anda lakukan untuk mengamankan instalasi MediaWiki Anda: Pastikan pengguna yang menjalankan php tidak memiliki akses tulis ke file atau direktori yang dapat diakses web di mana php diaktifkan untuk dijalankan.

Pada sistem berbasis Debian, ini berarti pengguna www-data tidak boleh memiliki berkas php.

Pada sistem mirip unix, Anda dapat melakukannya dengan memastikan bahwa direktori/file mediawiki dimiliki oleh orang lain selain pengguna server web Anda (www-data) atau pengguna server mysql. Bergantung pada bagaimana Anda memasang MediaWiki, hal ini mungkin sudah terjadi, tetapi jika tidak, dapat dilakukan dengan melakukan chown -R <usernamehere> /path/to/MediaWiki/, di mana nama pengguna adalah pengguna selain pengguna webserver atau mysql (biasanya Anda akan menggunakan nama pengguna Anda sendiri asalkan mysql dan php tidak berjalan sebagai nama pengguna Anda). Setelah melakukan langkah itu, Anda mungkin perlu mengubah pemilik direktori gambar kembali ke pengguna php, karena file yang diunggah perlu berada di sana, sehingga MediaWiki harus dapat menulis di sana (misalnya chown -R www-data /path/to/MediaWiki/images). Selanjutnya Anda menjalankan chmod -R go-w /path/to/MediaWiki untuk menghapus akses tulis dari semua pengguna lain selain pemilik file. Setelah melakukan langkah tersebut, Anda mungkin perlu mengaktifkan kembali akses tulis ke direktori gambar.

Direktori tempat MediaWiki memerlukan akses penulisan (seperti $wgCacheDirectory jika fitur tersebut diaktifkan) harus ditempatkan di luar root web. Pengecualiannya adalah direktori gambar, yang harus berada di root web. Namun, penting untuk menonaktifkan php di direktori gambar. Rincian tentang cara melakukan ini bervariasi berdasarkan server web, tetapi pada apache terkadang dapat dilakukan dengan menggunakan php_flag engine off dalam file .htaccess. Jika Anda melakukannya melalui berkas konfigurasi dalam direktori gambar itu sendiri, Anda harus memastikan berkas konfigurasi tersebut tidak dapat ditulis oleh server web. Lihat bagian di bawah tentang keamanan unggahan untuk keterangan lebih rinci.

Berkas LocalSettings.php Anda harus dapat dibaca oleh pengguna php, namun tidak boleh dapat dibaca oleh semua orang, untuk mencegah proses lain menemukan kata sandi basis data Anda dan informasi sensitif lainnya. Seperti semua berkas MediaWiki, pengguna php tidak boleh menulis ke LocalSettings.php.

Setelah mengubah izin, Anda mungkin perlu memulai ulang server web agar perubahan diterapkan.

Keamanan Lapisan Transportasi (TLS, HTTPS)

Untuk melindungi dari serangan gaya firesheep dan kebocoran privasi umum, disarankan untuk menghosting situs Anda menggunakan TLS (HTTPS). Panduan untuk menyiapkan TLS berada di luar cakupan dokumen ini, namun perlu dicatat bahwa ini jauh lebih murah sekarang karena letsencrypt.org menyediakan sertifikat gratis.

Jika Anda melakukan pengaturan TLS, penting untuk menguji situs Anda dengan ssllabs.com/ssltest/ untuk memastikan pengaturannya benar, karena sangat mudah untuk salah mengonfigurasi TLS.

Jika Anda mengaktifkan TLS, Anda mungkin juga ingin mengonfigurasi server web Anda untuk mengirim header strict-transport-security. Hal ini akan meningkatkan keamanan situs web Anda terhadap penyadap, tetapi memiliki kekurangan yaitu Anda tidak dapat memutuskan untuk berhenti menggunakan TLS selama jangka waktu tertentu.

Rekomendasi umum PHP

Silakan merujuk ke OWASP Lembar Cheat Keamanan PHP

Saran ini berlaku untuk semua lingkungan PHP, dan belum tentu khusus untuk MediaWiki.

Rekomendasi konfigurasi PHP, untuk php.ini atau yang ditetapkan sebaliknya:

• Kecuali Anda memerlukannya secara khusus, nonaktifkan allow_url_fopen.
  • Kerentanan eksekusi kode PHP jarak jauh mungkin bergantung pada kemampuan memasukkan URL ke dalam include() atau require(). Jika Anda tidak memerlukan penggunaan pemuatan file jarak jauh, menonaktifkannya dapat mencegah serangan semacam ini pada kode yang rentan.
  • MediaWiki mungkin mengharuskan pengaturan ini untuk ekstensi pencarian Lucene, ekstensi pemanen OAI, ekstensi TitleBlacklist, dan penggunaan tertentu Special:Import dalam 1.5. Namun, pengaturan ini tidak diperlukan dalam instalasi umum.
  • MediaWiki seharusnya aman meskipun ini diaktifkan; menonaktifkan ini merupakan tindakan pencegahan terhadap kemungkinan kerentanan yang tidak diketahui.
• Nonaktifkan session.use_trans_sid.
  • Jika ini aktif, ID sesi terkadang dapat ditambahkan ke URL jika kuki tidak berfungsi sebagaimana mestinya. Hal itu dapat membocorkan data sesi login ke situs pihak ketiga melalui data rujukan atau pemotongan dan penempelan tautan.
  • Anda harus selalu mematikannya jika sedang menyala.

Misalnya jika Anda melihat baris ini di php.ini:

allow_url_fopen = On

Ubahlah menjadi:

allow_url_fopen = Off

Alternatifnya, Anda dapat menambahkan perintah apache ini untuk menonaktifkan allow_url_fopen pada tiap direktori:

php_flag allow_url_fopen off

Kemudian mulai ulang Apache untuk memuat ulang perubahan sebesar apachectl reload atau rcapache2 reload (SuSE).

Pada sistem multipengguna dengan PHP terinstal sebagai modul Apache, semua skrip pengguna akan berjalan di bawah akun pengguna dengan hak istimewa yang dikurangi yang sama. Ini dapat memberikan pengguna lain akses untuk membaca berkas konfigurasi Anda (termasuk kata sandi basis data), membaca dan mengubah data sesi login Anda, atau menulis berkas ke direktori unggahan Anda (jika diaktifkan).

Untuk keamanan multipengguna, pertimbangkan untuk menggunakan konfigurasi CGI/FastCGI di mana setiap skrip pengguna berjalan di bawah akun mereka sendiri.

Rekomendasi umum MySQL dan MariaDB

Secara umum, Anda harus menjaga akses ke basis data MySQL atau MariaDB seminimal mungkin. Jika hanya akan digunakan dari satu mesin tempat server tersebut berjalan, pertimbangkan untuk menonaktifkan dukungan jaringan, atau mengaktifkan akses jaringan lokal saja (melalui perangkat loopback, lihat di bawah), sehingga server hanya dapat berkomunikasi dengan klien lokal melalui soket domain Unix.

Jika akan digunakan melalui jaringan dengan jumlah mesin klien yang terbatas, pertimbangkan untuk menetapkan aturan firewall IP agar menerima akses ke port TCP 3306 (port MySQL/MariaDB) hanya dari mesin tersebut atau hanya dari subnet lokal, dan menolak semua akses dari internet yang lebih luas. Hal ini dapat membantu mencegah pembukaan akses ke server Anda secara tidak sengaja yang disebabkan oleh beberapa kelemahan yang tidak diketahui di server basis data, GRANT yang salah ditetapkan terlalu luas, atau kata sandi yang bocor.

Jika Anda membuat pengguna MySQL/MariaDB baru untuk MediaWiki melalui penginstal MediaWiki, akses yang cukup bebas diberikan untuk memastikan bahwa ia akan berfungsi dari server kedua maupun server lokal. Anda dapat mempertimbangkan untuk mempersempitnya secara manual atau membuat akun pengguna sendiri dengan izin khusus hanya dari tempat yang Anda perlukan. Pengguna basis data hanya perlu memiliki izin SELECT, INSERT, UPDATE dan DELETE untuk basis data.

Khususnya, hak istimewa FILE merupakan penyebab umum masalah keamanan. Anda harus memastikan bahwa pengguna MySQL/MariaDB tidak memiliki hak istimewa ini atau hak istimewa "administrasi server" lainnya.

Perhatikan bahwa tabel user dalam basis data MediaWiki berisi kata sandi pengguna yang di-hash dan mungkin berisi alamat surel pengguna, dan secara umum harus dianggap sebagai data pribadi.

Kata sandi basis data

Lihat Manual:Securing database passwords untuk beberapa tindakan pencegahan yang mungkin ingin Anda ambil untuk mengurangi risiko kata sandi MySQL/MariaDB ditampilkan di web.

Tata letak berkas alternatif

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: Manual:Configuring file uploads/id

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.

Lihat pula

• Umum
  • Kategori:Ekstensi akses pengguna
  • Configuration Settings: Access
• Planning/Requirements gathering
  • Manual:Persyaratan instalasi
• User authorization
  • AuthManager – describes plug-in architecture for determining user identity
  • Manual:$wgAuthManagerConfig – configuration variable used by plug-in architecture
  • Kategori:Otentikasi dan login – authorization extensions available
  • Manual:Resetting passwords – 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:Hak pengguna – describes configuration of the default MediaWiki rights architecture
  • Manual:Mencegah akses – 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
  • Keamanan – 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:Halaman khusus – 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