MediaWiki

Handleiding:Beveiliging

This page is a translated version of the page Manual:Security and the translation is 100% complete.
Languages:
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.
  • Als u bind-address=127.0.0.1 instelt in uw my.ini (onder sectie [mysqld]) zal MySQL/MariaDB alleen luisteren op de loopback-interface. Dit is de standaard in de EasyPHP-installatie voor Windows. (Als u MySQL/MariaDB gebruikt op een Unix-machine, kan de instelling skip-networking zijn in plaats van in het bestand my.cnf.)
  • GRANT en REVOKE syntaxis

Als er een datalek is in de MySQL- of MariaDB-database

Als er een datalek is in de database, in LocalSettings.php:

  1. Wijzig $wgDBpassword als daar ook een datalek was
  2. Verander enkele letters in $wgSecretKey .
  3. Stel $wgAuthenticationTokenVersion in op een onvoorspelbare waarde om ervoor te zorgen dat waarden van user_token in uw database niet kunnen worden gebruikt om zich voor te doen als een van uw gebruikers


Bij een datalek in LocalSettings.php

Als er een datalek was in LocalSettings.php, bescherm deze dan opnieuw en:

  1. Verander $wgDBpassword
  2. Vervang $wgSecretKey door een andere willekeurige reeks letters en cijfers
  3. Maak een andere $wgSpamRegex (optioneel)
  4. Reset de kolom user_token in de tabel user zodat deze niet gebruikt kan worden om gebruikers te imiteren

Database wachtwoorden

Lees Manual:Securing database passwords voor enkele voorzorgsmaatregelen die u mogelijk wilt nemen om het risico te verkleinen dat MySQL/MariaDB-wachtwoorden op internet worden getoond.

Alternatieve bestandslay-out

MediaWiki is ontworpen om op zijn plaats te draaien nadat het uit het distributie-archief is gehaald. Deze aanpak is handig, maar kan leiden tot verminderde beveiliging of onnodige duplicatie van bestanden.

U voorkomt duplicaten in een massa-installatie of om gevoelige bestanden uit de webroot te houden voor veiligheid door verschillende bestanden handmatig te verplaatsen of te consolideren.

Het verplaatsen van de hoofdbestanden en skin-bestanden kan het verzamelen, kiezen en wijzigen van de code in uw LocalSettings.php verfijnen. Experimenteer hiermee, als u dat wilt.

Als u aan het verbeteren van de beveiliging werkt, moet u er rekening mee houden dat WebStart.php de huidige map als basis gebruikt. Dit betekent dat het instellen van uw include_path niet de veiligheid van uw installatie kan verbeteren.

Gevoelige informatie verplaatsen

Overweeg om het databasewachtwoord of andere mogelijk gevoelige gegevens te verplaatsen van LocalSettings.php naar een ander bestand dat zich buiten de hoofdmap van het webdocument bevindt, en dat bestand in LocalSettings.php (met include()) op te nemen. Dit kan helpen ervoor te zorgen dat uw database wachtwoord niet wordt gecompromitteerd als een configuratiefout van de webserver de PHP-uitvoering uitschakelt en de brontekst van het bestand wordt onthuld.

Net zo zal het bewerken van LocalSettings.php met sommige redacteurs een back-upbestand in dezelfde map achterlaten met een gewijzigde bestandsuitbreiding, waardoor de kopie als gewone tekst wordt geserveerd als iemand bijvoorbeeld LocalSettings.php~ vraagt. Als u zo'n editor gebruikt, moet u de back-upgeneratie uitschakelen of gevoelige gegevens buiten de webroot plaatsen.

Een MediaWiki debug logfile zoals het wordt gebruikt voor debugging bevat ook gevoelige gegevens. Zorg ervoor dat u de toegang voor niet-geautoriseerde personen en het publiek altijd verbiedt zoals uitgelegd, verwijder de restanten van dergelijke logbestanden wanneer ze niet nodig zijn en commenteer of verwijder de regels over logging in uw 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

Stel DocumentRoot in op /dev/null

Een veilige optie voor de Apache Web Server is om de DocumentRoot in een lege of niet-bestaande map te instellen en vervolgens een Alias in de Apache-configuratie te gebruiken om alleen de scripts en mappen die webtoegankelijk moeten zijn te laten zien.

Loader scripts

Een PHP-only oplossing die met elke webserver werkt, is het schrijven van een reeks scripts die expliciet naar een specifieke map chdir() en vervolgens een of meer bronbestanden vereisen. Bijvoorbeeld: 

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

Gebruiker beveiliging

Iedereen die in staat is om de gebruikersinterface bepaalde systeemberichten in de namespace MediaWiki: te bewerken, kan willekeurige JavaScript- en CSS-code introduceren in de pagina-uitvoer. Dit omvat wiki-gebruikers die de rechten editsitejs/editsitecss hebben, evenals iedereen met directe schrijftoegang tot de tabel text in de database.

Deze zijn meestal uitgeschakeld op het login-scherm, dus het risico op 'snarfing' van het wachtwoord in JavaScript moet minimaal zijn. Maar kwaadwillende code kan nog steeds proberen om kwetsbaarheden in de browser te exploiteren (spyware installeren, enz.), dus moet u ervoor zorgen dat alleen vertrouwde mensen systeemberichten kunnen wijzigen.

Upload beveiliging

Zie ook: Handleiding:Bestandsuploads configureren

De belangrijkste zorg is: hoe voorkomen we dat gebruikers schadelijke bestanden uploaden?

Het uploaden van bestanden is een optionele functie van MediaWiki en wordt standaard uitgeschakeld. Als u deze inschakelt, moet u ook een map in de webroot verstrekken waarin door de webservergebruiker kan worden geschreven.

Dit heeft verschillende gevolgen voor de veiligheid:

  • De map moet mogelijk beschrijfbaar zijn, of anders eigendom zijn van het beperkte gebruikersaccount van de webserver. Op een systeem met meerdere gebruikers kan het mogelijk zijn voor andere lokale gebruikers om schadelijke bestanden in uw uploadmap te plaatsen (zie opmerkingen over meerdere gebruikers hierboven). Als het mogelijk is, maak de map alleen schrijfbaar via het account van de webserver, maak het niet globaal schrijfbaar.
  • Hoewel de configuratie van PHP een limiet op de bestandsgrootte van individuele uploads stelt, stelt MediaWiki geen limiet op totale uploads. Een kwaadwillige (of ijverige) bezoeker kan een schijfpartitie vullen door veel bestanden te uploaden.
  • Gemaakte miniaturen en geüploade bestanden die worden bewaard voor overschrijving kunnen worden bewaard in images/thumb en images/tmp zonder zichtbare kennisgeving in de webinterface van MediaWiki. Hou ook hun grootte in de gaten.

De standaardconfiguratie probeert de soorten bestanden die voor veiligheid kunnen worden geüpload te beperken:

  • Bij standaard zijn de bestandstypes png, gif, jpg, jpeg en webp toegestaan ($wgFileExtensions ).
  • Verschillende uitvoerbare en script-bestandtypes zijn expliciet verboden ($wgProhibitedFileExtensions ) zelfs als u gebruikers toestaat om de lijst toegestane bestandstypes ($wgStrictFileExtensions ) niet te gebruiken.
  • Verschillende bekende afbeeldingsbestandstypes hebben hun typen geverifieerd met behulp van de functie getimagesize() van PHP.
  • de geüploade bestanden worden gecontroleerd om te zien of ze bestandstypen detectie bugs in Internet Explorer en Safari kunnen laten zien, waardoor ze als HTML worden weergegeven. (Er is voorgesteld om deze controle te verwijderen, zie T309787).

Als voorzorgsmaatregel moet u de uitvoering van PHP-scripts (en andere scripttypen die u mogelijk heeft) aan de serverzijde expliciet uitschakelen in de uploadmap (standaard images). U moet ook de browsers instrueren om bestanden niet te "sniffen" door een header X-Content-Type-Options: nosniff in te stellen.

Een Apache conf-bestandsfragment om dit te doen, bijvoorbeeld als uw MediaWiki-instantie in /Library/MediaWiki/web is, kan er uitzien als: 

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

Als u geen toegang heeft tot apache-configuratiebestanden, maar u kunt .htaccess bestanden gebruiken om configuratie-instellingen op specifieke mappen te overschrijven, kunt u een .htaccess bestand in de uploadmap plaatsen dat er als volgt uitziet: 

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

De exacte configuratie kan variëren. In het bijzonder kan het gebruik van de opties open_basedir het hanteren van uploads compliceren.

Als u een van de bovenstaande oplossingen gebruikt, kunt u controleren of het werkt met deze eenvoudige test.

  • Maak een bestand 'test.php' aan in de uploadmap.
  • Zet <?php phpinfo(); in het bestand.
  • Ga naar het pad van het bestand in een webbrowser. Als u alleen de tekst van het bestand ziet, is het goed, anders is er ergens iets mis.

Uitschakelen PHP-oplossing voor Nginx: http://serverfault.com/a/585559/162909

Voor de beste beveiliging moet u ook overwegen om een apart domein te gebruiken voor geüploade bestanden. Voor volledige veiligheid is het het beste om uploads te laten afhandelen vanaf een volledig apart domein, geen subdomein, maar zelfs een subdomein biedt extra beveiliging. Dit is vooral belangrijk als u SVG-bestanden uploaden toestaat, omdat dat bestandsformaat vergelijkbaar is met HTML. MediaWiki controleert SVG-uploaden op beveiliging, maar het is het beste om meerdere lagen verdediging te hebben. Zie $wgUploadPath voor het configureren van een ander domein om mediabestanden af te handelen.

Externe programma's

  • /usr/bin/diff3 kan worden uitgevoerd voor bewerkingsconflicten.
  • Als ImageMagick ondersteuning heeft voor miniaturen of SVG-afbeeldingen is ingeschakeld, kan convert worden uitgevoerd op geüploadde bestanden.
  • Deze lijst is onvolledig.

U kunt Shellbox gebruiken om een meer afgesloten omgeving te bieden voor het uitvoeren van externe commando's.

Zie ook

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