The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
When a webform has a managed_file element, which is set to be encrypted, only the value of the field is encrypted, but not the file itself. I think it's a fair assumption that this is not the expected behaviour.
The severity of this is mitigated for three reasons:
- Anonymous files can only be uploaded to
private. - The links to the files are only displayed if the user can see encrypted webform values.
- If someone tries to directly access the file by using a direct url, the user is required to have permission to view the webform submission.
Still, if someone could somehow figure out the internal path to the file, and had access to private files, they would see the unencrypted file.
Discovered while trying to reproduce #3035804: Access encrypted file uploaded by anonymous user
Proposed resolution
Figure out if we can actually encrypt the file's content before saving to disk.
Remaining tasks
- Fix it.
- Add test coverage.
User interface changes
None.
API changes
None?
Data model changes
None
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 3038902-6.patch | 6.16 KB | manuel garcia |
| #6 | interdiff-3038902-5-6.txt | 3.89 KB | manuel garcia |
| #5 | 3038902-5.patch | 6.02 KB | manuel garcia |
| #5 | interdiff-3038902-2-5.txt | 1.84 KB | manuel garcia |
| #4 | Screenshot from 2019-03-10 10-03-06.png | 35.6 KB | manuel garcia |
Comments
Comment #2
manuel garcia commentedMoving here the patch on #3035804: Access encrypted file uploaded by anonymous user which verifies access to files uploaded to webform.
Note that this not yet includes coverage for the reported bug, but I feel we can iterate on it here.
Comment #3
manuel garcia commentedComment #4
manuel garcia commentedAlso noticing that instead of showing
[Value Encrypted], it is showingTest File {Empty}Comment #5
manuel garcia commentedHere is coverage for the bug itself, which should fail.
Discovered another mitigation factor I've found while writing the test: the user directly accessing the uploaded file must have access to view the webform submission.
Comment #6
manuel garcia commentedOK I had to make some changes to the test to get this going, using an asset text file to simplify things and making sure to remove the new line from the string returned by file_get_contents.
Also added an assertion to verify that when the user has the
'view encrypted values'he can actually see the original content of the file.It should hopefully come back red, verifying the reported bug.
Comment #8
JvE commentedAs a workaround we've installed the file_encrypt module and created a
"webform"encryption profile.This allows you to choose the 'encrypt' filesystem when configuring file upload elements in a webform.
Comment #9
manuel garcia commentedThank you @JvE for sharing your workaround here. I believe that is probably the best approach to doing this right now, and perhaps webform_encrypt should not be responsible for encrypting the files themselves and outsource that to file_encrypt module.
I believe the best we could do without adding too much complexity here would be to warn the user if they configure a webform field with files to be encrypted to also use file_encrypt module. Or just document it in the README / Project page?
Comment #10
malcomio commentedUsing file_encrypt seems to work for us, although we have found #3123160: Incorrect URLs for files uploaded via webform with file_encrypt .
Comment #11
robcarrSix years on and File Encrypt still the only way to solve this. It works.
The solution in this module (Webform Encrypt) apparently only encrypts the filename in the database