Security Scan: __Host-Prefix

#1

Nextcloud recommends to

Use a dedicated domain for Nextcloud
Administrators are encouraged to install Nextcloud on a dedicated domain such as cloud.domain.tld instead of domain.tld to gain all the benefits offered by the Same-Origin-Policy.

I did it (xy.domain.de) but the Security Scan mentioned:

__Host-Prefix

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.

I do not unsterstand correctly even with regards to

Security: __Host-Prefix cookie setting?

could anyone explain in detail, what is preferred or not.

2 Likes
#2

Same here on my installation … :neutral_face:

#3

Yes same here also. As far as I understand you would need nextcloud to be reachable without subfolder, so example.org or cloud.example.org instead example.org/nextcloud. So switching webserver root to nextcloud folder or copying nextcloud content to webserver root would be the solution, which would break all links and shares indeed. But according to @Oclair this is actually not more but less secure.

So I don’t know, seems there is some more discussion necessary about how so handle it best :smiley:. I will leave my setup as it is, since it doesn’t seem to be a big problem.

#4

My Server is reachable over https://cloud.example.org and only a A

So … :sob:

#5

I think this security scan report means the Cookie Prefixes draft.

#6

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.

#7

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:

2 Likes
Security: "__Host-Prefix", how to fix?
Scan.nextcloud.com: a few issues
#8

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.

#9

@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

#10

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?
#11

@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
#12

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!

#13

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.

#14

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.

#15

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.

#16

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 ;).