Security Scan: __Host-Prefix

If a cookie’s name begins with “__Host-”, the cookie MUST be:

   1.  Set with a "Secure" attribute
   2.  Set from a URI whose "scheme" is considered "secure" by the user
       agent.
   3.  Sent only to the host which set the cookie.  That is, a cookie
       named "__Host-cookie1" set from "https://example.com" MUST NOT
       contain a "Domain" attribute (and will therefore be sent only to
       "example.com", and not to "subdomain.example.com").
   4.  Sent to every request for a host.  That is, a cookie named
       "__Host-cookie1" MUST contain a "Path" attribute with a value of
       "/".

As I get it, subdomains should work, as the cookie can be set from “https://cloud.example.com” and then will be sent to “https://cloud.example.com” without need for “Domain” attribute, right?

As Path=/ need to be set, subfolders should not work. I am not sure about the behaviour, if i.e. index.php is shown in address field, if this also counts as path.

Also would be interesting, if __Host-cookies are set automatically, if the requirements are fulfilled or if sometimes settings need to be adjusted for that.

€: More on that from this blog post:

Same-site cookies support

The Same-site cookie support in Nextcloud 11 has been hardened even further. Same-Site cookies are a security measure supported by modern browsers that prevent CSRF vulnerabilities and protect your privacy further.

Browsers that support same-site cookies can be instructed in a way to only send a cookie if the request is originating from the original domain. This makes exploiting CSRF vulnerabilities from other domains a non-issue. Also timing attacks, such as enumerating whether a specific file or folder exists, are not feasible anymore. Nextcloud enforces the same-site cookies to be present on every request by enforcing this within the request middleware.

As hardening measure, in Nextcloud 11 we have added the __Host prefix to the cookie if the environment supports this feature. This enforces the cookie to be only sent via HTTPS and only be sent only to the host that has set this cookie. This mitigates cookie injection vulnerabilities within potential third-party software sharing the same second level domain. Note that Nextcloud does also employ regular protections against CSRF such as a shared secret between browser and client. Same-Site cookies are just considered a security hardening. More technical details about the original implementation can be read in this blog.

Okay … I had an alias in my apache2 configuration due an migration from the past …

#Alias /owncloud "/var/www/html/owncloud/"
#Alias /nextcloud "/var/www/html/owncloud/"

After I commented this out … everything is fine A+ :sunglasses:

6 Likes

I do not have an alias or something like that in place and Nextcloud performs on NGINX.
In specific I am waiting for a solution regarding security re-scan issues.
Most probably all my issues will disappear (Nextcloud releases security scanner to help protect private clouds) because my domain is not beeing re-scanned since days.

@guddl : THANK YOU!! :slight_smile:
That was the solution for me and I am so thankful to have this solved now. Thank you!
A+ wohooo

So to get this right:

  • I also have an alias for nextcloud in conf-available actually for /nextcloud, as the folder is also in /var/www/nextcloud.
  • Would the only solution be to put server root to nextcloud folder and therefore lose shares etc.?
  • Or would it also be possible to put server root to /var/www, threrefore keep url/nextcloud and move all strict config and folder permissions from my alias to the ssl vhost?

@MichaIng
I just commented out the alias
# Alias /nextcloud "/var/www/nextcloud/"
in sites-enabled, restarted the apache service and that was it.

So to compare our setups, my path is also:
/var/www/nextcloud

and my domain is:
https://cloud.mydomain.net/

Before the upgrade to NC 11 connecting to my server resulted always in URLs like
https://cloud.mydomain.net/nextcloud/index.php***
NC 11 however removed the part /nextcloud/ by changes to the .htaccess I guess. I had to change nothing manually there.

From what I read about the __Host- Cookie I expected that this cannot be activated for my setup, but obviously it can.
Just try to comment out the alias and restart the webserver as well and run another security test :slight_smile:

Good luck!

1 Like

I have Nextcloud set up at my home. My ISP have DHCP so I have to use a DDNS from dynu.com.
My URL to access my Nextcloud is:
https://example.dynu.com/nextcloud.

I don’t have any knowledge about these sorts of things on how to setup redirect, subdomain, domain, cname, virtual host and whatever ppl and guides talk about. I have just followed guides to set things up and I’m totally stupid about these sorts of things. I don’t get the “big pictures” so to say, and even how much I try to read about it I don’t understand.

I tried to comment out
Alias /nextcloud "/var/www/nextcloud/"
in
/etc/apache2/sites-available/nextcloud.conf
But then I cant connect to my Nextcloud. What do I need to do to make this work? Do I need to do some changes in dynu DDNS config, or do I need to buy a domain.

Perhaps this security flaw is not a big deal, and I can ignore it. I got an A, and maybe I should be happy I got that, but if I can do anything about it I will.

I would thankful for any help!

Hi @Eazy ,

We would need more information about your system. You are using NC 11.0.2, right? If you make changes rather go to the files in /etc/apache2/sites-enabled/. Usually there are only softlinks in this folder, but you can be sure to touch the right config file.
While there have been a lot of changes to the .htaccess file in /var/www/nextcloud with NC11.0.x you could check if the updater was able to write to that file. For me the URL I see in the browser address field changed from
https://example.dynu.com/nextcloud/index.php
to
https://example.dynu.com/index.php

with NC 11. If you still see the first kind of URL there are probably some entries in .htaccess missing.

Maybe it is better to open a new thread and post your config files there.

I am little wondering about that. Didn’t all your shares break as well as configs from external clients, mail, dav etc.? I would be reaally surprised if due to some automated changes in .htaccess the url to your nextcloud changes. This would be an extremely bad practise in my opinion as SO much depends on the url, which would need a horrible fix for every larger deployment with much users.

Hm, you’re right. Old shares and sync configurations stopped working and I had to setup every sync connection again, but while I liked the short URLs I didn’t complain.

And at least my server is now A+ :smiley:

To be honest I can’t rule out that I made one configuration change or two, to receive an A+. And while there were a lot of changes on the server lately (update to NC 11.0.1 and then to 11.0.2, requested improvements by users) I cannot be 100% sure, what happened only by the update and what was me. I have no change management for my small server :stuck_out_tongue:

While writing this comment I checked my configs again and notice in the config.php:
'htaccess.RewriteBase' => '/',

I believed I added this line first after I read this thread here. Maybe this was the real reason for the changed URLs, but I have absolutely no clue.
In general I just wanted to help and describe what changed at my server, in case someone wants the A+ as bad as I did and accepts the necessity to make some config changes in the clients.

Ah yes, the changed rewrite base would make sense. This hardens my suggestion, that no sub folder is allowed for _Host prefix cookies / A+ rating.

Hmm as my nextcloud is mostly used private, I could change this without much effort. But I only have one sub domain for my server, which is given from a friends private dyndns server. So far I don’t use the web server root for any other web service/page, but this might change some day.

Ah I think I will stay with an A and keep nextcloud in a sub folder for now :stuck_out_tongue:. If there is a way, to still get A+ with this, I would appreciate some hint :slight_smile:.

€: Same topic and same solutions/answers here: Security: __Host-Prefix cookie setting?
So I think one of these topics could be closed ;).

Do you run nextcloud behind a reverse proxy? I am using traefik and got an A+ after adding the following line to config/config.php:

'overwriteprotocol' => 'https',

Background:
The secure (https) connection is terminated at the proxy and nextcloud only sees an unencrypted (http) connection coming from the proxy. As you can read in Security: __Host-Prefix cookie setting? nextcloud needs a secure (=https) connection to use __Host-cookies. So you have to overwrite the connection type :smiley:

Hope that helps!

8 Likes

Although this topic is older than two years.
I have a similar problem and I don’t know the solution.
Can anyone help me?

very thx

This resolved my issue!!! I have NextCloud running in a docker container behind a Traefik reverse proxy… Adding this one line resolved my final issue with the ‘__Host’ prefix failing. Now I have an A+ rating!!!

1 Like

I know this post is now oldoldold, but this is something I have not been able to figure out. How do I get the connection between reverse proxy and the Nextcloud container to be https? I’m using Nginx Proxy Manager and when I choose https there, I get a “502 Bad Gateway”. Obviously, something is missing at the Nextcloud end of the connection. I added your line to my config.php, but it doesn’t help. I feel like Nextcloud should be generating some kind of self-signed ssl certificate, but it doesn’t.

I got this same setup to work with the Collabora CODE container, but I just can’t get it to work with Nextcloud. Any suggestions? Anything I should add to my docker-compose, for instance?

in general it is always better you start your own thread and describe your setup, the problem, what you tried so far…

the overwriteprotocol setting itself doesn’t change anything, it explicitly expected to make Nextcloud behave different. In this case you can access NC with plain http:// but it make all URL look like https://. the reason is majority of the users don’t want to use TLS behind reverse proxy - terminating TLS on your entry point (=reverse proxy) simplifies the setup - you only need to manage the complexity of certificate requests, issuing and configuring once and don’t need to replicate it to different endpoints like collabora, NC, another webservice (especially in case of docker and VMs on same physical server there is no security issues related to such setup).

Thank you for the explanation. Also good to see there are no security issues involved (the entire setup including docker is indeed running on the same physical server). That is also what I gathered so far, but it’s still nice to hear it confirmed. The reason I started tinkering with this (again) was the __Host-Prefix message of Nextcloud’s security scan, which is also why I wrote in this existing thread. Maybe I should have made that clear.

I guess I will leave my setup as it is since, from what I understand, this __Host-Prefix message does not seem to be that important. If you tell me I’m wrong about this, I’m happy to keep tinkering. :slight_smile:

I have no security warning within Nextcloud and security scan… (always access the system with http://mycloud.tld)

maybe you missed something, please double check your configs

I access it via mycloud.mydomain.tld instead of mydomain.tld which, according to some of the messages above, seems to be the reason for the security warning. But, as also mentioned above I believe, this is the recommended setup and arguably also the safer setup. Anyway, I’m no security expert. I’ve just tried to read up on this and this is what I found out.

overwriteprotocol fixed it for me. Actually, it fixed the rating and “You are accessing your instance over a secure connection, however your instance is generating insecure URLs.” :sunglasses: