Bug #42601

Content Security: QOM rewriting is omitted if used in certain cases in an Action Controller

Added by Robert Lemke almost 7 years ago. Updated about 6 years ago.

Status:
Under Review
Priority:
Must have
Assignee:
Category:
Security
Start date:
2012-11-01
Due date:
% Done:

100%

PHP Version:
5.4
Has patch:
No
Complexity:
medium

Description

The QOM Query Rewriting Aspect checks if the security context is initialized. If it is not yet initialized, it will suspend query rewriting and just proceed to call the execute() or count() method.

This may be a problem because it is not defined when the security context is initialized. It can does happen that if no getRole() etc. methods have been called previously (no user is logged in), content is shown which must not be visible.

This issue is, however, quite predictable and becomes apparent during development already.


Related issues

Related to TYPO3.Flow - Bug #42758: Unit test for PersistenceQueryRewritingAspect broken Resolved 2012-11-07
Related to TYPO3.Flow - Bug #44765: Functional test broken Resolved 2013-01-23

Associated revisions

Revision 9af3204b (diff)
Added by Robert Lemke almost 7 years ago

[BUGFIX] Enforce Query Rewriting more reliably

This initializes the security context if it hasn't been initialized
when the PersistenceQueryRewritingAspect becomes active.

Previously it could happen that entities which should be covered by
a policy are visible to anonymous users.

Change-Id: I44838de1503cbe49cf3fee51921b731bfaa0cfc5
Resolves: #42601
Releases: 1.1, 1.2

Revision ce08c301 (diff)
Added by Sebastian Kurfuerst over 6 years ago

[BUGFIX] The security context is only allowed to be initialized after routing took place

This bugfix solves the root-cause for the following two symptoms:

  • two logins needed in Neos until the Site is shown
  • if the Flow_Mvc_Routing_FindMatchResults cache is deactivated completely,
    the login does not work at all.

The problem is as follows:

  • The security context needs the current request for working properly;
    such that it can separate the active and inactive tokens correctly in
    \TYPO3\Flow\Security\Context::separateActiveAndInactiveTokens()
  • The current request is built during routing. Thus, the routing mechanism
    (f.e. RoutePart handlers) is not allowed to access the Security Context
    in any way. If it does (like in this example), things might break in various
    ways.
  • For Neos, the following call chain takes place:
    • Routing
    • FrontendNodeRoutePartHandler->matchValue line 51
    • NodeService->getNodeByContextNodePath() line 57
    • new ContentContext() calls "initializeObject"
    • ContentContext->initializeObject does $this->domainRepository->findByHost()
    • this internally uses Repository->findAll()
    • this executes the TYPO3\Flow\Security\Aspect\PersistenceQueryRewritingAspect->rewriteQomQuery
    • because Neos has policy entries for entities (TYPO3\TYPO3CR\Domain\Model\Node),
      $this->securityContext->initialize() is called, WITHOUT HAVING A
      REQUEST SET BEFORE.
    • This results in a half- and wrongly-initialized Security Context
      set up, with activeTokens not properly set, and also only the
      standard roles assigned ("Everybody").
    • Thus, the check in TYPO3\Neos\Controller\Frontend\NodeController->showAction() fails:
      $this->accessDecisionManager->decideOnResource('TYPO3_Neos_Backend_BackendController');
    • This redirects the user back to the login ($this->redirect('index', 'Login'))
    • Now, if the routing cache is activated, the aspect kicks in (in
      the second iteration) and directly returns the match result, without
      triggering a database query before.

Thus, we need to enforce that the security context is not initialized during
the routing phase.

The attached patch is just a quick fix; with not really the clean solution.
But at least it works and the problem is properly described ;-)

This is a follow-up to issue #42601; where the according code has been
implemented.

Change-Id: I724c1b352dd1807ba53b1e336f2d90e90360ff4d
Releases: master, 2.0

Revision 9a3433d9 (diff)
Added by Karsten Dambekalns over 6 years ago

[BUGFIX] Fix security-related unit test failures

The change I724c1b352dd1807ba53b1e336f2d90e90360ff4d introduced some
test failures. This change takes care of the failing unit tests.

Change-Id: Idff32284a4e8c4e935b7d7c132da769f5dd47140
Related: #42601
Releases: master

Revision 55a312f2 (diff)
Added by Karsten Dambekalns over 6 years ago

[BUGFIX] Fix security-related functional test failures

The change I724c1b352dd1807ba53b1e336f2d90e90360ff4d introduced some
test failures. This change takes care of the failing functional tests.

It does that by:

  • changing the order in which security is set up in the
    FunctionalTestCase provided by Flow.
  • setting the "current request" again after a call to clearContext() in
    ContentSecurityTest
  • adjusting the expected exception in MethodSecurityTest in two places

Change-Id: I353e2cba11473cf9ddef82f96b6a79d9d6fefbba
Fixes: #44765
Related: #42601
Releases: master

Revision 56c6d852 (diff)
Added by Karsten Dambekalns over 6 years ago

[BUGFIX] Fix security-related functional test failures, part 2

The change I724c1b352dd1807ba53b1e336f2d90e90360ff4d introduced some
test failures. This change takes care of the failing functional tests.

It does that by:

  • setting the "current request" again after a call to clearContext() in
    ContentSecurityTest
  • adjusting the expected exception in MethodSecurityTest in two places

This is a followup to I353e2cba11473cf9ddef82f96b6a79d9d6fefbba which
was broken after having fixed those already.

Change-Id: I09182972baf668abbb2cf583e8deebdc31e90205
Related: #42601
Fixes: #44765
Releases: master

Revision ff2a4117 (diff)
Added by Sebastian Kurfuerst over 6 years ago

[BUGFIX] The security context is only allowed to be initialized after routing took place

This bugfix solves the root-cause for the following two symptoms:

  • two logins needed in Neos until the Site is shown
  • if the Flow_Mvc_Routing_FindMatchResults cache is deactivated completely,
    the login does not work at all.

The problem is as follows:

  • The security context needs the current request for working properly;
    such that it can separate the active and inactive tokens correctly in
    \TYPO3\Flow\Security\Context::separateActiveAndInactiveTokens()
  • The current request is built during routing. Thus, the routing mechanism
    (f.e. RoutePart handlers) is not allowed to access the Security Context
    in any way. If it does (like in this example), things might break in various
    ways.
  • For Neos, the following call chain takes place:
    • Routing
    • FrontendNodeRoutePartHandler->matchValue line 51
    • NodeService->getNodeByContextNodePath() line 57
    • new ContentContext() calls "initializeObject"
    • ContentContext->initializeObject does $this->domainRepository->findByHost()
    • this internally uses Repository->findAll()
    • this executes the TYPO3\Flow\Security\Aspect\PersistenceQueryRewritingAspect->rewriteQomQuery
    • because Neos has policy entries for entities (TYPO3\TYPO3CR\Domain\Model\Node),
      $this->securityContext->initialize() is called, WITHOUT HAVING A
      REQUEST SET BEFORE.
    • This results in a half- and wrongly-initialized Security Context
      set up, with activeTokens not properly set, and also only the
      standard roles assigned ("Everybody").
    • Thus, the check in TYPO3\Neos\Controller\Frontend\NodeController->showAction() fails:
      $this->accessDecisionManager->decideOnResource('TYPO3_Neos_Backend_BackendController');
    • This redirects the user back to the login ($this->redirect('index', 'Login'))
    • Now, if the routing cache is activated, the aspect kicks in (in
      the second iteration) and directly returns the match result, without
      triggering a database query before.

Thus, we need to enforce that the security context is not initialized during
the routing phase.

The attached patch is just a quick fix; with not really the clean solution.
But at least it works and the problem is properly described ;-)

This is a follow-up to issue #42601; where the according code has been
implemented.

Change-Id: I724c1b352dd1807ba53b1e336f2d90e90360ff4d
Releases: master, 2.0

Revision 26a56543 (diff)
Added by Karsten Dambekalns over 6 years ago

[BUGFIX] Fix security-related functional test failures

The change I724c1b352dd1807ba53b1e336f2d90e90360ff4d introduced some
test failures. This change takes care of the failing functional tests.

It does that by:

  • changing the order in which security is set up in the
    FunctionalTestCase provided by Flow.
  • setting the "current request" again after a call to clearContext() in
    ContentSecurityTest
  • adjusting the expected exception in MethodSecurityTest in two places

Change-Id: I353e2cba11473cf9ddef82f96b6a79d9d6fefbba
Fixes: #44765
Related: #42601
Releases: master, 2.0

Revision 5612a561 (diff)
Added by Karsten Dambekalns over 6 years ago

[BUGFIX] Fix security-related functional test failures, part 2

The change I724c1b352dd1807ba53b1e336f2d90e90360ff4d introduced some
test failures. This change takes care of the failing functional tests.

It does that by:

  • setting the "current request" again after a call to clearContext() in
    ContentSecurityTest
  • adjusting the expected exception in MethodSecurityTest in two places

This is a followup to I353e2cba11473cf9ddef82f96b6a79d9d6fefbba which
was broken after having fixed those already.

Change-Id: I09182972baf668abbb2cf583e8deebdc31e90205
Related: #42601
Fixes: #44765
Releases: master, 2.0

Revision 18fa6d16 (diff)
Added by Karsten Dambekalns over 6 years ago

[BUGFIX] Fix security-related unit test failures

The change I724c1b352dd1807ba53b1e336f2d90e90360ff4d introduced some
test failures. This change takes care of the failing unit tests.

Change-Id: Idff32284a4e8c4e935b7d7c132da769f5dd47140
Related: #42601
Releases: master, 2.0

History

#1 Updated by Gerrit Code Review almost 7 years ago

  • Status changed from Accepted to Under Review

Patch set 1 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/16106

#2 Updated by Robert Lemke almost 7 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100

#3 Updated by Gerrit Code Review almost 7 years ago

  • Status changed from Resolved to Under Review

Patch set 1 for branch FLOW3-1.1 has been pushed to the review server.
It is available at https://review.typo3.org/17084

#4 Updated by Karsten Dambekalns almost 7 years ago

  • Target version changed from 2.0 beta 1 to 2.0

#6 Updated by Robert Lemke over 6 years ago

  • Status changed from Under Review to Resolved

#7 Updated by Gerrit Code Review over 6 years ago

  • Status changed from Resolved to Under Review

Patch set 2 for branch FLOW3-1.1 has been pushed to the review server.
It is available at https://review.typo3.org/17084

#8 Updated by Karsten Dambekalns about 6 years ago

  • Target version changed from 2.0 to 2.0.1

Also available in: Atom PDF