Dokuwiki: Mozilla Observatory/Set more security headers

[robinro]

Mozilla published a new tool to judge webpage security. They complain about a couple of http headers missing from dokuwiki, see:
https://observatory.mozilla.org/analyze.html?host=www.dokuwiki.org

In details those are:

• Strict-Transport-Security
• Content-Security-Policy
• X-Frame-Options
• X-XSS-Protection
• X-Content-Type-Options

While the ssl related ones are maybe setup-specific and are easily set in the webserver config, it might be a good idea to set the others by default or at least provide an option to set them.

[SFITCS]

I agree they'd be nice to see implemented at dokuwiki.org - and SSL (letsencrypt?). But most of them would be nice to see also implemented in the stock dokuwiki build as part of _.htaccess.dist_ or an optional _dokuwiki.conf_ (for apache2 sites-available).

The following can be added to _httpd.conf_ configuration files, _.htaccess_, or inside virtualhost sections. Note that _mod_headers_ must be enabled.

Strict-Transport-Security

_Header set Strict-Transport-Security "max-age=631138519; includeSubDomains"_

Content-Security-Policy

_Header add Content-Security-Policy "default-src 'self'"_ (see end of this post for Google Analytics).

X-Frame-Options

_Header set X-Frame-Options "DENY"_

X-XSS-Protection

_Header set X-XSS-Protection "1; mode=block"_

X-Content-Type-Options

_Header set X-Content-Type-Options "nosniff"_
(DEPRECATED) _Header add X-Content-Security-Policy "default-src 'self'"_

Additionally:-
Header add X-WebKit-CSP "default-src 'self'"

I'm guessing you also noted the lack of SRI (and SRI fallback) - I don't believe it's needed as the default DokuWiki scripts are from the same source. However - dokuwiki.org uses Google Analytic scripts which _might_ be improved with an integrity hash, and will definitely need a modification to Content-Security-Policy e.g.:-
_Header add Content-Security-Policy "script-src 'self' www.google-analytics.com ajax.googleapis.com"_

[glensc]

well. should the configuration be done on webserver level or dokuwiki (php)?

if they need to be set on html pages, i would use dokuwiki code as it's more dynamic and centrally controllable (more coverage to get it done on more dokuwiki installations). but if the headers need to be set on all resources, including static resources. then indeed, need to use webserver config.

[glensc]

there's also possible for dokuwiki some admin page to generate neccessary webserver config that admin can copy and paste into webserver config

[SFITCS]

Thanks for you fast response.

The OP was just referring to dokuwiki.org - making more work was my fault.

For dokuwiki.org it would be optimal to do it in the webserver configuration files (_.htaccess_ chews more resources).

For DokuWiki it would have the widest application if added to _.htaccess.dist_, as I guess most DokuWiki users don't have access the webserver configuration.
I really like your idea of adding the capability to generate those directives in Admin. If you did that, perhaps add the same directives to _.htaccess.dist_ - but comment them out so they are optional(?).

I haven't checked other distributions, but Debian has some of those options in _/etc/apache2/conf-available/security.conf_ by default (though commented out) - in most cases IMO that's the best place to set them, but I haven't sampled enough usecases the be certain they shouldn't just be deployed as Directory directives (e.g. _X-Frame-Options_).

_X-Frame-Options_ is tricky as some DokuWiki users will use frames and "_DENY_" will stop that, whereas "_SAMEORIGIN_" will allow from the same site (I'd go with the secure as a default, _DENY_).

_Content-Security-Policy_ and the somewhat deprecated _X-WebKit-CSP_ is also tricky - as it depends what scripts are added to DokuWiki - the examples I gave are safe for a default DokuWiki as it doesn't call off-site scripts.

I can try and provide some informative comments for _.htaccess.dist_/Admin Directives page/ or a DokuWiki.org security document, but I won't have much time in the coming week. Anything I wrote between now and then would be, um, less than succinct - and it's only going to be useful if simple and unambiguous.

[glensc]

actually i thought i was commenting on #967, which was general approach, not dokuwiki.org :)

[SFITCS]

[shrug] I'm an optimist.

[t2d]

I believe it makes no sense to improve it just in the dokuwiki.org config. The software should deliver safe and sane defaults for everyone. Therefore, I believe .htaccess ist the way to go.

[glensc]

@t2d you misunderstood, i offed to set the headers in:

1. dokuwiki core (index.php in other words)
2. .htaccess

for "1." - is it sufficient to set the headers on html documents only. if no then this option goes out.

as "1." has better coverage and control, not everybody knows or has access to configure .htaccess, and there are more webservers out there than Apache, and if the values are dynamic, (Content-Security-Policy "script-src 'self' www.google-analytics.com ajax.googleapis.com) then this allows it to be configured from conf/local.php

and even if the headers must be configured in webserver (can't be done in dokuwiki), then we can add the admin page which can dynamically provide sample config to be pasted to webserver config

[SFITCS]

Agreed Glen (make the changes to DokuWiki, which will then apply to dokuwiki.org).
IMO _.htaccess.dist_ should include the most secure defaults, but as they are not going to suit everyone I'd suggest that the comments in _.htaccess.dist_ include a link to somewhere on DokuWiki.org (https://www.dokuwiki.org/security?) where more detailed information can be found about those configurations - and how to use them in the webserver configurations, instead of _.htaccess_ for those that do have access.

Would it also be possible to make the first comment in _.htaccess.dist_
## Set the permissions on this file to 440
?? I know it's common to use lower security (and take advice from random websites) - but there's no compelling reason I can think of - i.e. I don't know of any DokuWiki plugins that rewrite the base _.htaccess_ file.

e.g. then _head -n4 .htaccess.dist_ would give:

## Set the permissions on this file to 440
## See https://www.dokuwiki.org/security for more information about these settings.

## Enable this to restrict editing to logged in users only

[glensc]

@SFITCS you're also locked in about using .htaccess, do you know can it be set in php headers? or it _must_ be set for any resource (including static files)?

also what's with the 0440 file permission? usually the files need to be chmod 0644 because webserver run usually different user than the file owners in unix filesystem.

[SFITCS]

Sorry Glen, I misread/understood. I'm not certain if it's possible to set the options in dokuwiki core, I'd have to test.
If it is possible:-

• that is the best place to provide those options (most likely to implemented by the widest number of DokuWiki users)
• requires less server resources than .htaccess (the same as configuring in the main web server configurations)
• would/should work with all webservers

[SFITCS]

what's with the 0440 file permission? usually the files need to be chmod 0644 because webserver run usually different user than the file owners in unix filesystem.

Most use virtual hosting and suexec - so webserver runs with user permissions.

[SFITCS]

Elan - do you have compelling reasons for granting read access to Others - and write access to the Owner (other than convention)??
I can understand write access to Owner - _if_ it's something like WordPress, and a security plugin that changes .htaccess is installed... otherwise I don't understand your reasoning as it then relies on a main conf directive to protect _.htaccess_ from tampering or reading (I can be a bit thick).

[glensc]

@SFITCS the most coverage as said is to set the headers in dokuwiki core (dokuwiki php code), where in codebase it exactly lands i'm not sure. probably inc/init.php as init_hsts() function.

for testing you can add beginning of /doku.php lines like:

header("Strict-Transport-Security: max-age=631138519; includeSubDomains");
header("Content-Security-Policy: default-src 'self'");
//header("Content-Security-Policy: script-src 'self' www.google-analytics.com ajax.googleapis.com");
header("X-Frame-Options: DENY");
header("X-XSS-Protection: 1; mode=block");
header("X-Content-Type-Options: nosniff");
header("X-Content-Security-Policy: default-src 'self'");
header("X-WebKit-CSP: default-src 'self'");

you get the gist, see also header() method documentation.

[glensc]

file permission of .htaccess is totally out of scope of this issue, but i answer anyway:

in Apache, .htaccess needs to be readable for webserver to process it. in typical installation webserver user-id is www-data, the files are installed as my user (or root), so for webserver to be able to process .htaccess it needs to be accessible for webserver process. if you need to protect the file being accessible over web, use Deny from all Apache config.

also there should be no write access for the .htaccess file by webserver process. you as admin should be modifying it, not web scripts.

and if you want to be extra secure, you should disable processing local .htaccess files at all (AllowOverride None), and configure the directives in main apache config instead (/etc/apache2/*). this of course loses flexibility, so it's usually enabled.

[SFITCS]

Test of headers show they work fine in default Debian Jessie test VPS (see attached)
They were added to _httputils.php_ as _doku.php_ didn't look like the right place to insert them (warning it was a quick and dirty

hack).

Many thanks.

And agreed, _.htaccess_ permissions is out of scope if you are not planning on adding the directives to them, and I don't intend to start a flame war of opinions over something that's trivial to demonstrate :)

from the test VPS:-

ls -al .htaccess
-r--r----- 1 www-data www-data 1744 Oct  1 11:08 .htaccess

DokuWiki_headers_test.zip

[glensc]

you have:

$ ls -al .htaccess
-r--r----- 1 www-data www-data 1744 Oct  1 11:08 .htaccess

but i'm talking that the file is not writable by www-data user:

$ ls -al .htaccess
-r--r--r-- 1 root root 1744 Oct  1 11:08 .htaccess

do not get fooled by file permission that www-data does not have write permission:
that file is owned by www-data allows www-data user to chmod to whatever it likes and still write to it.

so the question is: what are you trying to achieve by changing the .htaccess permissions? prevent it bein accessible from web? you can't solve that with file permissions as i already explained. prevent it being readable by local users? i don't see value in this, as the file is still accessible from web. besides i trust my local users.

as for the test: it's no question that header() function will add the headers. the question is whether it is sufficient to solve the current problem and and does the dokuwiki installation still work.

[SFITCS]

Yes it solved the current problem thanks - were the header logs I attached unclear? (I didn't have time to edit them down).

I quickly tried adding the headers to _doku.php_ and got errors - I assume/guess because they didn't immediately follow <html>. Putting them in _httputils.php_ worked fine for testing purposes (though I label it a hasty hack), and had no detrimental effect on DokuWiki.

As for _.htaccess_ permissions - as I previously agreed, it's not relevant to this issue (and yes I read your response - it didn't answer any of my questions :)). But I'm interested in discussing it elsewhere when I finish work, I can be reached via the forum pm.

[robinro]

Thanks for working on this issue!

While I used dokuwiki.org as an example I would really like to see those settings as defaults in the dokuwiki code. I would prefer an implementation in the php code over a htaccess version for the arguments mentioned above.

[glensc]

@SFITCS what needs testing is not the technical aspect "how to add http headers", but whether dokuwiki install still works after the headers are added to http responses. i did not look the logs, because the testing needs to be done with browser. the test should be about "which headers should (can) be added by default" and "which headers would need $conf setting".

also, if you want to post code changes, attach them as diff -u OLDFILE NEWFILE output inside code block:

```diff [diff output goes here] ```

[SFITCS]

I apologise if my post confused you - those header changes produced the desired result when tested with web browsers.
The log included are the header logs from the browser. i.e. the correct headers where received in the correct format/locations.
No diff was given because I'm almost certain those headers should not be inserted where I added them.
I did try inserting them where you suggested, in _doku.php_, but it caused DokuWiki to stop functioning, so I put them in the first place I could quickly find where they would work - noting that it is very unlikely to be the correct place (it was for conditional headers, but I couldn't locate the correct place in the time available to me).
tl:dr? I'm not suggesting they belong in _httputils.php_ - I'll leave the correct placement up to DokuWiki developers.
From my point of view I was only testing to see whether my belief that headers created by the application would be valid , matched the practise- it did (i.e. would the webserver, or the application, not invalidate any of the headers) .
Thanks for your work.

[splitbrain]

TL;DR :wink:

Could one of you provide a pull request with whatever you agreed on? It's easier to discuss when we have some code to look at.

[mjbohn]

Hi
I made some tests with adding these headers in inc/init.php .
https://github.com/mjbohn/dokuwiki/blob/security_header/inc/init.php
starting at line 78

Seems to work fine. At least I don't see any issues at browser console as long as "Content-Security-Policy" is not set.
But I guess that's just setting the right options for this header.

Anybody familiar with this header

[splitbrain]

There is no doubt that we can set headers in DokuWiki. The question is if there are sensible headers to set that would apply to everyone or if it would make more sense to leave the decision on adding those headers to the admin installing DokuWiki.

So what I would like to see is a list of the headers and their possible settings with a description what each of them would mean for DokuWiki users (eg. what would stop working, like running DokuWiki in a frames etc).

Once we have that it's easier to decide what to actually implement.

[mjbohn]

Well I also never had any doubt that this would be possible :-)
My intension with this test was to offer a config section to enable these headers, but all default off. So the admin can decide which to turn on.

The description of each option could thoroughly explain what happens if the header is turned on.

[gamma]

Please check out the PR and the plugin I put together at https://github.com/i-net-software/dokuwiki-plugin-contentsecurity - It is a first draft for adding the respective headers using the already existing functions of DW.

[dregad]

@gamma not sure if you're aware, but there's already a plugin to manage CSP headers - see https://www.dokuwiki.org/plugin:cspheader

It has not been updated recently, but despite the warning on the plugin's page, it works just fine in latest DW version as far as I can tell (at least for my purposes).

I did not test your plugin so I don't know how it compares, but maybe it would be best not to have multiple plugins for the same purpose to avoid confusion.