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>
      7447a3d1
  2. 07 Jun, 2022 1 commit
  3. 29 Apr, 2022 1 commit
  4. 02 Feb, 2022 1 commit
  5. 18 Jan, 2022 1 commit
    • Stefan Bürk's avatar
      [TASK] Use proper QueryBuilder execute() replacement methods · 597a92fd
      Stefan Bürk authored and Benni Mack's avatar Benni Mack committed
      doctrine/dbal implemented single purpose method to replace the
      compound 'execute()' in QueryBuilder to avoid the incompatible
      return typehint tuple of 'Doctrine\DBAL\Result|int' in favour
      of 'executeQuery()' and 'executeStatement()' which was added
      forward-compatible with #96247 marking the old one internal
      but not deprecated for now to keep a eventually longer grace
      period to mitigate for extensions developers.
      
      This patch however goes through the core and replace these
      methods to be clean as possible and is a first preparation
      to remove the 'checkThisOnly' option from phpstan which are
      swallowed by this option.
      
      * replace 'execute' with 'executeQuery()' for select and
        count queries generating results ('Doctrine\DBAL\Result').
      * use 'executeStatement()' for insert, update and delete
        queries return affected rows as return value (int)
      * adjust return typehints to match the single return type
        signature on really minor places to match the return type
        of the wrapped replaced execute method.
      * replace one really old 'exec()' from connection with
        corresponding replacement method along the way.
      * add several todos on two places which are weird and do
        not make any sense for further investigation and fixing,
        as declared as out-of-the-scope for this wide-area patch.
      
      Resolves: #96551
      Related: #96247
      Related: #96521
      Releases: main, 11.5
      Change-Id: Ie8d40f3882f1694ab7f7e5053729fa1c798a9c5f
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73032
      
      
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      597a92fd
  6. 12 Oct, 2021 1 commit
  7. 05 Oct, 2021 1 commit
    • Benjamin Franzke's avatar
      [SECURITY] Verify HTTP_HOST via FE/BE middleware · 5cbff855
      Benjamin Franzke authored and Oliver Hader's avatar Oliver Hader committed
      Avoid a dependency cycle between HTTP_HOST generation
      and verification.
      As $GLOBALS['TYPO3_REQUEST'] is not available
      during ServerRequestFactory::fromGlobals(), HTTP_HOST
      verification can not be performed at that point.
      It is therefore delayed into a context aware middleware
      instead of being skipped because of missing $GLOBALS.
      
      Positive advantage of moving the verification into
      frontend and backend middlewares, is that context
      checks to exclude CLI/installtool can be dropped.
      
      As a side effect this also fixes the frontend to installtool
      redirect if TYPO3 is not yet configured and running with
      an invalid SERVER_NAME, as ServerRequestFactory::fromGlobals()
      doesn't fail.
      
      Releases: master
      Resolves: #95395
      Change-Id: Idd3a3449a878cd625dad0d04892d9f0e710ca1a9
      Security-Bulletin: TYPO3-CORE-SA-2021-015
      Security-References: CVE-2021-41114
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/71438
      
      
      Tested-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
      Reviewed-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
      5cbff855
  8. 24 Sep, 2021 1 commit
  9. 29 Jul, 2021 1 commit
  10. 15 Apr, 2020 1 commit
  11. 14 Apr, 2020 1 commit
  12. 13 Apr, 2020 1 commit
  13. 23 Mar, 2020 1 commit
  14. 16 Jan, 2020 1 commit
  15. 14 Aug, 2018 1 commit
  16. 11 Aug, 2018 1 commit
    • Christian Kuhn's avatar
      [TASK] Make password hash selection an install tool preset · 4b695b64
      Christian Kuhn authored
      With this change, the password hash code in salted passwords is
      reduced to the SaltFactory with two methods and the single hash
      classes that implement SaltInterface without further public
      methods. Everything else including the utility classes is
      deprecated.
      The change moves the LocalConfiguration.php config options around,
      adds a settings preset for hash mechanism selection, adds according
      silent upgrades, adds 'best available' hash mechanism selection
      at installation time and drops the last saltedpasswords
      ext_conf_template.txt option.
      
      Details:
      * Remove the password hash selection from saltedpasswords config
        namespace and put to TYPO3_CONF_VARS/BE/passwordHashing/className
        and TYPO3_CONF_VARS/FE/passwordHashing/className
      * Move available password hash registry from
        TYPO3_CONF_VARS/SC_OPTIONS/ext/saltedpasswords/saltMethods
        to TYPO3_CONF_VARS/SYS/availablePasswordHashAlgorithms
      * Add a setting preset to select one of argon2i (preferred),
        bcrypt, pbkdf2 or phpass (last fallback)
      * Use 'best matching preset' during installation to select a good
        salt mechanism by default
      * Silently upgrade existing password hash selection and upgrade
        to one of the four hash algorithms above
      * Allow algorithm specific options in
        TYPO3_CONF_VARS/BE/passwordHashing/options and
        TYPO3_CONF_VARS/FE/passwordHashing/options for admins who
        know what they are doing and need to fiddle with hash details.
      * Simplify and refactor the single password hash classes. Deprecate
        a huge list of methods along the way.
      
      Change-Id: I773e2ee27a121c9f0d5302695ebf4aa561170400
      Resolves: #85804
      Resolves: #83760
      Releases: master
      Reviewed-on: https://review.typo3.org/57850
      
      
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      4b695b64
  17. 09 Aug, 2018 1 commit
  18. 31 Jul, 2018 1 commit
    • Christian Kuhn's avatar
      [TASK] Drop salted passwords configuration options · c2cb6fa9
      Christian Kuhn authored and Andreas Fernandez's avatar Andreas Fernandez committed
      In order to prepare the saltedpasswords extension to be implemented
      as a library into the core directly, a series of configuration
      options is dropped from the extension:
      
      * FE.forceSalted & BE.forceSalted (default 0)
        Setting this to 1 disabled upgrading non-salted user password
        to salted passwords and denied login. The option is dropped, but
        only passwords that have been upgraded from simple md5 or plaintext
        in v8 are allowed to login and will get their password upgraded.
      
      * FE.updatePasswd & BE.updatePasswd (default 1)
        Setting this to 0 disabled upgrading one salted password to
        another. This is dropped: Passwords will now always be upgraded
        to the currently configured hash algorithm if the currently used
        algorithm does no match the configured one.
      
      * FE.onlyAuthService & BE.onlyAuthService (default 0)
        Setting this to 1 allowed stopping the authentication chain if
        the salted passwords did not verify a password. This setting is
        pretty useless since it can be expected that any sane authentication
        provider kicks in before the native salted passwords authentication.
        We found not a single usage of that flag in TER.
      
      * checkConfigurationFE & checkConfigurationFE2
        & checkConfigurationBE & checkConfigurationBE2
        These configuration user function have been responsible to check
        various combinations of valid and invalid salted passwords
        combinations. This is obsolete with removing the other options and the
        deprecated rsaauth extension. An install tool preset for sane options
        and according warnings will be set up to establish better usability
        from an administrator point of view as soon as this patch is done.
      
      The only option left is the main "saltedPWHashingMethod". This will
      be transferred to an install tool preset including best option selection
      during installation in a next step.
      
      Resolves: #85683
      Releases: master
      Change-Id: I7e8150ba9bc8b36f59d08ca5cadeb547e1301f67
      Reviewed-on: https://review.typo3.org/57725
      
      
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Markus Klein's avatarMarkus Klein <markus.klein@typo3.org>
      Tested-by: Markus Klein's avatarMarkus Klein <markus.klein@typo3.org>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      c2cb6fa9
  19. 22 Jun, 2018 1 commit
  20. 25 Apr, 2018 1 commit
  21. 26 Mar, 2018 1 commit
  22. 18 Mar, 2018 1 commit
  23. 30 Nov, 2017 1 commit
  24. 12 Oct, 2017 1 commit
    • Christian Kuhn's avatar
      [TASK] Deprecate ConfigurationForm · 906684cb
      Christian Kuhn authored
      The call tree of the extension manager "configuration form"
      ext_conf_template.txt parser is a mess:
      The ext:extensionmanager ConfigurationUtility calls ext:core
      ConfigurationForm which is a class that extends ExtendedTemplateService
      which extends TemplateService. The "TypoScript" a-like parsing then uses
      class TypoScriptParser. This compiles to a huge list of dependencies.
      
      The patch compiles this mess down to a series of methods within
      ConfigurationUtility directly, effectively adding needed parts
      of TypoScriptParser and ConfigurationForm as protected methods.
      The class ends up with way less direct and indirect dependencies.
      
      The various detail parsing methods are still messy and hard to follow,
      but rewriting the parser heart does not really make sense since the
      ext_conf_template.txt format will bite the dust sooner or later anyway
      and having all in one place is already much better than before.
      So putting some days of energy into rewriting these specific parts
      of the TypoScript parsing did not seem to be worth it, even if it in
      the end could probably solved with 1/4 of code.
      
      Class ConfigurationForm is deprecated but could also be removed
      as breaking patch later if anyone wants to refactor the remaining
      ExtendedTemplateService and TemplateService classes in v9.
      
      Note this patch is an intermediate step before the ConfigurationUtility
      class form ext:em is moved into the install tool.
      
      Change-Id: I62d9fafb6444d954e17c980358e6367a83b033b8
      Resolves: #82725
      Releases: master
      Reviewed-on: https://review.typo3.org/54362
      
      
      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: Wouter Wolters's avatarWouter Wolters <typo3@wouterwolters.nl>
      Reviewed-by: Mona Muzaffar's avatarMona Muzaffar <mona.muzaffar@gmx.de>
      Tested-by: Mona Muzaffar's avatarMona Muzaffar <mona.muzaffar@gmx.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      906684cb
  25. 22 Aug, 2017 1 commit
  26. 12 May, 2017 1 commit
  27. 01 Mar, 2017 1 commit
  28. 01 Dec, 2016 1 commit
  29. 26 Oct, 2016 1 commit
  30. 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>
      4a4bf359
  31. 30 Aug, 2016 1 commit
  32. 09 Jun, 2016 1 commit
  33. 08 Jan, 2016 2 commits
  34. 08 Oct, 2015 1 commit
  35. 18 Jul, 2015 1 commit
  36. 15 Jul, 2015 2 commits
  37. 07 Jul, 2015 1 commit
  38. 27 Mar, 2015 1 commit