WOPI endpoint security question

Hello all!

I have a question about the WOPI endpoint and its security. I have a setup where collabora code runs as a container with its own domain and cert (no reverse proxy) while nextcloud is behind haproxy.
The two could talk but i could not open documents even though i allow listed the ip and domain of the container host machine, turned out i have to also allowlist the reverse-proxy even though it adds the x-forwarded-for header (apache2 module enabled to support this, apache logs show the correct ip).
So the WOPI endpoint only looks at the source IP and ignores the header?

Thanks in advance!

Nextcloud VM:
Ubuntu 22.04.3 LTS
Apache/2.4.52 (Ubuntu)
PHP 8.1.2-1ubuntu2.14
MariaDB 10.6.12-MariaDB-0ubuntu0.22.04.1
Nextcloud 28.0.1

Collabora code runs in a container on TrueNAS Scale 23.10.1 (from their own official repository).

from GitHub - nextcloud/all-in-one: The official Nextcloud installation method. Provides easy deployment and maintenance with most features included in this one Nextcloud instance. we see adding reverse proxy IPs is required

It is known that the in AIO included collabora (Nextcloud Office) does not work out of the box behind Cloudflare. To make it work, you need to add all Cloudflare IP-ranges to the wopi-allowlist in https://yourdomain.com/settings/admin/richdocuments

so IPs of all reverse proxy nodes is required. which makes sense as reverseproxy is the system effectively accessing the cloud. In terms of security such wide exception makes no sense as everybody can access the system from cloudflare IPs. I think the only good solution to address the issue would be an own reverse proxy

The reverse proxy is mine, it runs on my router. And that is my concern as well that anyone can access the endpoint through that proxy because it is exposed for reasons (tech illiterate family mainly)…
But i find it odd that nextcloud doesnt use the header added by haproxy to determine the real client IP.

(Extra info: im not using the AIO version.)

I’m not deep into the WOPI protocol details… but I’m under impression the integration only works if domains of both system match. There no “open access” to all you files through the WOPI server… The access works in a way an authenticated user tries to edit a file, the cloud generates a unique URL including a token aka password to access this file through WOPI system and only using this URL it’s possible to access the file (for some time?). WOPI access list provides another level of protection reducing attack vector through leaked URLs… take a look at Collabora integration guide I referenced details to WOPI protocol as well.

definitely a good idea to check real-ip for systems running behind reverse proxy. Would be great you file an issue at Issues · nextcloud/richdocuments · GitHub

Oh okay, that makes sense. And i already read that piece when i set it up. If NC does authentication outside of the IP then it should be fine ™.

Hm, idk why i only referenced only apache in the OP. NC also logs the real (behind the reverse-proxy) ip, that is why i found it odd that the WOPI endpoint needed the reverse-proxy ip to be whitelisted as well…

if it’s important for you I would never trust but proof - you can look at the logs (browser F12 is enough) and check if you can access the WOPI URL, likely it works for short time from everywhere… but after some timeout the URL should stop working…

There might be reasons… maybe the dev just didn’t consider reverse proxy from the beginning…

1 Like