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. 28 May, 2022 1 commit
  4. 11 May, 2022 1 commit
  5. 01 Apr, 2022 1 commit
    • Christian Kuhn's avatar
      [!!!][TASK] Simplify TCA authMode settings · 2f0338a9
      Christian Kuhn authored and Benni Mack's avatar Benni Mack committed
      To prepare towards a deployable backend group access
      rights system, some of the more obscure options are
      removed to reduce overall complexity.
      
      * TYPO3_CONF_VARS['BE']['explicitADmode'] is finally
        gone: Following a deny list approach is a flawed security
        system. TYPO3's default setting (explicitADmode=allow)
        follows the very common "Least Privileged" principle,
        so editors need to be explicitly given access to a
        CType, as is done with all other permissions.
      
      * The only valid value for TCA config option "authMode"
        on type="select" fields is now "explicitAllow". The
        previous "explicitDeny" value is abandoned following
        the reasoning above. The value "individual" is abandoned
        since it is a very rarely used setting (not a single
        match in TER).
      
      * With authMode="individual" being gone, the select item
        array keys on position six that could be set to "EXPL_DENY"
        and "EXPL_ALLOW" are obsolete.
      
      * Field "explicit_allowdeny" in table be_groups is
        simplified. This was a comma separated list of
        colon separated: "table:field:value:ALLOW/DENY".
        The last "ALLOW" or "DENY" is now obsolete.
      
      The patch removes the above handling from the core. A
      TCA migration scans TCA for invalid options and adapts
      them. An upgrade wizard is in place to clean up the
      be_groups explicit_allowdeny field of existing rows.
      
      Resolves: #97265
      Releases: main
      Change-Id: I545b08fc694e9081ad79e69e7f55f684316e7b0f
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74126
      
      
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      2f0338a9
  6. 14 Mar, 2022 1 commit
  7. 09 Mar, 2022 2 commits
  8. 07 Mar, 2022 1 commit
    • Stefan Bürk's avatar
      [TASK] Replace 'CompositeExpression->add()' usage · 81bb030e
      Stefan Bürk authored and Benni Mack's avatar Benni Mack committed
      doctrine/dbal moves their classes forward and deprecated
      some stuff while providing replacement for it. This has
      been early adopted for the core facade classes with #97081
      in a forward-compatible way. Before deprecating the old
      methods core usage have to be replaced.
      
      This patch replaces the usage of 'CompositeExpression::add()'
      with the immutable way using 'with()' with re-assigning the
      returned instance to the used variable.
      
      In general this means that following usage example:
      
        $or = CompositeExpression::or();
        $or->add($queryBuilder->expr()->eq(...));
      
      will be replaced with:
      
        $or = CompositeExpression::or();
        $or = $or->with($queryBuilder->expr()->eq(...));
      
      Alternativly this could be refactored collecting parts in a
      array first and add them later with one 'with()' call or by
      directly creating the 'or()' or 'and()' CompositeExpression
      with the provided parts directly - which would have been a
      larger and harder to review patch. Thus this patch does the
      simple replacement to have minimal changes for easier review
      experience.
      
      Resolves: #97124
      Related: #97081
      Releases: main
      Change-Id: I00fde09593e1c1ccb2949daaec3ee4aa688dda63
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73833
      
      
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Nikita Hovratov's avatarNikita Hovratov <nikita.h@live.de>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Nikita Hovratov's avatarNikita Hovratov <nikita.h@live.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      81bb030e
  9. 05 Mar, 2022 1 commit
  10. 04 Mar, 2022 1 commit
  11. 11 Feb, 2022 1 commit
  12. 07 Feb, 2022 1 commit
    • Oliver Bartsch's avatar
      [!!!][FEATURE] New Module Registration API · 29db88c3
      Oliver Bartsch authored and Benni Mack's avatar Benni Mack committed
      This change introduces a new way to register
      TYPO3 Backend Modules.
      
      Each module is now registered during build-time
      in a dedicated registry. Therefore, The registration
      is moved from ext_tables.php to the
      Configuration/Backend/Modules.php file.
      
      Accessing the registered modules can be done via
      a central API, the ModuleProvider class. This class
      takes care of access permissions and further
      processing (e.g. module menu generation).
      
      $GLOBALS[TBE_MODULES] is fully removed as no sane
      backwards-compatibility (for a use-case) is available.
      
      A new PSR-14 event BeforeModuleCreationEvent is added,
      which allows to manipulate a module configuration, before
      it is used to create and register the module.
      
      Existing registrations do no longer work. However, to support
      extenion authors in maintaining multiple versions, the previously
      used API methods (e.g. `addModule` and `registerModule`) will
      stay until TYPO3 v13.0. No trigger_error() is used, so extension
      authors use the Extension Scanner to detect usages.
      
      Executed commands:
      
         composer u typo3/cms-styleguide
      
      Resolves: #96733
      Releases: main
      Change-Id: I07f4bc417e6effb1215cf0e373cc60f2b13ba8ad
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73058
      
      
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      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>
      29db88c3
  13. 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
  14. 08 Jan, 2022 1 commit
  15. 04 Jan, 2022 1 commit
  16. 20 Dec, 2021 1 commit
  17. 07 Dec, 2021 1 commit
  18. 05 Dec, 2021 1 commit
  19. 19 Nov, 2021 1 commit
  20. 15 Nov, 2021 1 commit
  21. 27 Oct, 2021 1 commit
  22. 11 Oct, 2021 2 commits
  23. 24 Sep, 2021 3 commits
  24. 22 Sep, 2021 1 commit
  25. 24 Aug, 2021 1 commit
  26. 23 Aug, 2021 1 commit
  27. 08 Aug, 2021 1 commit
  28. 03 Aug, 2021 1 commit
  29. 29 Jul, 2021 2 commits
  30. 28 Jul, 2021 1 commit
  31. 22 Jul, 2021 1 commit
  32. 01 Jul, 2021 1 commit
  33. 28 Jun, 2021 1 commit
  34. 01 Jun, 2021 1 commit
  35. 27 May, 2021 1 commit