Create secured temporary /files tmp directory (or) create hash on uploaded tmp files

Created on 12 October 2016, about 8 years ago
Updated 18 June 2023, over 1 year ago

Given the most recent PSA: https://www.drupal.org/psa-2016-003 β†’ and diving into the workings of why it happened, brought the idea up that "maybe" Drupal needs to create a secured temporary file directory within /files that is only accessible to Drupal and the webserver (not public).

With PSA-2016-003 and the public file system, "if" a file is allowed to upload by anonymous (or anybody who can upload a file really), a temporary file is created and accessible to the public. This creates an open door for anyone to access provided they have the URL. To mitigate the problem, the site builder must either convert the entire file system to private, otherwise it is left up to each individual module to provide a private upload method that can be different than the sitewide public method.

What I propose to mitigate this problem in the future, since Drupal itself is not mitigating this, is to have Drupal either create a temporary /files/tmp folder that is not accessible to the public where all tmp files are subsequently stored, or, create some sort of hash on the uploaded temporary file that is impossible for the uploading party to decipher. For the example of image.jpg, it would be uploaded and renamed to GbJvyf-image.jpg. (IMO, they should be hashed last, after they are sanitized through modules like transliteration) This method would require some obvious DB overhead within Drupal to maintain and properly deal with the hashed files, then remove the hash and rename them once they are permanently placed.

If the secured /files/tmp directory is used, I believe securing this folder across various website servers and hosting platforms might be somewhat difficult to accomplish. (apache vs nginx vs lightspeed etc).

The main idea of this is to allow anonymous and authenticated uploads by any module, but secure those temporary files until the system has decided what needs to happen with it.

Without some sort of security measure in place on this matter, it doesn't matter if the user is trusted or authenticated because they can still mitigate this security hole. Since temporary files are not logged (that I know of), there is no way for a site builder to even know that a trusted / authenticated user is out there uploading files with the sole purpose of mitigating this security hole and if cron is set to run at a longer interval, those files can potentially be indexed and accessible out in the wild for quite some time.

✨ Feature request
Status

Closed: outdated

Version

11.0 πŸ”₯

Component
File systemΒ  β†’

Last updated about 11 hours ago

Created by

πŸ‡ΊπŸ‡ΈUnited States philsward

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.71.5 2024