Host fileshelter in subpath with Nginx reverse proxy?

[ohmykreee]

Hi, I'm new to these things, and I encountered some problems when deploying fileshelter in subpath with Nginx reverse proxy.

(Version I use: system: Ubuntu 20.04.3 LTS, Nginx: 1.18.0, fileshelter: 5.0.1)

Let's say if I have a domain www.example.com, and I want to host fileshelter in https://www.example.com/share/.

Here is my Nginx config file:

server {
    listen 443 ssl http2;

    server_name www.example.com;
    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!MD5;

    access_log            /var/log/nginx/example.access.log;

    proxy_request_buffering off;
    proxy_buffering off;
    proxy_buffer_size 4k;
    client_max_body_size 5000M; # Make the number the same as 'max-share-size' in fileshel
ter.conf

    location /share/ {

      proxy_set_header        Host $host;
      proxy_set_header        X-Real-IP $remote_addr;
      proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header        X-Forwarded-Proto $scheme;
      proxy_set_header        X-NginX-Proxy true;

      proxy_pass          http://localhost:5010/;
      proxy_read_timeout  120;
    }

    location /otherapp/ {
        # other app, similar to the one above
    }
}

Here is part of my fileshelter.conf:

listen-port = 5010;
listen-addr = "0.0.0.0";
behind-reverse-proxy = true;
# original-ip-header and trusted-proxies are remained default
deploy-path = "/";

At first, everything looks fine, except the text in download link area is something like https://www.example.com/share//share-download/xxx-xxx-xxx, but the link is usable and is https://www.example.com/share/share-download/xxx-xxx-xxx.

However, when someone want download file through "Download" button, the url becomes https://www.example.com/share?id=xxx-xxx-xxx&p=xxxxxx, which should be https://www.example.com/share/share?id=xxx-xxx-xx&p=xxxxxx.

I have no idea what's going on. Because I have other app running on another port, I think it is impossible to proxy all the traffic to fileshelter location / and config deploy-path="/share". I've tried another subpath like "file" but the download link still https://www.example.com/share?id=xxx-xxx-xxx&p=xxxxxx.

And please forgive my poor English 😂.

[epoupon]

Hello!

Indeed this looks like #54
I am afraid this is some limitation of Wt, but I will check what we can do about it

[ohmykreee]

Thanks for reply!

I don't know much about C++, but I just figured out something and I want to share with you.

It seems that the code causing this issue is

fileshelter/src/fileshelter/resources/ShareResource.cpp

Line 71 in a1a6914

return {Wt::LinkType::Url, std::string {getDeployPath()} + "?id=" + uuid.toString() + (password ? ("&p=" + Wt::Utils::hexEncode(std::string {*password})) : "")};

The Wt::LinkType should be InternalPath. But simply change Wt::LinkType::Url to Wt::LinkType::InternalPath will cause another problem: (basing on this doc: https://webtoolkit.eu/wt/doc/reference/html/classWt_1_1WLink.html#a01bddbf88cebda0cf7aa59fd30531718)

For an internal path, the value will be interpreted as a CharEncoding::UTF8 encoded string.

And the url will be encoded, which is unusable. I think that is the limitation of Wt.

I have figured out several possible approaches if they can help:

• Directly download the file, not by generating an url and the user visit it. (I think current way of downloading is a bit insecure because if a share is password-protected, you can download the file through the download link even if he/she doesn't the password of it.)
• Do string joining. I've found Wt::WEnvironment::deploymentPath here https://webtoolkit.eu/wt/doc/reference/html/classWt_1_1WEnvironment.html#a0e18848af468dd624031c9718b6a6c17 , which says "Returns the deployment path.". I guess you can get the path and do string joining. But I tried call this function and I failed 😂.
• Do url decoding. I also find Wt::Utils::urlDecode here https://webtoolkit.eu/wt/doc/reference/html/namespaceWt_1_1Utils.html#a578b89050767856c533d95a48df23ff5 , maybe you can decode the encoded url. I tried but I don't know how to do it 😂.
• Add a setting like proxy-subpath or something else.

[epoupon]

Thanks for your report! Will check these elements.
Why do you feel the current way of downloading is insecure btw? it can be seen as an API which requires a password parameter when the share is password protected. The button's anchor just exposes the password but the user is supposed to have entered this password to make the button display.

[ohmykreee]

That makes sense if treat it as an API.

But one problem is that the download link is easily accessible and static, which means leaking the download link = leaking UUID and password (because the password is encoded with the method of hex, and hex is decodable) = anyone knows the download link can easily access the file.

Maybe you can still keep the API function while make it direct-download when access it from website/browser, and store/check the password with cryptographic hash algorithm like sha-1.

[epoupon]

Yes indeed, the 'API' link itself is very important as it contains the UUID and possibly the password. It is meant to be used for non sensitive stuff if you want to avoid the web page indirection.
The password is already stored using bcrypt, see

fileshelter/conf/fileshelter.conf

Line 73 in a1a6914

bcrypt-count = 12;

The web link to the share (URL mydomain/share-download/uuid ) is meant to be secret, and the password is here when you send the link over an unsecure channel, like an email or whatever.

[ohmykreee]

I see, thanks for your reply ❤️

[epoupon]

ok, should be fixed, see #54