Published Files Security Issues (Dropbox)

[KyleKotowick]

Following up from issue #1823, I'm having some concerns with file security when using the Dropbox driver.

If I use the following code in the client configuration:

getFileCallback : function(file, fm) {
	fm.exec('open', file.hash);
}

Then when you open a file, it will open the published link on Dropbox. For example, I have a text file and when I double click it, it will open a window with the URL as https://dl.dropboxusercontent.com/s/wlf01gfuofh6k9q/test.txt. This file, even though I have it in a private Dropbox folder and the elFinder connector restricts access to it to specific users, is now publicly accessible at this URL. There are two issues here:

1. anyone sniffing the wifi network I'm using will see that I sent a request to this URL, and they can then copy-paste that into their own browser and see the file

2. it seems that once a file is published this way, it remains public forever (or at least, for the several weeks since I opened the test file last). So there is no way to protect this file again after opening it once

Is there any way to prevent elFinder from EVER publicly publishing a Dropbox file? Make it so that elFinder gets the file contents through the API internally, then sends them to the browser window? i.e. make it so that the client will never see a Dropbox URL anywhere?

It should be noted that this has to be a configuration on the connector (server-side), since anyone could modify the javascript on the client's end (so a client-side configuration option is insufficient).

[KyleKotowick]

After some more research, it looks like this is happening on line 892 of elFinderVolumeDropbox.class.php. It's using the /shares endpoint of the Dropbox API, which creates a permanent share link. At an absolute minimum, it should be using the /media endpoint instead, which creates a link that is good for 4 hours. Although even for the /media endpoint, the documentation explicitly states:

This URL should not be used to display content directly in the browser.

And that's for the reasons that I mentioned in the OP (anyone sniffing the connection could see a request to that URL and visit it themselves). I think the only real solution is to either:

1. instead of using the /shares API endpoint to view the file, get the file contents internally using the /files (GET) endpoint, then output it in its entirety to the browser, OR

2. use the /media endpoint to create a temporary link to the file, then stream the contents to the browser through the connector file

I think these are the only ways you will have any real security here.

[nao-pon]

@kkotowick Other net drive drivers such as GoogleDrive also have similar problems.

I am trying to solve this problem by adding url to disabled of the connector 's volume root option.

Thanks!