Duplicacy Web Security Flaw

[knightar]

I run the Duplicacy Web Edition to view long term statistics about my backups, I set the Web GUI to be publicly available to the internet so I can access it from my server and I was talking to a friend which notified me that when he accessed the site that he was allowed in without the password. It seems that typing in the password allows anyone access once the password is typed in once. This is a major security issue, especially if it’s not explained that this is the case. It would be beneficial to require everyone who accesses the URL to require the password, not just after someone enters it.

Until this is fixed, I am going to have to change it so it listens back on the local host, or most likely use a private network to access it.

It may be a good idea to notify the user that they are exposing the Web UI to anyone.

[saspus]

Related discussion: Web-UI security: HTTPS, sessions, and logout button

[snellgrove]

I can’t recreate this behaviour.

Same host, two browsers… Password Into one, open the duplicacy URL in second browser and I get an auth prompt.

[saspus]

No, it is still reproducible; I’ve just tried on MacOS with Firefox. Edit – see this comment below

The viable workaround for when it runs in a single user environment is described here:

Web-UI security: HTTPS, sessions, and logout button

I thought the same and “resolved” the problem by setting up a ssh tunnel on my client machine: ssh -l 8888:127.0.0.1:3875 “your-server-address” then point your browser to http://127.0.0.1:8888 I think if anyone is able to access the computer running duplicacy with priviliges like listening to the loopback interface there is not much you can do anyway. You could also setup a reverse proxy like nginx that is secured with a ssl certificate. Anyway a logout button would give me a better feeling …

I like it way more because this approach separate security from applications. However this does not solve an issue that any user on the same machine can access the UI – so the underlying problem still needs to be fixed.

[saspus]

No, it is still reproducible; I’ve just tried on MacOS with Firefox.

I take that back. It’s not reproducible. But the reason that I and OP thought that it was is a separate serious UX problem.

Summoning @gchen

The problem stems from the very first password the UI asks not being an admin password; instead it’s an encryption password of the datastore to keep configuration file in. So, the user thinks the web UI is protected by that password, but this is not the case. Admin password is still empty.

This is highly misleading – why is it not the same as an administrator password? Also, it’s a common convention that when the web app asks you to set a password the first time you use it – it’s a password needed to access it. Duplicacy-web broke this convention.

You have to actually go to settings and set admin password for the UI… then it will ask you in every new session; but I guess that could be circumvented by stealing the cookie or intercepting PUT/GET requests – since HTTPS is not supported

So, additional request: make it obvious that the password you enter at the start is not an admin password. Yes, it’s written in English right there - but I did not read. Nor did OP. Nobody reads text before the password setup boxes – we all know what they are supposed to be for.

Maybe add another two boxes to let users set web UI admin password on the same page. User can chose to leave it empty; but its presence will make it unambiguously clear that there are two different passwords involved. And this realization will maybe force them to read the text to understand which is which.

And honestly, what is the reason for them to be different? They seem to be effectiveively have the same power/access.

[knightar]

Ah! I looked again after reading your comment and I see that there is an “Administration Password”, I don’t believe this was there when I set it up (Correct me if I’m wrong?) when the beta was released. I entered the password and I’ve confirmed that setting this value does prevent others from logging in and seeing unprotected page. So part of my initial issue was fixed, but is still vulnerable due to no HTTPS.

[gchen]

By default the web GUI listens on 127.0.0.1 so there isn’t a need for forcing an administration password for everyone.

I don’t think using the master/encryption password as the administration password is a good idea. They belong to different trust levels. For instance, you may have a friend who you know will not sabotage your backup schedules if you give them the administration password, but still you will never share the master password.

@knightar version 1.0.0 supports HTTPS. You just need to set the HTTPS listening address on the Setting page.