Project

General

Profile

Actions
Copy link

Feature #104364

open

Better restrict frontend file access when dealing with private storages

Added by Jan Kornblum 5 days ago. Updated 2 days ago.

Status:
Under Review
Priority:
Should have
Assignee:
-
Category:
Security
Target version:
-
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?

Actions
Copy link

Also available in: Atom PDF