Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Files accessible by other customers/even public #24

Open
rfc2822 opened this issue Jul 23, 2019 · 2 comments
Open

Files accessible by other customers/even public #24

rfc2822 opened this issue Jul 23, 2019 · 2 comments

Comments

@rfc2822
Copy link

rfc2822 commented Jul 23, 2019

Hello,

When evaluating Form Tools I found that uploaded files are put to /uploads and then served statically (without access control). The file names are kept as sent by the browser, so they can be guessed easier than UUIDs or something like that. So, those uploaded files can be accessed

  • either when the name can be guessed or when
  • auto-index overrides the empty index.html (for instance, because autoindex is active and index.html is not in the index files list)

by

  • other customers (who should not see the files of other customers) and,
  • if there is no additional protection, even publicly.

I have found real installations in the Web where private uploads were publicy accessible.

To prevent this, files should probably not be served statically, but only over a script which checks whether the current user is allowed to download the respective file.

@benkeen
Copy link
Member

benkeen commented Jul 24, 2019

Hey @rfc2822, thanks very much for your post!

Yes, the default upload folder is just [form tools root]/upload. This is just a convenient out-the-box location that guarantees to exist after a Form Tools installation is set up. But like you said, that location is publicly accessible and isn't secure.

(You mentioned "auto-index? I'm not aware of what that is... that's a server setting that somehow overrides the default index.html file? Interesting...)

But yes, what you mentioned - using a script to determine whether the user has access to the file - is certainly an option, but in many cases people won't want that. It's often used just to house public data. It sounds like what's really needed is an option to enable a more secure setting for certain scenarios.

That said, people still have options beyond what you mentioned:

  • they can use the filename renaming option to totally customize the uploaded filenames and make them unlikely to be guessed, e.g. including unix timestamps or something (see: https://docs.formtools.org/modules/field_type_file/filenames/)
  • change the upload folder to be outside the webroot. This would be the most effective solution to prevent people ever accessing the content from the web-browser. However I think that would make it a one-way trip. They couldn't download it again via a URL of course.

But this is certainly something worth looking at further. Great points!

@rfc2822
Copy link
Author

rfc2822 commented Jul 24, 2019

(You mentioned "auto-index? I'm not aware of what that is... that's a server setting that somehow overrides the default index.html file? Interesting...)

Configurations may enable auto-index and set the index file to index.php only (instead of index.html and index.php). It seems like I have found such a configuration quite easily.

change the upload folder to be outside the webroot. This would be the most effective solution to prevent people ever accessing the content from the web-browser. However I think that would make it a one-way trip. They couldn't download it again via a URL of course.

Sounds like a good solution for my case, thanks!

Then I'll only have to manage to create a script that takes the CSV, reads all lines, fetches the mentioned files from the server and puts alltogether (CSV + referenced files) into a ZIP, because this is the format the customer needs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants