Project

General

Profile

Actions

Bug #22348

open

Epic #90674: Backend UI not reflecting permissions

Security problem with flexforms, especially extbase and overriding not allowed values

Added by Georg Ringer about 14 years ago. Updated about 4 years ago.

Status:
Accepted
Priority:
Should have
Assignee:
-
Category:
Security
Target version:
-
Start date:
2010-03-29
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.4
PHP Version:
5.2
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

Description:
-----------------
A user can save anything in the flexform field by using e.g. firebug and
modifiying the name-attribute of the fields. Extbase is configured to
merge flexform and typoscript settings automatically and further more it
uses specific keywords to set e.g. the used templates.

For example: Any textarea / input field can be changed to save data into
the field "view.templateRootPath" which is then used as template path.

Problem:
----------------
If a user has the rights to create html files or maybe the right to
upload files to a specific folder in fileadmin/, he can change the
template of any extbase extension he has access to.

Problem with pibase:
----------------
As there is no speficic keyword for the pibase extension it is not that
easy there. Of course if an extension merges every flexform setting with
the TS settings itself, the same problem occurs.

Possible Solution:
----------------
I don't know if the proposed solution is the correct one but IMO before
the record is saved/updated, it needs to be checked if every flexform
field is existing in the flexform file.

IMO there is at least one problem: If the flexform file is extended by
the extension author, old and unsed sections remain in the database
because everything is merged there.

(issue imported from #M13955)

Actions #1

Updated by Helmut Hummel over 10 years ago

  • Project changed from 1716 to TYPO3 Core

This might theoretically be security relevant, but there is currently no (not that we know) exploit possibility, so there is no benefit in keeping this fact secret.

In contrast we should educate developers about the potential impact of making critical configuration available in settings.

Actions #2

Updated by Nicole Cordes almost 10 years ago

  • Assignee set to Nicole Cordes
  • Is Regression set to No
Actions #3

Updated by Alexander Opitz over 8 years ago

  • Target version deleted (4.6.0)
Actions #4

Updated by Susanne Moog over 6 years ago

  • Category set to Security
Actions #5

Updated by Georg Ringer about 4 years ago

  • Status changed from New to Closed

with #88496 switchablecontrolleractions have been deprecated. this will also solve this issue

Actions #6

Updated by Georg Ringer about 4 years ago

  • Status changed from Closed to Accepted
Actions #7

Updated by Nicole Cordes about 4 years ago

  • Assignee deleted (Nicole Cordes)
Actions #8

Updated by Riccardo De Contardi about 4 years ago

  • Parent task set to #90674
Actions

Also available in: Atom PDF