Project

General

Profile

Actions

Feature #104364

open

Better restrict file access when dealing with private storages

Added by Jan Kornblum 7 months ago. Updated 16 days ago.

Status:
Under Review
Priority:
Should have
Assignee:
-
Category:
Security
Start date:
2024-07-11
Due date:
% Done:

0%

Estimated time:
PHP Version:
8.3
Tags:
private, storage, file, access, eID, dumpFile
Complexity:
Sprint Focus:

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?


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #81361: File dump in TYPO3 BE insecure because login status is not checkedClosedFrans Saris2017-05-29

Actions
Actions #1

Updated by Georg Ringer 7 months ago

  • Assignee deleted (Oliver Hader)
Actions #2

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

Actions #3

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

Actions #4

Updated by Jan Kornblum 7 months ago

  • Related to Bug #81361: File dump in TYPO3 BE insecure because login status is not checked added
Actions #5

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
Actions #6

Updated by Jan Kornblum 7 months ago

  • Target version set to Candidate for patchlevel
Actions #7

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
  • 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)
Actions

Also available in: Atom PDF