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?
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.
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.
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…