User Tools

Site Tools


dokuwiki_security

If you want to send us your comments, please do so. Thanks
More on comments


Dokuwiki security

Introduction

This is a redacted copy of the Dokuwiki security page

This page is work in progress

When your Dokuwiki instance is misused

How to notice something is wrong

On a regular basis check

  • the emails being sent log or let a program do it for you. If you are using Direct Admin you can look in E-mail management | E-Mail Accounts | E-Mail Usage. Beware that there can be a lot of pages. Check the last page by clicking on Last Page
  • if user accounts are made which should not be there in Admin | User Manager

Remedies

  • Remove users which should not be there in Admin | User Manager. If there are many users you can also edit the file conf/users.auth.php
  • Make sure you have the rights in the Admin | Access Control List Management set appropriate
  • In Admin | Configuration Manager goto Authentication | disable actions Disable DokuWiki actions and put a checkmark at Register and Subscribe/Unsubscribe
  • Crude: Remove (make sure to have a copy somewhere) inc/Mailer.class.php
  • If you are running LiteSpeed webserver.htaccess files may not do what is expected
  • Clean the data/meta/_dokuwiki.changes file
  • Check all directories for files and directories which should not be in it
  • Follow the instructions below

Question

  • How is it possible, is it possible that a user which has Read only permissions can send emails via dokuwiki?

Dokuwiki on security

The redacted Dokuwiki page

DokuWiki is a web application and is often used on public servers, reachable from the Internet. This means it is at a greater risk to be attacked by malicious people than, for example, a local application on your desktop system.

DokuWiki is developed with security in mind. We try to find a balance between user-friendliness and security but favor security when no satisfying compromise can be found.

This page should give you an overview on what aspects you should have an eye on to make sure your DokuWiki is secure.

Reporting and Notifications

When you discover a security issue in DokuWiki, please notify us. The preferred ways to do so are:

The first two ways should be preferred except for very serious bugs where making the bug public before a patch is available could endanger DokuWiki installations world wide

  • All previous security issues can be seen in the bugtracking system
  • Depending on the severity of a found security issue it will be fixed in a future release (on very minor issues) or a bugfix release will be made. In the latter case users will be informed through the update check mechanism
  • You should always run the most current release of DokuWiki as there are no security fixes released for older versions.

Web Access Security

DokuWiki stores configuration and page data in files. These files should never be accessible directly from the web. The distribution tarball contains a set of .htaccess files which usually tell the Apache web server to deny access to certain directories.

If you don't use the Apache web server or your Apache does not use .htaccess files you need to manually secure your installation

The following directories should not be accessible from the web. They need to have 0700 permissions. When accessed from the web via, for example https://4t6.nl/data/ a 403 Forbidden Access to this resource on the server is denied! error should be the result

  • data
  • conf
  • bin
  • inc (isn't dangerous when accessible, though)
  • vendor (leaks info about your environment)

To check if you need to adjust the access permissions try to access http://yourserver.com/data/pages/wiki/dokuwiki.txt. You should not get access to that file this way.

(More about permissions - install:permissions - but it does not deal with the lack of detailed information about Dokuwiki's directory permissions.

If your directories are not properly secured, read the following subsections on how to do that.

EDIT (2017-08-28): If you give 0700 permissions to bin directory, you don't have access to the page edit toolbar…

EDIT (2017-09-26): There are a mistake between data privileges in this page and data privileges in install:permissions. A directory cannot be writable and not writable by the web user at the same time. Please admin team, fix this and remove this comment

EDIT (2018-05-01): Check that you cleared browser cache after setting all up. Security warning can be cached, so you'll probably wasting your time trying to make things work.

Deny Directory Access in Apache

The simplest way is to enable .htaccess support in your Apache configuration. Please see the Apache .htaccess Tutorial.

DokuWiki already comes with correctly configured .htaccess files. The contents of a .htaccess file to block all access to the directory it is in should be as follows (valid for both Apache 2.2 and 2.4):

<IfModule !mod_authz_core.c>
  Order deny,allow
  Deny from all
</IfModule>
<IfModule mod_authz_core.c>
  Require all denied
</IfModule>

Remark : Using apache2 on Ubuntu, the .htaccess does not work until you activate the 'mod_rewrite' in apache2 (sudo a2enmod rewrite && sudo service apache2 restart)

It seems that Apache2 in general, or it might be specifically to Ubuntu, is configured slightly differently than Apache1.x.

In the /etc/apache2/sites-available (or you need to modify the file default, e.g. 000-default.conf) (or the file default-ssl if you use https rather than http)

There you'll find:

NameVirtualHost *
<VirtualHost *>
        ServerAdmin admin@site.com

        DocumentRoot /var/www/
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride none
                Order allow,deny
                allow from all
        </Directory>

Default for AllowOverride in the <Directory /var/www/> is (double) none, should be (double) all

/etc/init.d/apache2 reload to refresh your apache configuration and your .htaccess files should now work.

:!:/etc/init.d/apache2 reload may not work. You can try sudo service apache2 restart instead.

(See http://ubuntuforums.org/showthread.php?t=47669 for the full thread)

[you can make this change also for the particular directory containing your DokuWiki installation, ie. /var/www/path-to-dokuwiki instead of changing that globally]


The other way is to use LocationMatch directive inside VirtualHost definition - it's a little bit more efficient than .htaccess. Just below Directory directive add:

<LocationMatch "/(data|conf|bin|inc|vendor)/">
    Order allow,deny
    Deny from all
    Satisfy All
</LocationMatch>

However see the “What to use When” section here http://httpd.apache.org/docs/2.4/sections.html#file-and-web for a statement that “Location” directives should not be used for protecting filesystem objects, only virtual (e.g. database-generated) paths. IMO if .htaccess isn't available or sufficient, then putting directory-specific restrictions directly in the hosts conf file would be the safest approach. This http://ada.adrianlang.de/dokuwiki-php-execution#solutions_in_the_configuration seems a solid approach - but this document should be “canonical”.


The above could cause a problem if you have another “root” that includes the directories data|conf|bin|inc|vendor. For example another wiki installation. You can avoid this problem by extending your LocationMatch within your wiki installation folder.

        <Directory /var/www/dokuwiki>
            order deny,allow
            allow from all
        </Directory>

        <LocationMatch "/(data|conf|bin|inc|vendor)/">
            order allow,deny
            deny from all
            satisfy all
        </LocationMatch>

Deny Directory Access in Lighttpd

.htaccess files are Apache config files. lighttpd does not support them

URL re-write gives deny access to the directories above (data|conf|bin|inc|vendor). In /etc/lighttpd/lighttpd.conf add the following URL rewrite rule. (The Dokuwiki files are installed under http://domainname.tld/dokuwiki/ )

url.rewrite-once = ( "^/dokuwiki/(data|conf|bin|inc|vendor)/+.*" => "/nonexistentfolder" )

Uncomment or add “mod_rewrite” in the server.modules section. It should look like this

server.modules += (
     "mod_compress",
     "mod_dirlisting",
     "mod_staticfile",
     "mod_rewrite",
)

This is not sufficient when Vivaldi and probably other Chromium based browsers are used. When combined with “mod_access” it does keep people out. More mod_access examples are available on the mod_access page
In /etc/lighttpd/lighttpd.conf “mod_access” should be in the “server.modules = (” section. It should look like

server.modules = (
      "mod_indexfile",
      "mod_access",
      "mod_alias",
      "mod_redirect",
)

Maybe also needed are

      "mod_status",
      "mod_cgi",
      "mod_accesslog"

For security also add

$HTTP["url"] =~ "^/dokuwiki/(data|conf|bin|inc|vendor)/+.*" {
    url.access-deny = ("")
}

to /etc/lighttpd/lighttpd.conf and save it
Do systemctl restart lighttpd to reload /etc/lighttpd/lighttpd.conf and start lighttpd if it was not started
Do systemctl status lighttpd

Rename data Directory

Securing the data directory is most important. If you cannot move directories out of the webserver (see below) or can't configure your webserver to deny access (see above), then you should at least make it harder to guess the name of your data directory.

To do so, rename your data directory to something cryptic (eg. a long row of letters and numbers) and reconfigure your config:savedir option in your conf/local.php file.

Move Directories out of DocRoot

The most secure way to avoid any access to the mentioned directories is to move them outside the so called “Document Root” of your Webserver.

WARNING: If you are planning to use the installer, you need to install your wiki executing the install.php script first before you can do this step. If the Move Directories operation is done before, the installer execution will fail.

data Directory

  1. Move the data directory (and all its contents) out of the document root
  2. Edit the config: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';

conf Directory

  1. Move the conf directory (and all its contents) out of the document root
  2. Create a file named preload.php inside the inc directory and set the DOKU_CONF define to the new location of the conf directory.

For example, if the conf directory is moved to /home/yourname/conf, create the following inc/preload.php:

inc/preload.php
<?php
// DO NOT use a closing php tag. This causes a problem with the feeds,
// among other things. For more information on this issue, please see:w
// http://www.dokuwiki.org/devel:coding_style#php_closing_tags
 
define('DOKU_CONF','/home/yourname/conf/');

bin Directory

The bin directory contains CLI tools. If you don't have shell access on your server anyway you can simply delete the directory and its contents. Otherwise just move it out of the document root. No further configuration needed.

inc Directory

There is currently no easy way to move this directory out of the document root. But since it doesn't contain any sensitive data it isn't worth the effort to try anyway.

DokuWiki Configuration Settings

DokuWiki contains several configuration settings that have an impact on various security aspects of the installation. Please refer to the documentation of each setting to learn what they do and what suggested settings are.

Plugin Security

DokuWiki has lots of community contributed plugins. Plugins add new functionality to DokuWiki by adding new code. This means the code has practically any access to your server. Additionally plugins are distributed separately from DokuWiki in an entirely ad-hoc manner. They are not subject to the same degree of attention and review that the core DokuWiki code base gets. So security precautions are necessary before installing a plugin.

Here are some tips to help you with choosing the plugins you install.

  • If you can, review the plugin source code yourself, before installing it.
  • If in doubt, ask on the Dokuwiki.org mailing list.
  • Plugins are installed under the DokuWiki lib directory, which is directly accessible from the outside. Review what a plugin contains and lock down access with .htaccess files as appropriate.
  • Plugins are authored by developers not directly related to the DokuWiki project - they may be inexperienced, have malicious intent or may host the plugin source code on a server that has been compromised. Be careful whom you trust!
  • Review the plugin page for mentioned security warnings and upgrade the plugin when new releases become available.

See also: How to report security issues in plugins

Access Control

With Access Control Lists (ACL) you can restrict which pages and/or namespaces users have access to. You can give read and write permissions depending on the user group or single users.

Additional Reading

Here are a few more internal and external pages related to security.


Main subjects on this wiki: Linux, Debian, HTML, Microcontrollers, Privacy

RSS
Disclaimer
Privacy statement
Bugs statement
Cookies
Copyright © : 2014 - 2024 Webevaluation.nl and the authors
Changes reserved.

This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.More information about cookies
dokuwiki_security.txt · Last modified: 20-04-2022 14:38 by wim