Skip to content
Snippets Groups Projects
  1. Feb 07, 2023
    • Benjamin Franzke's avatar
      [SECURITY] Prevent XSS due to wrong PATH_INFO evaluation · b8094083
      Benjamin Franzke authored
      As already started in #88304 (but only for NormalizedParams)
      and later reverted in #89312 (because of cgi-bin problems),
      PATH_INFO is no longer considered as a preferable SCRIPT_NAME
      alternative. All known server configurations set SCRIPT_NAME
      these days to a proper value when cgi.fix_pathinfo is set.
      
      The fallback to PATH_INFO has been introduced with
      the initial revision of TYPO3 and isn't needed at all nowadays,
      it's actually wrong, as a REQUEST_URI like /index.php/foo/bar
      would incorrectly be interpreted as $scriptName == "/foo/bar",
      which let's all calculations on $scriptName fail and
      even leads to XSS where values derived from $scriptName are
      printed without being escaped.
      
      Also any ORIG_SCRIPT_NAME evaluation is dropped, as this variable
      contains the SCRIPT_NAME that was set by the webserver configuration
      before PHP applied cgi.fix_pathinfo. Using ORIG_SCRIPT_NAME
      effectively meant bypassing PHP's pathinfo fix. It usually contains
      the cgi-wrapper paths, which is why PATH_INFO was used to overrule
      wrong ORIG_SCRIPT_NAME values.
      
      GeneralUtility::getIndpEnv('PATH_INFO') is adapted to trust the
      servers PATH_INFO information, now that we no longer allow
      servers to send SCRIPT_NAME as PATH_INFO (we enforce
      cgi.fix_pathinfo=1 for CGI installations).
      
      The normalized SCRIPT_NAME is now adapted to be encoded as a URL
      path by default, as all TYPO3 usages expect this to be an URL path.
      Note that $_SERVER['SCRIPT_NAME'] refers to the servers file
      system path, not the URL encoded value.
      
      This SCRIPT_NAME sanitization actually enables:
      
      a) TYPO3 to be run in a subfolder that contains characters
      that need URL encoding
      e.g. `/test:site/` – url encoded that'd be `/test3Asite/`.
      
      b) prevention of XSS in case third party extensions
      missed to escape any URL that is derived from SCRIPT_NAME
      (while making sure that properly escaped
      output is not double escaped)
      
      Resolves: #99651
      Related: #88304
      Related: #89312
      Releases: main, 11.5, 10.4
      Change-Id: Ief95253d764665db5182a15ce8ffd02ea02ee61e
      Security-Bulletin: TYPO3-CORE-SA-2023-001
      Security-References: CVE-2023-24814
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/77738
      
      
      Reviewed-by: default avatarOliver Hader <oliver.hader@typo3.org>
      Tested-by: default avatarOliver Hader <oliver.hader@typo3.org>
      b8094083
    • Benjamin Franzke's avatar
      [TASK] Improve comments and readability in PageArgumentValidator · c008616d
      Benjamin Franzke authored
      Make clear that the early-bail out for empty pageArguments is
      done to prevent setting `disableCaches` to `true`.
      
      Also makes that that the $pageNotFoundOnCacheHashError
      condition is really tied to pageArguments being non-empty.
      Prevents us from refactoring that code and missing this bit.
      
      Resolves: #99860
      Related: #99859
      Releases: main, 11.5, 10.4
      Change-Id: I98ffa3dffe76a37970784979a2c4f2a9a64aa5bf
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/77752
      
      
      Tested-by: default avatarStefan Bürk <stefan@buerk.tech>
      Tested-by: default avatarNikita Hovratov <nikita.h@live.de>
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Reviewed-by: default avatarBenjamin Franzke <bfr@qbus.de>
      Reviewed-by: default avatarStefan Bürk <stefan@buerk.tech>
      Reviewed-by: default avatarNikita Hovratov <nikita.h@live.de>
      Tested-by: default avatarBenjamin Franzke <bfr@qbus.de>
      c008616d
    • Oliver Hader's avatar
      [BUGFIX] Avoid disabling page caches when having cHash validation enforced · adaa7dc0
      Oliver Hader authored
      If $GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']['enforceValidation']
      is enabled and the HTTP request only contains the `?id` query parameter,
      caching for the page is disabled - which should be avoided.
      
      Resolves: #99859
      Releases: main, 11.5, 10.4
      Change-Id: I14a81f5a2ec3ecabedd1abf0756a3ee32e7af4e4
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/77734
      
      
      Tested-by: default avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: default avatarStefan Bürk <stefan@buerk.tech>
      Reviewed-by: default avatarOliver Bartsch <bo@cedev.de>
      Tested-by: default avatarStefan Bürk <stefan@buerk.tech>
      Tested-by: default avatarcore-ci <typo3@b13.com>
      adaa7dc0
  2. Feb 06, 2023
    • Benni Mack's avatar
      [BUGFIX] Enforce validation when no cHash is given · 840f8af3
      Benni Mack authored
      When no cHash is given but GET parameters are handed in
      which _would_ require cHash parameters, these are now
      properly evaluated during the frontend request.
      
      As this has a security impact,
      a new option called
      $GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']['enforceValidation']
      is introduced, which then skips
      the "requireCacheHashPresenceParameters" option.
      The latter is an include list, but cache Hash
      calculation should rather be based on
      the exclude list such as "excludedParameters" and
      "cachedParametersWhiteList".
      
      If the new option is set, but some properties such
      as tx_solr[q] should be allowed, then this needs
      to be added to the excludedList ("excludedParameters")
      by extension authors.
      
      A new test "SlugSiteWithoutRequiredCHashRequestTest"
      is added which works with a disabled feature
      flag compared to "SlugSiteRequestTest" which
      has the feature flag enabled.
      
      Resolves: #95297
      Releases: main, 11.5, 10.4
      Change-Id: Ib72c6a34602e77d8c2044ad2e826c0474ebd2326
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/77712
      
      
      Tested-by: default avatarOliver Hader <oliver.hader@typo3.org>
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Reviewed-by: default avatarOliver Hader <oliver.hader@typo3.org>
      840f8af3
  3. Feb 04, 2023
  4. Feb 03, 2023
  5. Feb 02, 2023
  6. Feb 01, 2023
  7. Jan 31, 2023
  8. Jan 30, 2023
  9. Jan 27, 2023
  10. Jan 26, 2023
  11. Jan 25, 2023
  12. Jan 24, 2023
  13. Jan 23, 2023
  14. Jan 22, 2023
  15. Jan 20, 2023
  16. Jan 19, 2023
  17. Jan 18, 2023
  18. Jan 17, 2023