It's better when it's simple

Herramientas de usuario

Herramientas del sitio

Barra lateral

Esta traducción es más antigua que la página original y podría estar obsoleta. Ver lo que ha cambiado.
Traducciones de esta página?:

Learn about DokuWiki

Advanced Use

Corporate Use

Our Community

Follow us on Facebook, Twitter and other social networks.

Our Privacy Policy


¡Esta es una revisión vieja del documento!


NEEDSATTENTION! (needs some refactoring)

Alertas de seguridad

Para informarse sobre los problemas de seguridad con DokuWiki subscribase al proyecto DokuWiki en (asegúrese de dejar mensajes de correo electrónico de suscriptor). Necesita una cuenta Freshmeat para ello. Todos los problemas de seguridad están disponibles en el sistema de seguimiento de errores bugtracking system.

Revelaciones de Seguridad

Si usted encuentra un problema de seguridad con DokuWiki, ​​por favor primero contacte con los mantenedores en privado .

  • Desarrollador principal: Los detalles de contacto con Andi están disponibles Aquí.
  • ¿Quién si no?

Puede alternativamente considerar la publicación de un bug, en un espacio público.

Secure the DokuWiki installation during configuration

By default, DokuWiki installations allow anyone to access the wiki and modify pages. As soon as you install DokuWiki, it's possible for someone to access the wiki. While you are performing the initial configuration, you should exclude external visitors.

If you are using the Apache webserver, this can often be accomplished by adding the following lines to the top of the .htaccess file in the root of the DokuWiki installation:

Deny from all
Allow from

Cambie “” por su dirección IP, puede determinarla accediendo a

:!: Si su dirección IP está compartida con otros, they will also be able to access DokuWiki. This may be the case if you are behind a proxy or wireless router (at work, at school, through ISPs such as AOL, etc.)

Don't forget to remove the lines added to the .htaccess file before you launch your

Configuración de seguridad de Dokuwiki

Las siguientes opciones de configuración deben ser tratadas con especial cuidado durante la configuración de Dokuwiki.

fmode / dmode

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

Disable Debugging output

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

:!: 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 directories are owned by you. Setting permission for DokuWiki to work is just changing group for conf and giving 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.

Prevención de copiado de contenido remoto

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.

Forzar HTTPS en el Login

Usando mod_rewrite, podemos forzar al login a usar HTTPS, así prevenimos que las contraseñas viajen sin protección por la red.

Añadir éstas líneas a la configuración de Apache (apache.conf):

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

Puede querer cambiarse ${HTTP_HOST} a ${SERVER_NAME}, cuando el nombre del servidor se equipara con el hostname en el certificado SSL.

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

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
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.
Updated 2008-03-28: minor change to RewriteRules. Previously they would not work properly if the wiki was hosted in a subfolder of the web server root. Now they should work fine with multiple DokuWiki installations, each in separate subfolders on the same web server.

# 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}%{REQUEST_URI} [R,QSA,L]

# Change back to non-secure for all other pages
RewriteCond %{HTTPS} on
RewriteCond %{QUERY_STRING} !do=(log|profile|admin)
RewriteRule ^(.*) http://%{HTTP_HOST}%{REQUEST_URI} [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 search the website, but only found this with no solution…
poonh [at] mcmaster [dot] ca 2008-Jan-23 18:25 EST

A note on the “lost cookie” problem – this happened to me after an upgrade, and I eventually figured out that a new security setting was added. If you are serving the wiki over HTTP, but just securing the login pages, the cookie will now be “lost”. This is because the cookie by default is now being set in “secure” mode, which means it can't be sent over HTTP if it was set over HTTPS. To fix this, go into settings and disable “securecookie”. More info (and security thoughts):,5wirehead [at] notapattern [dot] net 2009-Feb-03 13:00 EST

Thanks for posting this solution, poonh, it was very helpful to me :-). The only thing is that now I am getting a “Warning: Contains unauthenticated content” warning in Firefox (equivalent in IE). This is because the requests for js.php and css.php are being redirected back to the non-secure URI. Might I suggest the following additions to the “send back” code:-

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

Is there a security problem with doing this? Is there a security problem with leaving it as-is? Personally, I just prefer the thought of it being one way or the other. — Andy Turner 2008-Mar-25 13:48 GMT

Theoretically I don't think it really matters (security-wise) if some files are retrieved over an unencrypted connection, because normally they would be anyway and there's nothing confidential there; personally I just want to ensure that passwords are encrypted in transit. The additions you suggested above aren't sufficient to solve the problem (they only affect “send back” as you indicated); they don't address the mixed HTTPS/HTTP retrieval of content during the first redirect.

Is there mixed retrieval on the first redirect? I don't know this for sure, I'd be glad for somebody to explain it to me… anyhow, I thought of it like this: you request the login page via HTTP, and the server redirects you to the HTTPS login page. Only when you have this can you know which JS, CSS etc files to request; if these are given as links relative to the current page, your browser must then request them from the same (i.e. HTTPS) server. Without the changes I suggest, these JS etc requests are redirected back to the HTTP server; with these additions they are returned via HTTPS. So I'm not sure where mixed requests you mention occur. — Andy Turner 2008-Mar-28 17:45 GMT

I've spent a few more minutes looking at this. Page contents such as the numerous JavaScript and CSS include files are retrieved in plaintext, hence the browser warning for mixed HTTPS/HTTP. I do understand what you're saying about the relative URLs. The problem is that the exceptions you've included in the RewriteCond's you added aren't sufficient. You can observe the (numerous!) non-secure HTTP GET requests issued by your web browser if you use packet capture software like Wireshark. You'll also need to have exceptions for any JPGs, PNGs, ICOs, GIFs, and more. I don't know at what point the number of rewrite condition checks has a tangible performance impact but you probably don't want to have so many. There may be a more elegant way to deal with this; I haven't given it enough thought.
poonh [at] mcmaster [dot] ca 2008-Apr-01 02:23 EDT

Here is another take on split http/https operation:

# Send to https on attempting to login etc.
RewriteCond %{HTTPS} !=on
RewriteCond %{QUERY_STRING} do=(admin|log|profile)
RewriteRule ^(.*) https://%{HTTP_HOST}/$1 [R,QSA,L]
# On showing, send back to http.
RewriteCond %{HTTPS} =on
RewriteCond %{QUERY_STRING} (do=show|^$)
RewriteRule ^(.*) http://%{HTTP_HOST}/$1 [R,QSA,L]

Does not seem to have any issue (cookies, fetching other objects on the page, etc), and the main thing is for 'regular page views' to go non-https (so the body of the wiki is cacheable). Editing, searching, other operations are less important.

In some cases, the above lines seem to be incomplete. In fact, Dokuwiki may not complete user authentication. So, you could add one more condition for the HTTPS rewrite rules to fix this:
thomas [dot] chemineau [at] gmail [dot] com 2009-Mar-31 13:02 GMT

# On showing, send back to http.
RewriteCond %{HTTPS} =on
RewriteCond %{QUERY_STRING} (do=show|^$)
RewriteCond %{THE_REQUEST} !^POST
RewriteRule ^(.*) http://%{HTTP_HOST}/$1 [R,QSA,L]

Setting some wiki pages to read-only

Other settings

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

Cleaning the access control lists

When deleting pages or users, the access definitions for them remain. This can be considered a feature or a security risk. If you want to clean up the ACL, you can run the script clean_acl.php .

Securing the install directories

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


  • They don't need to move the directories, only change the configuration for security/authentication.
  • In the IIS console, open the “Properties” dialog of the virtual directory for the wiki site
  • Then, in the “Directory Security” tab, click the Edit button in the “Anonymous access and authentication control” section
  • In the “Authentication” dialog, uncheck “Anonymous access”, then click OK on both dialogs
  • :!: Not really tested, but should work. So no warranty!

Confirming Apache htaccess works

The direct reading of data files like is prevented by dokuwiki through the .htaccess file in data/ that says:

 order allow, deny
 deny from all

FIX ME: There is no such file “start.txt” in my ./data dir. Please check this point. IF i understand this correctly, a simple visitor should not be able to read the content of a dir like http://localhost/dokuwiki/conf/ - if you can see files in here you should go and fix this. make sure your webserver does not list the files in here or anywhere in a dokuwiki directory.

This works in most of the installations (and on apache default installations), but some servers are configured in a way not to allow this feature in .htaccess. Test this by trying to access the start.txt. If htaccess-deny works the browser should yield a 403 HTTP-error.

In other cases ⇒ Read under URL rewriting how to configure Apache so that it honors htaccess configuration and prevents the reading of files in and below data/.

The ./bin directory

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

:!: Move the bin out of 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).

The ./data directory

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

The ./conf directory

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


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

2008.12.28 Following the instructions above removed all CSS styling. The fault seems to be related to the php_value auto_prepend_file line. Even prepending <?php alone with no future instructions was enough. Instead, go into inc/init.php and redefine DOKU_CONF as follows:

  // define config path (packagers may want to change this to /etc/dokuwiki/)
  if(!defined('DOKU_CONF')) define('DOKU_CONF',fullpath(dirname(__FILE__).'/../../').'/dokuwiki/conf/');

where __FILE__ refers to the location of init.php.

The ./inc directory

(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 publicly 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;


Move the inc directory to /home/yourname/dokuwiki to make /home/yourname/dokuwiki/inc.

FIXME Moved all other directories successfully but the ./inc directory turned out to be not so easy. DokuWiki started looking for plugins and includes where they weren't and, particularly, it seemed to be looking for the ./lib directory in the same location as my ./inc directory . It can probably work but there are a few more definitions to be added to prepend.php, such as, possibly having to point the contents of the ./inc directory back to the web-accessible root. I did that for plugins as follows:


There are a few other functional directories inside the ./lib directory which are misreferenced when ./inc is moved out of the web root but I did not try to fix them all. As soon as I moved the ./inc directory back to my web root and deleted define('DOKU_INC','/home/yourname/dokuwiki/'); from prepend.php, everything went back to normal.

Another possibility (NOT TESTED! A developer needs to comment if this is at all doable!) is to move the ./lib directory out of the web root as well but prepend.php will need to be modified accordingly.

General PHP Settings

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


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

Private Error Logging

(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 that's 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 directory 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
# E_ALL & ~E_NOTICE => 2047 - 8 => 2039 (Note: E_ALL is different for 5.2.x and above, see
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.

Enable safe_mode and open_basedir

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

Two options are very important in PHP regarding security: 2)

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

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.

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

Warning on Plugins

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 that has been compromised. Be careful whom you trust


Block useragent libwww using .htaccess (also implement the 4G):

SetEnvIfNoCase User-Agent "Jakarta Commons" keep_out
SetEnvIfNoCase User-Agent "Y!OASIS/TEST"    keep_out
SetEnvIfNoCase User-Agent "libwww-perl"     keep_out
SetEnvIfNoCase User-Agent "MOT-MPx220"      keep_out
SetEnvIfNoCase User-Agent "MJ12bot"         keep_out
SetEnvIfNoCase User-Agent "Nutch"           keep_out
SetEnvIfNoCase User-Agent "cr4nk"           keep_out
deny from env=keep_out

I have the following code in a file and just include it at the top of the entry page to my site. (i.e. index.php). However it will not help when someone it attacking a file that does not have the include in it. Doing the ban via .htaccess would be a better way to filter out these requests. But this might help while we wait for someone who knows how to create the filter to post. 3)

  $aBadUserAgents   = array();
	$aBadUserAgents[] = 'libwww';
	foreach ($aBadUserAgents as $variable) 
	    if (strpos($_SERVER["HTTP_USER_AGENT"], $variable) !== false)
	        die(header("HTTP/1.0 403 Forbidden"));
the filespace directly accessible via normal web browsing
Note: use of safe_mode / open_basedir is a subject for debate. Fundamentally it is not 100% secure (lots of workarounds such as DokuWiki's own safemode bypass) and it sometimes complicates configurations / installations of some applications, etc. See PHP's safe_mode or how not to implement security. Furthermore, safe mode has been dropped from PHP6, it's already gone from the PHP6 CVS branch, if general you're probably better of chrooting your PHP (see link in this page here)
es/security.1358419249.txt.gz · Última modificación: 2013-01-17 11:40 por