search

MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.89k stars 498 forks source link

"Referrer-Policy" HTTP-Header is not set to "no-referrer" #3694

Closed Phil1988 closed 4 years ago

Phil1988 commented 4 years ago

Required Information

DietPi version | cat /boot/dietpi/.version
G_DIETPI_VERSION_CORE=6
G_DIETPI_VERSION_SUB=31
G_DIETPI_VERSION_RC=2
G_GITBRANCH='master'
G_GITOWNER='MichaIng'

Distro version | echo $G_DISTRO_NAME or cat /etc/debian_version
9.12

Kernel version | uname -a
Linux DietPi 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux

SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
Virtual Machine (x86_64)

This is not really a bug but I updated from NC 16.0.4 to 16.0.11 (and further.. but there happens this warning the first time) an got the warning from NC WebIF: Der "Referrer-Policy" HTTP-Header ist nicht gesetzt auf "no-referrer", "no-referrer-when-downgrade", "strict-origin", "strict-origin-when-cross-origin" oder "same-origin". Dadurch können Verweis-Informationen preisgegeben werden.

This warning only appears vom Nexctloud 16.0.11 to 17.0.8 (including) On 18.0.7 its gone.

The problem I have is, that I cant find the right place to include it because in /etc/apache2/sites-enabledR/dietpi-nextcloud.conf I can see: Header set Referrer-Policy no-referrer

I also had a look at the paths /etc/apache2/ and /etc/lighttpd/conf-enabled/ but could not find anything for that. It might be enough to create a .htaccess at /var/www/nextcloud/, but I want to avoid this because it violates the integrity checks.

Looks like it might not even be important to fix because its just in a few versions.

If I do a header check here: https://securityheaders.com I get this warning: Content-Security-Policy: This policy contains 'unsafe-inline' which is dangerous in the style-src directive.

I thought I could just do what I found here https://help.nextcloud.com/t/trying-to-get-an-a-rating-from-securityheaders-com/65796 and set: Header set Content-Security-Policy "default-src 'self';" in the file: /etc/apache2/sites-enabled/000-default-le-ssl.conf At least I do get an A+ from https://securityheaders.com. Problem is, that Nextcloud is broken then :)

If I do a security check here: https://scan.nextcloud.com I get the warning:

The __Host prefix mitigates cookie injection vulnerabilities within potential third-party software sharing the same second level domain. It is an additional hardening on top of 'normal' same-site cookies.

looks like you (MichaIng) have already been there ;) https://help.nextcloud.com/t/security-scan---host-prefix/9785/10

I also did comment out the Alias at

/etc/apache2/sites-enabled/dietpi-nextcloud.conf

but that changed nothing on the rating of scan.nextcloud.com.

MichaIng commented 4 years ago

Many thanks for your report. Yeah it is due to some back and forth on Nextcloud and the fact that setting a header doubled makes the warning appear:

You can simply take the config that would be applied on fresh installs or reinstalls: https://github.com/MichaIng/DietPi/blob/master/.conf/dps_114/apache.nextcloud.conf

Content-Security-Policy (CSP) is a different topic. Applying the wrong rules there breaks Nextcloud and further does Nextcloud apply those rules internally as strict as possible per-script. I personally use those very strict server-wide rules:

Header set Content-Security-Policy "upgrade-insecure-requests; default-src 'none'; frame-ancestors 'none'; base-uri 'none'; form-action 'none'"

But then for the Nextcloud directory I must unset the header:

<Directory /var/www/nextcloud/>
        Header unset Content-Security-Policy
...

The cookies __Host prefix cannot be set, unless Nextcloud is available at the webroot. Since we place it into a subdirectory (your.domain.org/nextcloud/), this "vulnerability" will always be present. However you can ignore it. There has been some discussion that it is misleading since it is always safer against random bot attacks and crawlers to have web applications in sub directories compared to the tiny benefit of the cookies __Host prefix. Check out the Nextcloud forum about this, if you are interested in details.

Jep, the Alias is completely meaningless in dietpi-nextcloud.conf since it matches the real location/path, hence we as well removed it from our current config.

Phil1988 commented 4 years ago

Just do be sure: The config at https://github.com/MichaIng/DietPi/blob/master/.conf/dps_114/apache.nextcloud.conf

should match to my /etc/apache2/sites-enabled/dietpi-nextcloud.conf right?

because I set some additional things there as max age, opcache.memory_consumption and the caldav , carddav and webdav for synchronizing correctly with android devices

So it currently does look like this:

Alias /nextcloud "/var/www/nextcloud/"

Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains; preload"
Header set Referrer-Policy no-referrer

<Directory /var/www/nextcloud/>
        Options +FollowSymlinks
        AllowOverride All

        <IfModule mod_dav.c>
                Dav off
        </IfModule>

        SetEnv HOME /var/www/nextcloud
        SetEnv HTTP_HOME /var/www/nextcloud

        # Hard coding 128M OPCache size, only for /nextcloud, to suppress warning on nextcloud admin panel.
        php_admin_value opcache.memory_consumption 128

</Directory>

Redirect 301 /.well-known/caldav https://MYURL/nextcloud/remote.php/dav
Redirect 301 /.well-known/carddav https://MYURL/nextcloud/remote.php/dav
Redirect 301 /.well-known/webdav https://MYURL/nextcloud/remote.php/dav
Redirect permanent /ocm-provider /nextcloud/ocm-provider
Redirect permanent /ocs-provider /nextcloud/ocs-provider

so for the Content-Security-Policy (CSP)

You put all of this into the /etc/apache2/sites-enabled/dietpi-nextcloud.conf right? so this

Header set Content-Security-Policy "upgrade-insecure-requests; default-src 'none'; frame-ancestors 'none'; base-uri 'none'; form-action 'none'"

goes to the "general" part of that config, and 

        Header unset Content-Security-Policy

goes into the Directory part correct?

Or am I missing other config files?

MichaIng commented 4 years ago

opcache.memory_consumption should be set via php.ini as shipping this via Apache2 config leads to inconsistent behaviour: Server-wide OPcache is set to default first, then once Nextcloud PHP pages is accessed, it switches server-wide to 128M. It is not possible to set this per-dir.

So on new installs we apply via /etc/php/7.3/mods-available/dietpi-nextcloud.ini:

; Nextcloud PHP settings
; priority=98
apc.enable_cli=1
opcache.enable=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1

The two SetEnv are obsolete, nobody knows how they made their way into ownCloud+Nextcloud documentations but I checked back and both, ownCloud and Nextcloud have removed them accordingly: https://github.com/nextcloud/documentation/commit/b95c0e0185e00a17de09e0c692f827998fef0730#diff-25006775d47d90bb1b266dc81ec432ec

The HSTS header should be set via HTTPS vhost, just because it is only valid and makes sense there. It has nothing to do with Nextcloud, but this header is either set for the whole (sub)domain or not at all. Clients/browsers do not store per-URL/path HSTS headers, only per-domain. So e.g. add it via /etc/apache2/sites-available/000-default-le-ssl.conf if Certbot/dietpi-letsencrypt did not already do that, inside <VirtualHost *:443> block.

The DAV redirects are fine there. We currently apply this via /etc/apache2/conf-enabled/dietpi-dav_redirect.conf but only to avoid conflicts between ownCloud, Nextcloud, Pydio (?) and BaiKal installs, which all (can) serve as DAV servers. As long as this file does not yet exist, its fine to leave your redirects. Interesting is the "webdav" one which is missing on our installs. I mean the Nextcloud clients find those perfectly fine but is allows to give 3rd party clients the hostname/domain only instead of full DAV endpoint path?

I put the general CSP rules into /etc/apache2/conf-available/micha.conf together with all other custom server-wide configs and only Header unset Content-Security-Policy into dietpi-nextcloud.conf. Practically it makes no difference but I like to have things separate and combined reasonable, so that when I remove a certain website and disable its configs, everything else stays as expected, although I do not plan to remove Nextcloud. Another place to put server-wide security/privacy headers and settings would be /etc/apache2/conf-available/security.conf which exists and is enabled by default (package-wise) and contains a few other headers and settings to consider. But the contained <Directory> parts can be ignored, as they are default in /etc/apache2/apache2.conf already 😉.

Also note that those CSP rules play zero role as long as you don't have any other website on the same webserver where you are not sure about scripts security. Basically websites should be forged so that as strict as possible CSP rules are set internally. I did this just to learn and get A+ at https://securityheaders.com/ 🤣.

Phil1988 commented 4 years ago

the opcache.memory_consumption was set by me manually in my /etc/apache2/sites-enabled/dietpi-nextcloud.conf ... on a Nextcloud < v14 because it didnt work on a different place.

I now have deleted that as well as the SetEnv stuff and the HSTS Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains; preload"

But I added the Header unset Content-Security-Policy at the section.

So it does look like this:

#Alias /nextcloud "/var/www/nextcloud/"
Header set Referrer-Policy no-referrer

<Directory /var/www/nextcloud/>
        Options +FollowSymlinks
        AllowOverride All
        Header unset Content-Security-Policy

        <IfModule mod_dav.c>
                Dav off
        </IfModule>
</Directory>

Redirect 301 /.well-known/caldav https://MYURL/nextcloud/remote.p$
Redirect 301 /.well-known/carddav https://MYURL/nextcloud/remote.$
Redirect 301 /.well-known/webdav https://MYURL/nextcloud/remote.p$
Redirect permanent /ocm-provider /nextcloud/ocm-provider
Redirect permanent /ocs-provider /nextcloud/ocs-provider

My /etc/apache2/sites-available/000-default-le-ssl.conf looks like this

<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName MYURL
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www
        #DocumentRoot /var/www/nextcloud

        ErrorLog ${APACHE_LOG_DIR}/error.log
        #CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLCertificateFile /etc/letsencrypt/live/MYURL/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/MYURL/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
RedirectMatch ^/$ /nextcloud/
</VirtualHost>
</IfModule>

So there is no HSTS there (also not set by letsencrypt). Should I add the line I posted above to this file?

like so?

<IfModule mod_ssl.c>
<VirtualHost *:443>
Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains; preload"
ServerName MYURL
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www
        #DocumentRoot /var/www/nextcloud

[...]

BTW: ismax-age=15552000; and includeSubDomains; preload" ok? I read something about max-age=31536000; amd without the preload...

my /etc/php/7.3/mods-available/dietpi-nextcloud.ini looks the same except I have ; priority=99 but I think thats not important at all.

The thing about the webdav (and caldav and carddav) is like 4 years old... back then it didnt work without any of these. I did check that fur sure. Might be that the Nextcloud or the DavDroid App has changed since and it works without but it shouldnt hurt right? :D

I put the 

Header set Content-Security-Policy "upgrade-insecure-requests; default-src 'none'; frame-ancestors 'none'; base-uri 'none'; form-action 'none'"

into the /etc/apache2/conf-available/security.conf because I dont like to add a new file there :)

Everything ok from your perspective?

EDIT: I did these changes and tested it.

I get this warning from securityheaders.com: 

Content-Security-Policy | Content Security Policy  is an effective measure to protect your site from XSS attacks. By  whitelisting sources of approved content, you can prevent the browser  from loading malicious assets.

So it looks like /etc/apache2/conf-available/security.conf is not the right place for the CSP ?

I know the A+ is not that important for my private cloud.... but you know.. we always have a better feeling, when we get good grades :D

MichaIng commented 4 years ago

About HSTS, yes that would be fine. Just keep in mind what preload means: https://hstspreload.org/ Once you're on the list, no browser that supports preload will ever again be able to connect to your domain via HTTP until you went through a probably long queue of getting it removed again.

So it looks like /etc/apache2/conf-available/security.conf is not the right place for the CSP ?

Is it enabled? a2enconf security; systemctl reload apache2 You can test via: curl -ILk https://localhost/

Phil1988 commented 4 years ago

Interessting! The max-age must be at least 31536000 seconds (1 year). => my header doesnt make any sence because of Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains; preload"

so I will now just delete the preload.

looks like security.conf is enabled:

a2enconf security; systemctl reload apache2
Conf security already enabled

So the output of curl -ILk https://localhost/ is now:

HTTP/1.1 302 Found
Date: Sat, 25 Jul 2020 13:14:47 GMT
Server: Apache/2.4.25 (Debian)
Strict-Transport-Security: max-age=15552000; includeSubDomains;
Location: https://localhost/nextcloud/
Content-Type: text/html; charset=iso-8859-1

HTTP/1.1 302 Found
Date: Sat, 25 Jul 2020 13:14:47 GMT
Server: Apache/2.4.25 (Debian)
Strict-Transport-Security: max-age=15552000; includeSubDomains;
Referrer-Policy: no-referrer
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-Robots-Tag: none
X-XSS-Protection: 1; mode=block
Set-Cookie: ocdz524gxpyd=c7l6gik52r2p1ujk9npo3rkkdq; path=/nextcloud; secure; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Set-Cookie: oc_sessionPassphrase=ucPblnfcIn3HygEA5Iw8XNc5aRpluLlut1N9KQOJB1dOsQ7mtjg6PRGhVd0rFiWwgbl7f%2F3JHjQ834%2B4m3VrCvG7P%2BeKeluP56xr6VjCtbyAuYms9bVjtciSwx9hXMfQ; path=/nextcloud; secure; HttpOnly
Set-Cookie: nc_sameSiteCookielax=true; path=/nextcloud; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
Set-Cookie: nc_sameSiteCookiestrict=true; path=/nextcloud; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
Location: https://localhost/nextcloud/login
Content-Type: text/html; charset=UTF-8

HTTP/1.1 200 OK
Date: Sat, 25 Jul 2020 13:14:47 GMT
Server: Apache/2.4.25 (Debian)
Strict-Transport-Security: max-age=15552000; includeSubDomains;
Referrer-Policy: no-referrer
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-Robots-Tag: none
X-XSS-Protection: 1; mode=block
Set-Cookie: ocdz524gxpyd=t21aqluor3m7apav365sb537so; path=/nextcloud; secure; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Set-Cookie: oc_sessionPassphrase=D%2FkBxA4omZmp9dNTEJO7KAwIJqKAE6hpE9l16rxuPElv9k%2BcJI7gn7%2BU2CxTNozDzNfzYo0fEI1K7bBq3W2ys5iIoPrKVNWCIvKUeKJLRMYeSbmxmL5K%2BLvptu12bmVd; path=/nextcloud; secure; HttpOnly
Set-Cookie: nc_sameSiteCookielax=true; path=/nextcloud; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
Set-Cookie: nc_sameSiteCookiestrict=true; path=/nextcloud; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
Feature-Policy: autoplay 'self';camera 'self';fullscreen 'self';geolocation 'self';microphone 'self';payment 'none'
Content-Length: 5943
Content-Type: text/html; charset=UTF-8

funny that in nextcloud is still a owncloud cookie set (oc_session) ;)

MichaIng commented 4 years ago

funny that in nextcloud is still a owncloud cookie set (oc_session) ;)

Lol, yeah there are still plenty of parts where ownCloud prefixes are used, starting with the occ command (only we apply an ncc alias) as well as default database prefixes etc 😄.

HTTP/1.1 302 Found

Ah, you have a rewrite rule to redirect all to Nextcloud? Then of course CSP will be reset in every case and you could remove this completely 😉. Since https://securityheaders.com/ AFAIK follows redirects before evaluating headers, it will then always complain about missing CSP.

Phil1988 commented 4 years ago

Yeah I have a rewrite rule (that I dont even remember where I did it... 4 years ago :D )

But I inserted the real path like https://MYURL/nextcloud/ to https://securityheaders.com. So It should have taken the CSP on my logic :D .... but it wouldnt be the first time I am wrong, nor will it be the last :)

MichaIng commented 4 years ago

Ah, but since you explicitly unset the CSP header on /nextcloud sub dir it is of course not present, intentionally since it would break Nextcloud.

So just to clarify:

MichaIng commented 4 years ago

I mark this as closed. Feel free to reopen if any questions left.