1. 14 Jun, 2022 1 commit
    • Torben Hansen's avatar
      [SECURITY] Restrict export functionality to allowed users · 7447a3d1
      Torben Hansen authored and Oliver Hader's avatar Oliver Hader committed
      The import functionality of the import/export module is already
      restricted to admin users or users, who explicitly have access through
      the user TSConfig setting "options.impexp.enableImportForNonAdminUser".
      The export functionality has the following security drawbacks:
      * Export for editors is not limited on field level
      * The "Save to filename" functionality saves to a shared folder, which
        other editors with different access rights may have access to.
      Both issues are not easy to resolve and also the target audience for
      the Import/Export functionality are mainly TYPO3 admins.
      Therefore, now also the export functionality is restricted to TYPO3
      admin users and to users, who explicitly have access through the new
      user TSConfig setting "options.impexp.enableExportForNonAdminUser".
      Additionally, the contents of the temporary "importexport" folder in
      file storages is now only visible to users who have access to the
      export functionality.
      In general, it is recommended to only install the Import/Export
      extension when the functionality is required.
      Resolves: #94951
      Releases: main, 11.5, 10.4
      Change-Id: Iae020baf051aeec0613366687aa8ebcbf9b3d8b2
      Security-Bulletin: TYPO3-CORE-SA-2022-001
      Security-References: CVE-2022-31046
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74902
      Tested-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
      Reviewed-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
  2. 15 Feb, 2022 1 commit
  3. 07 Dec, 2021 1 commit
  4. 24 Mar, 2021 1 commit
  5. 16 Jan, 2020 1 commit
  6. 27 Dec, 2019 1 commit
  7. 04 Oct, 2019 2 commits
  8. 11 Sep, 2018 1 commit
  9. 14 Aug, 2018 1 commit
  10. 22 Jun, 2018 1 commit
  11. 26 Mar, 2018 1 commit
  12. 14 Mar, 2018 1 commit
  13. 04 Oct, 2017 1 commit
    • Benni Mack's avatar
      [!!!][TASK] Use native trigger_error and ErrorHandler for deprecations · 95b13dca
      Benni Mack authored and Christian Kuhn's avatar Christian Kuhn committed
      The native PHP way of triggering deprecations by a framework or
      applications is done via
      `trigger_error($deprecationMessage, E_USER_DEPRECATED)`.
      Previously, TYPO3 used `GeneralUtility::deprecationLog()` and
      similar methods to generate a custom deprecation log, however it's
      more flexible to use native logging through TYPO3's ErrorHandler.
      This solution centralizes the way to configure the place if and
      how deprecation logs should be written to various log destinations.
      This also changes the way how deprecated methods, arguments and classes
      are handled.
      The new way to deprecate code in TYPO3 is done via
      `trigger_error()`, the @deprecated annotation within a method only
      exists now for IDE support, but is not reflected anymore for the
      logging message.
      That's why the @deprecated annotation does not contain
      a description anymore.
      The methods
      are marked as deprecated from now on.
      The configuration option $TYPO3_CONF_VARS[SYS][enableDeprecationLog]
      is removed.
      Deprecation messages can now be activated by adding
      the E_USER_DEPRECATED constant to the respective values in
       (so exceptions are handled by the TYPO3 error handler)
       (so exceptions are put into GeneralUtility::sysLog)
       (so exceptions are put into sys_log DB table)
       (so exceptions are thrown on a deprecation)
      Deprecations will still go into GeneralUtility::devLog(),
      if deprecations are activated via the "errorHandlerErrors" option.
      Tests which test explicitly for deprecated code is moved into
      Tests/UnitDeprecated, to ensure that the deprecated code is not
      throwing an exception.
      Resolves: #82438
      Releases: master
      Change-Id: I6ef9a642d179001f0484c4c7678e0bec12284faf
      Reviewed-on: https://review.typo3.org/54015
      Reviewed-by: Susanne Moog's avatarSusanne Moog <susanne.moog@typo3.org>
      Tested-by: Susanne Moog's avatarSusanne Moog <susanne.moog@typo3.org>
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  14. 20 Mar, 2017 1 commit
  15. 01 Mar, 2017 1 commit
  16. 04 Dec, 2016 1 commit
  17. 25 Oct, 2016 1 commit
  18. 13 Sep, 2016 1 commit
    • Helmut Hummel's avatar
      [!!!][SECURITY] Mitigate potential cache flooding · 4a4bf359
      Helmut Hummel authored and Oliver Hader's avatar Oliver Hader committed
      Bind cHash to the page id it was generated for, to avoid
      an attacker to be able to call multiple pages with the same
      cHash arguments and thus create unnecessary cache entries.
      We now add the id argument to the cHash calculation, but only
      if there are other arguments in the URI which would require a cHash.
      This avoids multiple cache entries for one page
      (one with and one without cHash).
      We ignore other core parameters like "type" and "MP", because the possibility
      to create unnecessary cache entries by manipulating these is very limited
      and thus an attack not feasible.
      Adapted tests to show our new expectations for cHash calculations.
      The new behavior is default for new installations, but not for on for existing
      installations, as an update would break the site with a high probability.
      By adding the configuration option, we'll give users the chance to
      pull the trigger once everything is prepared, but still get other
      security issues fixed with the release.
      Resolves: #76462
      Releases: master, 8.3, 7.6, 6.2
      Security-Commit: d97bb1cc1aea4a616db0665b60366a1a23f5ee50
      Security-Bulletins: TYPO3-CORE-SA-2016-020, 021
      Change-Id: Id8801b7b7d86b65ecaa2ca5e9bb14c27d4268aee
      Reviewed-on: https://review.typo3.org/49925
      Reviewed-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
      Tested-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
  19. 22 Aug, 2016 1 commit
  20. 04 Mar, 2016 1 commit
  21. 09 Jan, 2016 1 commit
  22. 28 Oct, 2015 1 commit
  23. 21 Jul, 2015 1 commit
  24. 15 Jul, 2015 1 commit
  25. 30 Jun, 2015 1 commit
  26. 30 Mar, 2015 4 commits
  27. 27 Mar, 2015 1 commit
  28. 14 Nov, 2014 1 commit
  29. 10 Nov, 2014 1 commit
  30. 24 Mar, 2014 1 commit
    • Jigal van Hemert's avatar
      [TASK] Add warning in Reports module if content adapter is active · fac12e2a
      Jigal van Hemert authored
      The setting [FE][activateContentAdapter] has a large impact on
      performance. A warning in the Reports module will encourage
      integrators to adapt TypoScript to increase performance.
      Resolves: #57249
      Releases: 6.2
      Change-Id: I935b86ba701d3b0dbac3b807a1ae9312bff223fc
      Reviewed-on: https://review.typo3.org/28724
      Reviewed-by: Wouter Wolters
      Reviewed-by: Alexander Opitz
      Tested-by: Alexander Opitz
      Reviewed-by: Markus Klein
      Tested-by: Markus Klein
  31. 09 Sep, 2013 1 commit
  32. 27 Aug, 2013 1 commit
    • Nicole Cordes's avatar
      [TASK] ext:saltedpasswords: Remove isUsageEnabled for backend · ef335ab2
      Nicole Cordes authored and Wouter Wolters's avatar Wouter Wolters committed
      Remove all calls on SaltedPasswordsUtility::isUsageEnabled('BE')
      as backend is enabled by default. Besides remove all
      ExtensionManagementUtility::isLoaded('saltedpasswords') as
      extension is loaded by default.
      Change-Id: Ie2332fc3c6c454888afc8c9956b9869309623584
      Resolves: #51356
      Releases: 6.2
      Reviewed-on: https://review.typo3.org/23375
      Reviewed-by: Christian Kuhn
      Tested-by: Christian Kuhn
      Reviewed-by: Wouter Wolters
      Tested-by: Wouter Wolters
  33. 07 Feb, 2013 1 commit
  34. 29 Jan, 2013 1 commit
    • Christian Kuhn's avatar
      [TASK] EXT:reports Improve xclass reporting · acb3f1b9
      Christian Kuhn authored
      Since TYPO3 CMS 6.0, the XCLASS registration changed and the old
      registration style does not work anymore. Additionally, 6.0 comes
      with a basic check for old XCLASS registration to warn users about
      The patch adds a new report for newly registered XCLASS'es and
      adapts the messages to better notify that neither old nor new
      registrations are a real problem, but that those classes should
      be kept an eye on during upgrading.
      Change-Id: I8c0052b9c7fb0e88aff62a71c9592bf51bcec7ad
      Resolves: #44895
      Releases: 6.1, 6.0
      Reviewed-on: https://review.typo3.org/17776
      Reviewed-by: Wouter Wolters
      Tested-by: Wouter Wolters
      Reviewed-by: Jigal van Hemert
      Tested-by: Jigal van Hemert
  35. 21 Oct, 2012 1 commit
  36. 18 Aug, 2012 1 commit
    • Christian Kuhn's avatar
      [FEATURE] Report status check for file and folder create mask · 24e9d42c
      Christian Kuhn authored
      In sane server setups, it is usually not a good idea to configure TYPO3
      to create files and folders with writable bit for 'others'. The
      introduction package actually sets fileCreateMask and folderCreateMask
      to 666 and 777, but this is to ease the installation process and make
      the introduction package work in curious setups as well without problems.
      Therefore we now add a warning to the reports module instead, if the
      write bit for others is set, so an administrator is informed on the
      possible security impact, while the installation process is still smooth.
      Change-Id: Iae75a9f9492d8b784a3e1ea2c754a14abbc58f3e
      Releases: 6.0
      Resolves: #39912
      Reviewed-on: http://review.typo3.org/13874
      Reviewed-by: Helmut Hummel
      Tested-by: Helmut Hummel