OnlyOffice Secret

@daniel.pan

I hope this can help you to implement this feature. It will be nice to have this function in next release.

Best Regards

1 Like

Thank you very much. We will review the code.

2 Likes

Was this implementation merged into the stable branch already? Manual content updated?

We are reviewing the code currently.

3 Likes

@daniel.pan Any updates to this?
I’ve got the integration setup with OnlyOffice but cannot enable the OnlyOffice service until this security hole is patched.

Thanks.

1 Like

This is on our plan list. But I’m sorry it is still delayed by other urgent fix tasks.

Hello, when I learned more about OnlyOffice, I found this, maybe it will meet your need without change Seafile code (or wait for the future version).

Hello!
Later we will implement a more advanced solution JWT and inform you about it.
In the current version of DS you may restrict access from alternative file storages by editing Document Server configuration file /etc/onlyoffice/documentserver/default.json. Find the section 'filter' and change it to the following look :

                   "rules": [
                     {
                       "address": "IP_or_DN",
                       "allowed": true
                     },
                     {
                       "address": "*",
                       "allowed": false
                     }
                   ],
                   "useforrequest": true,
                   "errorcode": 403
                 }
After editing configuration file use the command 'supervisorctl restart all'.
As you are using Docker version at first enter the container with 'docker exec -it container_ID /bin/bash' and then perform previously mentioned operations.
Thank you for the interest in ONLYOFFICE.

And we will look into the JWT token solution later if it is necessary.

1 Like

Thanks for the info but it is necessary to implement the token solution. Changing the code inside the docker containers is not a solution and could be incompatible any time.
There are updates for the docker images and they are replaced entirely for the document server. Messing with the code is not a good idea. :expressionless:

2 Likes

Good hint. I will try to implement and test the token solution, if everything goes well, you will see it in the next version.

2 Likes

That’s awesome thank you! :smiley:

I have tested editing the .json file in the docker image, and whilst it does seem to work, like @DerDanilo says, this isn’t a supported change of config to the container and any future update may alter this leaving the deployment open again without any notification.

JWT would be awesome to see, cheers @lian !

@daniel.pan @lian

The docker container for onlyoffice document server has recently been updated, and the unsupported work-around described here breaks the server after the update.

The web token is the only supported way of securing the server.

2 Likes

The PR linked above is now outdated. Is there any interest in reviving it?

Right now, anyone can open a document for viewing and switch to editing, or guess the key (it’s computed from public information) and connect directly to OnlyOffice. Moreover, it’s easy for a user to change their username. These are rather big security flaws.

1 Like

Please have a look at this blog post. It might be helpful. It is a German blog post - just have Chrome do the translation for you and I guess you will get the idea.

i dont think that this really does the trick.
Most users uses the recommended way with docker and nginx reverse proxy, If you now limit the onlyoffice to 127.0.0.1 or a domain its still exposed because the reverse proxy itself can still access it (and there is no way to change this because the user has to access the server).
you can only limit access if the onlyoffice and seafile server share a private secret.

1 Like

The link above does not provide security. As mentioned previously, without a token a user can escalate the read session to a write session and modify documents they only have read access to. Also, applying a firewall is only helpful if all your users are on a limited number of networks.

Hey odontomachus,
I have to disagree. I am the author of the blogpost and I can confirm that the mentioned ipfilter does prevent the abuse of your onlyoffice installation from another server.

Here is my setup I tested:

Server 1 with seafile, nginx, onlyoffice. Onlyoffice is accessible via https://cloud.example.com/onlyoffice
Server 2 is another server anywhere on the internet with seafile. Without ipfilter it is possible to the following to the seahub_settings.py:

# Enable Only Office
ENABLE_ONLYOFFICE = True
...
ONLYOFFICE_APIJS_URL = 'https://cloud.example.com/onlyoffice/web-apps/apps/api/documents/api.js'
....

To prevent that anybody else can abuse your onlyoffice instance it is sufficient to add the mentioned ipfilter for “cloud.example.com” to the onlyoffice config file.

As soon as there is an ipfilter another seafile instance will show the following error it an office document is opened:

I totally agree that this is not sufficient and does not tackle the other security aspects you mentioned.

Best regards
Christoph

1 Like

Never ending story :weary:

Having the same problem at my end.

I already had integrated an onlyoffice server in another cloud service with enabled JWT_SECRET Parameter but since there is no possibility to define the JWT_SECRET parameter inside seahub_settings.py, I had to disable the secret key on onlyoffice docker and restrict to those domains who access the onlyoffice docker server, which is actually the only workaround for restricted use of onlyoffice but difficult to maintain after every onlyoffice docker update, even we can apply the following volumen workaround. This mounting volumen workaround could be broken by new parameters inside /etc/onlyoffice/documentserver/default.json Let’s see how long it works this WA at my end…

An implementation of an JWT_SECRET Key in Seafile is the only realiable solution.

3 Likes

We will look into JWT Secret.

2 Likes

Hi Daniels,
Any news for secret key ?
Thanks