socket.io-file
socket.io-file copied to clipboard
rico345100
Support for upload mode where client provides upload file path
Hi,
My understanding is that right now socket.io-file only supports the upload mode where the server defines a list of upload paths from which the client can then select. I'm looking into making a file upload solution where the client controls the relative path of the file being uploaded within the upload directory set by the server. Such an upload mode would likely need to be enabled by the server in order for the client to use it, but I think it is a valuable upload mode since path configuration is then handled entirely by the client.
Is support for this something that could be considered in socket.io-file?
Hi, I understood what exactly you want, but I think that allow the client set the upload directory might causes security problems. They can upload some malicious files to dangerous path and I think that's quite bad idea.
Your suggestion might be handy some cases, but we need to be cautious. I think this issue is not simple, let me think about this.
I agree that the security of such an upload mode could be a potential concern, but I don't really see how it is any more dangerous to be able to put files into directories under some upload folder on the server compared with putting the same files into one directory. However, the server-side implementation must naturally ensure that a file upload under no circumstance can "escape" outside the dedicated upload folder(s), but that also applies to the current implementation.
Hm, as follow your words adding this feature seems fine with proper "escaping" the path. I will add this soon.
However this feature is quite different than original socket.io-file upload behavior, I have to find a way to keep the original interface but also support this method. So, I'm not sure how much it takes.
Anyway, thanks for good suggestion, I'm gonna tell you after it finish :)
How about simply keeping the existing interface, but allow the client to specify a file name which includes one or more directories, e.g. "/directoryA/file1.ext"? That way it is simply generalizing the existing interface by allowing files to be put into sub-directories of the upload location(s).
Hello, sorry for late answer, I was quite busy recently to finish my projects before leave my company.
Do you still needed your desired feature? I just read whole comments in this page and just think that allow client can specify uploading path still doesn't looks like good idea, even escaping the path from server.
Also from v2.0.14(https://github.com/rico345100/socket.io-file/issues/5), client can't select the path for security reason.
Comment freely you need to discuss about this feature again. Thanks!
Hi,
Yes, I'm very much still looking for this kind of feature.
I still can't see that security is a problem as long as two conditions are enforced: 1) The client can only write to a given root folder or create subfolders to the root folder. 2) The server augments the file name provided by the client so that no existing file is overwritten.
What security concern do you have with such an approach given that the two conditions are assumed valid?
This is actually possible due to a security bug funny enough. Also if it wasn't a security bug, you are asking for trouble by offering this to end users, very bad idea! If you address the use of ./ ../ in the uploadDir variable that is sent to the server then you could potentially be safe about it but it is still ill advised to do this.
Even with path traversal mitigation, I still think this would be a very bad idea. This screams "attack surface", at least to me. What situation would require the client specifying the file path, over the server providing one? This seems like a very odd use case.
I understand the bad feeling, but can't find the specific danger If the uploaded path is not allowed to contain "./" or "../" or special funky characters (in case these are ways to get out in other languages) and all paths are relative to a server decided path, like "/user_data/" then is there a danger?
I understand the bad feeling, but can't find the specific danger If the uploaded path is not allowed to contain "./" or "../" or special funky characters (in case these are ways to get out in other languages) and all paths are relative to a server decided path, like "/user_data/" then is there a danger?
The fact they want to allow this to be done isn't a danger on it's own if done well enough to make sure people don't succeed in path traversal. The danger is that due to a bug this is actually possible without people even needing to code their setup to do this, it's enabled by default for everyone using it whether they know it or not, THAT is the danger here. This as far as I know is still the case as with no attempts made to fix the issue. Either this project is dead or the person in charge of it is dead as https://github.com/rico345100/socket.io-file/issues/34 remains unresolved for many months now and another security issue has been found that is even worse that relies on issue 34 where an attacker can execute code on the server, this package should be avoided until it is fixed!
Agree, project looks dead. Reason for asking about the flaw was because the originator was explicit on his first response "to put files into directories under some upload folder " and objection continued with "generally a bad idea" the am. So I thougth there was more to the objection than the security bug opened.
The other thing I don't get is how is the better than using fetch interface with express-fileupload.