Learn about DokuWiki
Learn about DokuWiki
When certain code examples are entered on a page, the Server returns a “Error 403 – Forbidden”, “Error 406 – Not Acceptable”, “Error 403 – Forbidden”, “503 – Service Temporarily Unavailable” or similar errors. What's the problem?
This is usually a problem caused by overly-restrictive security policies set in the webserver (usually mod_security) or an application level Firewall (Sophos Firewall Webapp Control is known to be problematic).
There is no way to fix this in DokuWiki, because it is not a problem caused by DokuWiki itself. You need to check your webserver or application firewall audit logs to identify the problematic rule and disable it.
Commonly problematic words are parts of SQL statements, mail or UNIX commands like:
Sometimes the problem also occurs when certain parameters are passed in the URL, especially when they contain external URLs like when using external images that are loaded from DokuWiki's image cache system in
mod_security can be disabled at a user or hosted domain level. The following two lines can be inserted in an
.htaccess file that is saved in the
SecFilterEngine Off SecFilterScanPOST Off
–Chris Freyer 7/23/09
This could be a trade off between security and usability, although it is completely possible to have your DokuWiki work with mod_security, by spending time to update your security rules.
On Apache2, you can disable mod_security for a specific path inside the VirtualHost block inside your site files (for instance, in /etc/apache2/sites-enabled/my_host.tld.conf), by specifying the directory that DokuWiki is in and disabling the mod_security engine on that path.
// /etc/apache2/sites-enabled/my_host.tld.conf // Rather than using .htaccess for the entire domain. <VirtualHost my_host.tld:443> <Directory /var/www/my_host.tld/my_wiki_path> <IfModule security2_module> SecRuleEngine Off </IfModule> </Directory> </VirtualHost>
However, this means that for any undiscovered vulnerabilities in DokuWiki, mod_security will do nothing to prevent them from being exploited, which is not recommended security practice. For those who wish to maintain security of their installation, it is recommended to override the specific filters on for the doku.php file within mod_security's rules, so that it will allow for preview and editing of files, but remain enabled for the remainder of the site.
In some cases it is not allowed to disable the
mod_security option in the
.htacces file. You have to contact your provider and ask for disabling some rules. In my case:
Not having worked on my wiki site for some months, my attempts to edit and then save produced the problem described above. Working with my site provider, I created a userid for the technician, who then diagnosed that the rule being triggered was “checking for 4 or more URLs in a single post”. This rule was safely disabled.
We had suspected that the rule being triggered was:
Atomicorp.com WAF AntiSpam Rules: Possible Spam: Multiple embedded urls in argument (Disable if you wish to allow 4 or more URLs in a post) .
Changing the setting on that one rule was done. A warning was given on removing mod_security:
While many sites (such as forums) would need this rule enabled to prevent spamming on their forums and usually limit the number of urls a post can have, sites that have posts with a large number of links in them (like wikis) can easily trigger this rule and may need it disabled.
Mod_security is m to the type of attack that the particular rule prevents, but disabling one rule is better then disabling all.
A little more problem determination gave a better solution.