Sicherheit

Allgemeine Information zum absichern von Webanwendungen gibt es auf der Security Diskussions-Seite (en).

Um über Sicherheits-Probleme bezüglich DokuWiki auf dem neusten Stand zu sein abonniere am besten den DokuWiki-Feed (en) vom DokuWiki Projekt auf Freshmeat. Dafür ist allerdings ein Freshmeat-Zugang erforderlich.

Alle sicherheitsrelevanten Bugs kann man unter der Kategorie Security (en) im bugtracker (en) finden.

Wenn du ein Sicherheits-Problem in DokuWiki findest, melde es bitte erst einem Entwickler. Sprich am besten an den Haupt-Entwickler Andi

Alternativ hast du die Möglichkeit einen Fehler zu melden. Beachte aber das eine solche öffentliche Fehlermeldung von vielen Menschen gelesen werden kann.

Bei einer normalen Konfiguration kann jeder das Installationsskript ausführen. Es währe also empfehlenswert die Zugriffsrechte während der Installation so anzupassen dass nur Du darauf zugreifen kannst.

Hast du einen Apache Webserver musst du nur eine Datei .htaccess im DokuWiki-Verzeichnis auf dem Webserver anlegen (falls nicht schon vorhanden) und um folgende Zeilen erweitern:

Deny from all
Allow from 192.168.1.1

Die IP-Adresse “192.168.1.1” musst du dann durch die externe (öffentliche) IP-Adresse deines Rechners ersetzen. Deine IP-Adresse kannst du in der Regel recht schnell auf http://checkip.dyndns.org/ herausfinden. Diese unterscheidet sich meistens von deiner internen Adresse, sprich deines Netzwerkinterfaces.

Um die IP-Adresse deiner Netzwerkkarte herauszufinden benutzt du für POSIX-Betriebssysteme(Linux,Unix,…) “ifconfig eth0” und für Windows “ipconfig /all” in einer Kommandozeile.

In vielen Situationen kann deine IP-Adresse nicht nur dir zugeordnet sein. Wenn du z.B. einen Router in deinem Netzwerk einsetzt oder einen Proxy verwendest haben mehrere Nutzer gleichzeitig die selbe externe Ip-Adresse! Diese Nutzer könnten somit auch das Installationsskript zugreifen.

Nach der Installation und nachdem du die install.php gelöscht hast, musst du diese zwei Zeilen wieder entfernen damit wieder jeder auf dein Wiki zugreifen kann.

Mit den folgenden Einstellungen (en) sollte man besonders sorgfältig umgehen.

(That is, file/directory creation modes.) Set them as restrictive as possible. This is an essential part of securing a DokuWiki installation! Please refer to the permissions page.

(Required - there's too much potentially dangerous information available here to expose in public)

In your Dokuwiki config directory, edit your conf/local.php file (create if not found) and add the line

$conf['allowdebug']  = 0;

This didn't work in my installation because the local.php file become owned by the apache user. However it included local.protected.php so I created that file and put the line in there. Seems to work but it would be great if this could be verified.

If you set up permission as on permissions page, you have got file conf/local.php owned by the apache user. Problem is, if you haven't root access. If you installed dokuwiki somewhere in your home, under your user, all dirs are owned by you. Setting permission for dokuwiki to work is just changing group for conf and givig group write access on conf. Default state after creation of local.php by apache is, that you can read and delete it, but cannot change. Solution is simple, open local.php in editor, cut text, store in some temporary location, then delete local.php and create new one with pasted text. Set group for this new one local.php as apache user, and give group write access. Done.

Stuff like external images, linked from a wiki page, are copied to the local web server via the lib/exe/fetch.php script, the purpose being to provide consistent performance and to be able to resize remote images. You may want to restrict how large the files pulled from remote sources are allowed to be using the $conf['fetchsize'] option (given in bytes). Setting it to 0 effectively disables caching of external sources.

Using mod_rewrite, we can force the login to use HTTPS, thus preventing clear text passwords on the wire.

Add these lines to your apache.conf:

RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteCond %{QUERY_STRING} do=log
RewriteRule ^(.*) https://%{HTTP_HOST}/$1 [R,QSA,L]

You may want to change ${HTTP_HOST} to ${SERVER_NAME}, where server name matches the hostname in your SSL certificate.

Posted by Travis Sidelinger: travis [at] ilive4code [dot] net - 2006Oct01

The login page is served when you hit logout as well, so replacing do=login with do=log(in|out) is a slight improvement.
— Gerard Neil 2007-01-27 04:01

Question: is it possible through mod_rewrite magic somehow drop the user back to non-ssl right after the login? — Alex Popov 2007-10-31 14:03

After some hacking, I figured this one out. To use non-ssl for all pages except the login/logout pages, insert the following after the lines above:

RewriteCond %{HTTPS} on
RewriteCond %{QUERY_STRING} !do=log
RewriteCond %{REQUEST_METHOD} GET
RewriteRule ^(.*) http://%{HTTP_HOST}/$1 [R,QSA,L]

Note the test for GET; without this, the login page will fail and drop you back to the main page (because it requires a POST to doku.php, which would otherwise be lost in the redirect).

— wirehead [at] notapattern [dot] net 2007-Jan-04 23:00

“Lost” cookie fix
I encountered a problem with the cookie that's set when you log in being “lost” when transitioning between HTTP/HTTPS. This applies to the 2007-06-26b release (and probably earlier ones). The problem is exhibited as follows – using the above code to rewrite the login/logout URLs to SSL-encrypted pages and then redirecting back to non-secure HTTP pages afterward, the cookie gets “lost”. What happens is that the cookie is being set with an absolute URL instead of a relative URL. So the cookie is only tied to the HTTPS version of the site; when going back to HTTP, you “never logged in”. Note that this applies when $conf['canonical'] = 0, which is the default.

To fix this, the code in inc/init.php needs to be changed as follows:

-  if (!defined('DOKU_COOKIE')) define('DOKU_COOKIE', 'DW'.md5(DOKU_URL));
+  if (!defined('DOKU_COOKIE')) define('DOKU_COOKIE', 'DW'.md5(DOKU_BASE));

Also I recommend the following rewrite conditions/rules to also encrypt the “update profile” page (where you can change your password) and the Administration menu, where stuff like the user manager resides.

# We want to encrypt all pages over which passwords might be sent
# Includes: login, logout, profile (password change), admin menu (user manager)
RewriteCond %{HTTPS} !on
RewriteCond %{QUERY_STRING} do=(log|profile|admin)
RewriteRule ^(.*) https://%{HTTP_HOST}/$1 [R,QSA,L]

# Change back to non-secure for all other pages
RewriteCond %{HTTPS} on
RewriteCond %{QUERY_STRING} !do=(log|profile|admin)
RewriteCond %{REQUEST_METHOD} GET
RewriteRule ^(.*) http://%{HTTP_HOST}/$1 [R,QSA,L]

I struggled with this for a while before finding the solution (which seems so simple!), so I hope that this helps to save someone from time and aggravation. I did STFW, but only found this with no solution…
— poonh [at] mcmaster [dot] ca 2008-Jan-23 18:25 EST

See this FAQ entry.

In addition to settings listed on this page, the following settings may impact security and/or privacy. This is not necessarily an exhaustive list.

• fullpath, signature, all authentication_options, usewordblock, mailguard, iexssprotect, htmlok, phpok, hidepages, safemodehack, ftp

The following steps are highly recommended - even if marked Optional, it's worth the effort.

The purpose is to move everything possible outside your document root¹⁾ — excepting those scripts which absolutely must be there.

It is proposed that, given a typical Unix / shared host account where your home directory is /home/yourname and your document root directory is, say, /home/yourname/www, you should create a directory /home/yourname/dokuwiki which would be outside of the document root directory, and locate parts of Dokuwiki under there, as described in the steps below.

IIS-Users:

• they don't need move the directories, only change then configuration for security/authentication.
• in the IIS open the “properties”-dialog of the below mentioned folder from the Wiki-Site
• then in the “security”-tab click open then “authentification”-dialog
• uncheck “anonymous-access”
• :::: names of dialogs, checkboxes,etc. was translated from german IIS-Version. And may differ from right names in the english IIS-Version.
• :: Not realy tested, but should work. So no warranty!

(Required - although it's protected by .htaccess there is no reason why you should ever leave this exposed publically)

Move the bin out the document root or simply delete it. This directory contains scripts intended for use on the command line only and should not be left exposed.

If you do not have shell access or have no reason to use these scripts (e.g. you don't know what they are for), you could also simply delete the directory - doing so will not break anything (they are not required for Dokuwiki to work).

(Optional - directory protected by .htaccess but this is not always a safe solution)

Move data, media and attic out of the document root.

The easiest way to do this is:

1. Move the data directory (and all its contents) out of the document root
2. Edit the savedir setting to point to the new location of the data directory.

For example, if the data directory is moved to /home/yourname/data, add the following line to conf/local.php:

$conf['savedir'] = '/home/yourname/data';

The media and attic directories reside within the data directory, so following the steps above will secure those as well.

(Optional - directory protected by .htaccess but this is not always a safe solution)

Move the config subdirectory out of your document root. This is a little harder to achieve in current Dokuwiki versions but the easiest approach right now is to use PHP's auto-prepend-file ini setting, to load a simple PHP script that defines a constant pointing at the new config directory location.

On a typical shared host, create a file like /home/yourname/dokuwiki/prepend.php containing just;

<?php
define('DOKU_CONF','/home/yourname/dokuwiki/conf/');

(Terminating PHP processing instruction deliberately left out - do not add this: ?> at the end)

Move the conf directory to /home/yourname/dokuwiki/ so it makes /home/yourname/dokuwiki/conf.

Now edit the .htaccess file in your document root (e.g. /home/yourname/www/.htaccess) and add the following;

php_value auto_prepend_file "/home/yourname/dokuwiki/prepend.php"

What this does is tell PHP to run the prepend.php script before any other script. By defining the constant, it overrides what later gets set by Dokuwiki's inc/init.php script.

(Optional - directory protected by .htaccess but this is not always a safe solution)

In theory there shouldn't be anything dangerous here but there's also no reason to leave this code publically exposed - better safe than sorry. Be warned this step pretty much requires shell access to the server - most of the other steps above could be managed purely with an FTP client.

Assuming you've performed the step to move your config directory out of the document root, simply update the prepend.php file with an additional line to become;

<?php
define('DOKU_CONF','/home/yourname/dokuwiki/conf/');
define('DOKU_INC','/home/yourname/dokuwiki/');

Move the inc directory to /home/yourname/dokuwiki to make /home/yourname/dokuwiki/inc. You also need to move the lib directory then create a symbolic link to it under you document root e.g.;

$ mv /home/yourname/www/dokuwiki/lib /home/yourname/dokuwiki
$ ln -s /home/yourname/dokuwiki/lib /home/yourname/www/dokuwiki/lib

This should place a symbolic link to the lib directory under your document root, while still allowing DOKU_INC to resolve correctly.

this should be merged into wiki:config:php and be linked from here.

The following are general “good practice”. A good read on locking down PHP in general is Chapter 3 of Apache Security, available in PDF form for free here.

Note that if you are running Dokuwiki / PHP on a server you fully control, you may want to consider a chroot jail. There are various ramblings online for how to do this but the most complete / accurate / effective it probably Apache + Chroot + FastCGI + PHP FAQ

You should be able to set them by editing your main .htaccess file at /home/yourname/www/.htaccess.

IIS-User-Approach:

• modify php.ini in then PHP-Installation-Directory (i.e. C:\Program Files\PHP\)
• For Error-Loggin you can use the System-Log (“error_log = syslog” in the php.ini)

(Optional this is a good idea - the more information you give an attacker, the easier it is)

Add the following to .htaccess in your public document root directory (e.g. /home/yourname/www/.htaccess - the directory thats directly exposed to http requests and contains index.php and doku.php)

# Disable display of public PHP error messages
php_flag display_errors "off"

# Log all PHP errors to a file in private directory ( and not in the Dokuwiki data dir either! )
# here you'd need to create the directory and the file then make sure the file has world write
# permissions
php_flag error_log "/home/yourname/logs/errors.log"

# Don't keep reporting the same error again and again (keep log file smaller)
php_flag ignore_repeated_errors On

# Dokuwiki generates a lot of notices... best prevent reporting them
# in .htaccess files E_ALL, E_NOTICE have no effect, you must use the
# values from http://www.php.net/manual/en/function.error-reporting.php
# E_ALL & ~E_NOTICE => 2047 - 8 => 2039 (Note: E_ALL is different for 5.2.x and above, see
# http://www.php.net/manual/en/ref.errorfunc.php#errorfunc.constants.errorlevels.e-all)
php_flag error_reporting 2039

You need to create the directory and log file above, which (logged in via shell) can be done like;

$ mkdir ~/logs
$ touch ~/logs/errors.log
$ chmod 662 ~/logs/errors.log

If PHP finds the file doesn't exist, it won't automatically create it for you (i.e. the error messages disappear into the void). Meanwhile you need to make sure it doesn't get too big (it will grow if you don't do something to stop it). A simple way to reduce it's size is;

$ tail -100 ~/logs/errors.log > ~/logs/errors.log

That takes the last 100 lines from the log and overwrites the original with them - you might place this in, say, a weekly cron job.

Instructions for dokuwiki running on Linux/Unix and Apache. Tested on Centos 4.4

Two options are very important in PHP regarding security: ²⁾

• safe_mode: which restrict the execution of system commands from PHP (works in PHP3, PHP4, PHP5)
• open_basedir: which restrict the PHP script to only open file from inside a directory

Add this lines to your httpd.conf, sometimes it can be added in the file /wiki/.htaccess too:

# dokuwiki is installed in       : /var/www/html/wiki/
# your php pear packages are in  : /usr/share/pear/
# php is installed in            : /usr/lib/php4/
# use a new tmp directory in     : /var/www/html/wiki/tmp/
<Directory /var/www/html/wiki>
    php_admin_flag safe_mode On
    php_admin_value safe_mode_exec_dir "/usr/lib/php4"
    php_admin_value safe_mode_include_dir "/usr/share/pear/"
    php_admin_value open_basedir "/var/www/html/wiki/:/var/www/wiki/:/usr/share/pear/"
    php_admin_value upload_tmp_dir "/var/www/html/wiki/tmp/"
</Directory>

Then, you should configure all the permissions of the wiki directory with this command in Linux/Unix:

# chown apache:apache -R /var/www/html/wiki/

If you don't have a shell account in your hosting provider or you use only ftp to upload dokuwiki, then all permissions should be configured automatically. There is no need to run the chown command in those cases.

Is the above line something one has to do with telnet? My presence provider doesn't provide a command line… Over-all, all I got out of this page was to delete the .bin directory and moving the ./data directory. By the way, I've been unable to delete the old ./data on the server with FileZilla; it tells me “directory not empty” and when I go to the subdirectories, and to the files in them, all my attempts to delete seem to result in PWD commands. No apparent way to get rid of them. The rest of the stuff on this page either didn't work for me, or was too obscure to follow. Need to explain things with dummies in mind. We dummies are a majority

Don't know wether there are ftp-clients with the ability to change owner and group attributes as with chown on the command line, but probably your provider will not grant you the right to change owner and group attributes of your files. This also may be the reason why you can't get rid of 'your' files in the data dir (presumably they aren't yours ). If you set the fmode/dmode param too restrictive (lesser okt. values than 666/777, esp. in 3rd position) you won't be able to del files written and hence owned by the webserver (i.e. files created via dokuwiki) cf. permissions, fmode and hosted /Leif

Assuming your webserver is apache and is running as the user apache. This is needed because safe_mode runs the PHP script as the user that is the owner of the .php files.

Dokuwiki has lots of community contributed plugins. These are distributed separately from Dokuwiki in an entirely ad-hoc manner, and are not subject to the same degree of attention / review that the core Dokuwiki code base gets. Some tips / things you should be aware of;

• If you can, review the plugin source code yourself, before installing it.
• If in doubt, ask on the mailing list.
• Plugins are installed under the Dokuwiki lib directory, which is required to be exposed under your document root. You need to review very carefully what code a plugin contains, an lock down with .htaccess files as appropriate.
• Plugins are authored by developers not directly related to the Dokuwiki project - they may have malicious intent or may host the plugin source code on a server which has been compromised. Be careful who you trust

Why couldn't I define DOKU_PLUGIN in prepend.php, as with other constants, and put it outside the document root as well? – I see, some plugins link to files in their directory, such as the icons in the note plugin. / Viktor

Question: Could a setup like Mozilla's https://addons.mozilla.org be something for DokuWiki ?
That site hosts all the reviewed plugins for the Mozilla products (eg. Firefox, Thunderbird). Only stable and secure plugins make it to that site. Users know when they install plugins from that source that they are relatively safe opposed to obscure third party sites.
The bigger DokuWiki gets, the more important it is to safeguard for plugin vulnerabilities.
charlieMOGUL 07-12-2006 10:00 GMT +01:00