Feature #104364
open
Better restrict file access when dealing with private storages
0%
Description
When working with private storages (outside web root), access to any file from frontend context (typolink, image view helper, etc.) is automatically handled by core using the "eID=dumpFile" functionality. So access to any file is (theoretically) possible when the token is known (or guessed). Core documentation says, the "ModifyFileDumpEvent" can be used to restrict this file access...
In my opinion, an integrator or developer should be able to rely on, that when making a storage physically "private", there is absolutely no file access possible per default. Could the current behavior be changed by either one of the following ways:
- The "eID=dumpFile" should deny file access from frontend per default. Any access must be explicitly implemented using the "ModifyFileDumpEvent" (or by any other project specific implementation).
- The "eID=dumpFile" functionality should be extended and a rate limiter should get involved (to limit any brute force attacks).
What do you think?
Updated by
Updated by Gerrit Code Review 4 months ago
- Status changed from New to Under Review
Patch set 1 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/85254
Updated by Gerrit Code Review 4 months ago
Patch set 2 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/85254
Updated by Jan Kornblum 4 months ago
- Related to Bug #81361: File dump in TYPO3 BE insecure because login status is not checked added
Updated by Jan Kornblum 4 months ago
- Subject changed from Better restrict frontend file access when dealing with private storages to Better restrict file access when dealing with private storages
Updated by Jan Kornblum 4 months ago
- Target version set to Candidate for patchlevel