1. 21 Jun, 2022 1 commit
  2. 17 Jun, 2022 1 commit
  3. 24 May, 2022 1 commit
  4. 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
  5. 28 Feb, 2022 1 commit
  6. 22 Feb, 2022 1 commit
  7. 21 Feb, 2022 1 commit
  8. 14 Feb, 2022 1 commit
  9. 09 Feb, 2022 1 commit
  10. 16 Jan, 2022 1 commit
  11. 23 Dec, 2021 1 commit
  12. 13 Nov, 2021 1 commit
  13. 16 Sep, 2021 1 commit
  14. 30 Aug, 2021 2 commits
  15. 16 Aug, 2021 1 commit
    • Oliver Hader's avatar
      [BUGFIX] Adjust default behavior of HTML sanitization in parseFunc · 6a197e75
      Oliver Hader authored and Benni Mack's avatar Benni Mack committed
      As a result of TYPO3-CORE-SA-2021-013, new `htmlSanitize` behavior -
      when invoking `ContentObjectRenderer::parseFunc` - is enabled per
      default, in case it was not declared otherwise. That also happened
      when no processing configuration was given (or could be resolved).
      Without having any configuration, it was obviously not possible to
      disable `htmlSanitize`.
      
      Fluid's `HtmlViewHelper` can be used with an empty `parseFuncTSPath`
      (e.g. `<f:format.html parseFuncTSPath="">`) - due to missing (empty)
      configuration, sanitization was enabled per default in `parseFunc`.
      
      With this change, property `htmlSanitize` either needs to be enabled
      or disabled explicitly - otherwise deprecation logs will be generated,
      if not given, the fall-back behavior is inferred from new feature flag
      `security.frontend.htmlSanitizeParseFuncDefault`.
      
      Invoking `ContentObjectRenderer::parseFunc` without any configuration
      behaves like before TYPO3-CORE-SA-2021-013 was applied - it just does
      not process anything.
      
      Resolves: #94786
      Releases: master, 11.3, 10.4, 9.5
      Change-Id: I4aee54d712ce4758f6c9c2e64a43f80b6c076406
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70404
      
      
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Helmut Hummel's avatarHelmut Hummel <typo3@helhum.io>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Helmut Hummel's avatarHelmut Hummel <typo3@helhum.io>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      6a197e75
  16. 13 Aug, 2021 1 commit
  17. 10 Aug, 2021 1 commit
    • Oliver Hader's avatar
      [SECURITY] Ensure XSS-safe rich text rendering · 3dca584c
      Oliver Hader authored and Oliver Hader's avatar Oliver Hader committed
      Due to missing internal handling of provided RTE configuration, it
      was possible to directly persist XSS in database fields. Unless full
      blown backend RTE tag configuration is available, this patch still
      allows persisting potentially malicious data - which is not reflected
      in the backend user interface - but to be sanitized during frontend
      rendering (see below).
      
      Corresponding configuration directives (`removeTags`, `allowedAttribs`)
      are now considered again. Besides that a new, but simplified sequential
      HTML parser ensures that runaway node-boundaries are detected & denied.
      
      To sanitize and purge XSS from markup during frontend rendering, new
      custom HTML sanitizer has been introduced, based on `masterminds/html5`.
      Both `DefaultBuilder` and `CommonVisitor` provide common configuration
      which is in line with expected tags that are allowed in backend RTE.
      Using a custom builder instance, it is possible to adjust for individual
      demands - however, configuration possibilities cannot be modified using
      TypoScript - basically since the existing syntax does not cover all
      necessary scenarios.
      
      Resolves: #94375
      Related: #83027
      Related: #94484
      Releases: master, 11.3, 10.4, 9.5
      Change-Id: I5f8de43faab57b00052614ad37bd10ea9e384dc0
      Security-Bulletin: TYPO3-CORE-SA-2021-013
      Security-References: CVE-2021-32768
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70345
      
      
      Tested-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
      Reviewed-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
      3dca584c
  18. 30 Jul, 2021 1 commit
  19. 06 Jul, 2021 1 commit
  20. 11 Jun, 2021 1 commit
  21. 01 Jun, 2021 1 commit
  22. 31 May, 2021 1 commit
    • Oliver Bartsch's avatar
      [TASK] Change password reset functionality · 12737d31
      Oliver Bartsch authored and Richard Haeser's avatar Richard Haeser committed
      In case administrators don't want their users to
      initiate the reset password process, they have to
      set the global configuration option "passwordReset"
      to false.
      
      This however also prevents administrators from
      using the cli command or the action in the backend
      user module.
      
      Therefore, some things changed in the password
      reset implementation:
      
      - `passwordReset` now only affects the login screen
      - The CLI command is always enabled (requires shell
        access since the command is not schedulable)
      - Initiating password reset in the backend can be
        managed separately with a new user TSconfig option
      
      Also the descriptions of the global configuration
      options are adjusted. Actually `passwordResetForAdmins`
      previously mentioned that setting this to FALSE will
      only affect the login screen, which was not the case.
      It always affected all places.
      
      In the end, this enables administrators to be more
      precise when configuring the password reset functionality
      in their installations.
      
      Resolves: #91496
      Releases: master
      Change-Id: Ic74080adffbaf55f82189dffddb93fdd601034e2
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69268
      
      
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Jochen's avatarJochen <rothjochen@gmail.com>
      Tested-by: Richard Haeser's avatarRichard Haeser <richard@richardhaeser.com>
      Reviewed-by: Jochen's avatarJochen <rothjochen@gmail.com>
      Reviewed-by: Richard Haeser's avatarRichard Haeser <richard@richardhaeser.com>
      12737d31
  23. 06 May, 2021 1 commit
  24. 16 Apr, 2021 1 commit
  25. 16 Mar, 2021 1 commit
  26. 11 Mar, 2021 1 commit
  27. 10 Mar, 2021 1 commit
  28. 23 Feb, 2021 1 commit
  29. 19 Feb, 2021 1 commit
    • Oliver Bartsch's avatar
      [FEATURE] Introduce MFA in Core · 39145a46
      Oliver Bartsch authored and Benni Mack's avatar Benni Mack committed
      A new API is introduced, providing multi-factor
      authentication for the Core. The API is furthermore
      directly used to add two MFA providers by default:
      
      * TOTP (time-based one-time passwords)
      * Recovery codes
      
      Even if the API is designed to allow MFA in both,
      backend and frontend, it is currently only implemented
      into the backend. Users can therefore configure their
      available MFA providers in a new backend module,
      accessible via their user settings.
      
      There are also some configuration options for
      administrators to e.g. define a recommended provider
      or to disallow available providers for specific users
      or user groups.
      
      Administration of the users' MFA providers is possible
      for administrators in the corresponding user records.
      
      New providers can be introduced by implementing the
      MfaProviderInterface and tagging the service with the
      `mfa.provider` tag.
      
      Note that the API is currently marked as internal since
      changes in upcoming patches are to be expected.
      
      Following dependencies are introduced:
      
      * bacon/bacon-qr-code "^2.0"
      * christian-riesen/base32 "^1.5"
      
      Possible features that could follow later-on:
      
      * MFA frontend integration
      * Webauthn core provider for FIDO2 and U2F.
      * Forcing users to set up MFA on login
      * Password-recovery with active MFA
      
      Resolves: #93526
      Releases: master
      Change-Id: I4e902be624c80295c9c0c3286c90a6a680feeb5d
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67548
      
      
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      39145a46
  30. 26 Nov, 2020 2 commits
  31. 24 Nov, 2020 1 commit
  32. 10 Nov, 2020 1 commit
  33. 20 Oct, 2020 1 commit
    • Georg Ringer's avatar
      [FEATURE] Improved Email Validation · 7e95ee3a
      Georg Ringer authored and Daniel Goerz's avatar Daniel Goerz committed
      The method :php`\TYPO3\CMS\Core\Utility\GeneralUtility::validEmail`
      is used to validate a given email address through the core
      and TYPO3 extensions.
      
      The validation can now be configured by providing the used
      validators to be used in the LocalConfiguration.php or
      AdditionalConfiguration.php.
      
      Example:
      
         $GLOBALS['TYPO3_CONF_VARS']['MAIL']['validators'] = [
           \Egulias\EmailValidator\Validation\RFCValidation::class,
           \Egulias\EmailValidator\Validation\DNSCheckValidation::class'
         ];
      
      The RFCValidation validator is still be used as default.
      
      Furthermore, following validators are available:
      
      - Egulias\EmailValidator\Validation\DNSCheckValidation
      - Egulias\EmailValidator\Validation\SpoofCheckValidation
      - Egulias\EmailValidator\Validation\NoRFCWarningsValidation
      
      It is also possible to provide own validators which must implement
      the Egulias\EmailValidator\Validation\EmailValidation interface.
      
      If multiple validators are provided, each validator must return TRUE.
      
      Resolves: #92531
      Releases: master
      Change-Id: I9c5a0573c2f9bff56bf869dc221a2c0ffd75417b
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66179
      
      
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: default avatarJosef Glatz <josefglatz@gmail.com>
      Reviewed-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      7e95ee3a
  34. 23 Sep, 2020 1 commit
  35. 21 Sep, 2020 1 commit
  36. 11 Sep, 2020 1 commit
  37. 27 Jul, 2020 1 commit
  38. 04 Jun, 2020 1 commit