Feature #104364
openBetter 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 Gerrit Code Review 7 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 7 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 7 months ago
- Related to Bug #81361: File dump in TYPO3 BE insecure because login status is not checked added
Updated by Jan Kornblum 7 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 7 months ago
- Target version set to Candidate for patchlevel
Updated by Oliver Hader 16 days ago
Having a rate-limiter that catches the invalid requests (most probably brute force, since the HMAC token did not match) seems to be very useful.
However, for additional restrictions, there probably should be a new configuration for file storages - the current "is publicly available" is misleading and was interpreted differently in the past.
Thus, there might be a new sys_file_storage.content_restriction
which could be
- complete/full → no file content can be retrieved by file-dump-controller, nor are any thumbnails generated
- just the meta-data in
sys_file
can be accessed via the backend user interface - individual implementations still can use the FAL low-level API directly to retrieve file contents
- having this
complete/full
mode should be discussed further
- just the meta-data in
- granted-backend-users → only backend users with corresponding permissions can retrieve file content in the UI
- always requires an active backend user session
- always requires, that the current user has granted permission to the file-mount at the time of accessing file contents
- no-restriction → file contents can always be retrieved
- that's basically the current situation in
eID=dumpFile
(FileDumpController
)
- that's basically the current situation in