Unable to restrict allowed WOPI hosts

Installation & Configuration
1

Hi all,

I have Nextcloud and Collabora CODE running on the same machine. Collabora CODE is configured to listen on localhost with SSL disabled. nginx acts as reverse proxy and does SSL termination, making CODE available on a public URL via HTTPS. Overall, this setup works very well.

The Nextcloud docs (Configuration — Nextcloud latest Administration Manual latest documentation) say:

Similarly, it is advised to configure Collabora’s WOPI host configuration to only serve IPs from expected hosts.

To me this sounds like a good idea. CODE should only process files served by my Nextcloud instance and not some random other host. Unfortunately, I am unable to restrict the allowed WOPI hosts in coolwsd.xml. For testing, I set the following:

<alias_groups desc="default mode is 'first' it allows only the first host when groups are not defined. set mode to 'groups' and define group to allow multiple host and its aliases" mode="groups">
    <group>
        <host desc="hostname to allow or deny." allow="true">https://1.2.3.4:443</host>
    </group>
</alias_groups>

With https://1.2.3.4:443 I set an invalid IP on purpose. Still, my Nextcloud can open documents without any issues. So it seems like the WOPI host restriction is not enforced.

Am I doing something wrong? I would assume that only the specified host can serve files to CODE with this setting.

Thanks a lot,
Michael

2

I think I figured it out. Setting the loglevel to “information” reveals the behavior.

As expected, when “mode” is set to “first”, then the first host that connects will be added to the list of trusted WOPI hosts. The log message will be:

Adding trusted WOPI host: [hostname]

Interestingly, the behavior is the same when setting “mode” to “groups” but not defining any groups or only empty groups.

Now onto why I could not lock out my own Nextcloud with the setting in my original post: The local machine will always automatically be added to the list of trusted hosts. The log then says:

WOPI host [hostname] is on the same host as the WOPI client: “ip.addr.of.hostname”. Connection is allowed.

So, the way to secure this kind of installation is still to use the pattern from my original post (of course with the correct hostname of the machine). But for proper testing, one needs a different WOPI host (e.g., a second Nextcloud) on a separate machine.

1 Like
3

Hi @Bevan!

Yes, this is correct. You can generate a different WOPI hostname and see from the logs (at least information level, if not debug) that it gets blocked without attempting to communicate with it. This test hostname doesn’t need to be real or (if it is) owned by you, it just has to be excluded from the config.

Feel free to report back if you uncover any issues.

Thanks!

1 Like