Possible race condition with session results in frequently being kicked out of the CMS

[kartikpatel95]

With the upgrade of hybrid session module to 2.5.1 and above I am been kicked out of the CMS as it asks to re-authenticate the user but I am not actually logged out as it re-finds my session a moment later and logs me back in but redirects me out of the admin. This happens consistently, making me downgrade back to 2.4 where the issue is not there.

Can this be looked at why it is happening.

Acceptance criteria

• Sessions are not invalidated needlessly
• Users can reauthenticate into the CMS once their session expires
• We don't reintroduce CVE-2022-24444 in the process of fixing this

[GuySartorelli]

I am been kicked out of the CMS

How long does it take before you are "kicked out"? And when you say "kicked out", do you mean it is automatically taking you to /Security/login, or is it providing an authentication form within the CMS itself?

it re-finds my session a moment later and logs me back in

Can you please describe that behaviour more clearly? What do you mean by it re-finding your session? How do you know it re-finds it? Do you need to interact with the CMS in some way, or does something happen automatically? What does happen?

redirects me out of the admin

Where does it redirect you to? Does that happen immediately when it "re-finds your session"? Or does something happen in between?

making me downgrade back to 2.4 where the issue is not there

Does this mean the issue is actually present in 2.5.0 as well?

[gligorkot]

@GuySartorelli this looks like it's some sort of race condition, after looking into it these are my findings:

Relevant code within Silverstripe framework:

• Within RequestAuthenticationHandler.php

  public function authenticateRequest(HTTPRequest $request)
  {
      /** @var AuthenticationHandler $handler */
      foreach ($this->getHandlers() as $name => $handler) {
          // in order to add cookies, etc
          $member = $handler->authenticateRequest($request);
          if ($member) {
              Security::setCurrentUser($member);
              return;
          }
      }
  }

• Within SessionAuthenticationHandler.php

  /**
   * @param HTTPRequest $request
   * @return Member
   */
  public function authenticateRequest(HTTPRequest $request)
  {
      $session = $request->getSession();
  
      // Sessions are only started when a session cookie is detected
      if (!$session->isStarted()) {
          return null;
      }
  
      // If ID is a bad ID it will be treated as if the user is not logged in, rather than throwing a
      // ValidationException
      $id = $session->get($this->getSessionVariable());
      if (!$id) {
          return null;
      }
      /** @var Member $member */
      $member = Member::get()->byID($id);
      return $member;
  }

So what we're seeing is, when we go to the CMS admin, we see our authenticator call RequestAuthenticationHandler's authenticateRequest function and generally when looping through the handlers, the session handler gets invoked and the member gets returned correctly. What we find though, after upgrading hybrid sessions to 2.5.1, sometimes the SessionAuthenticationHandler's authenticateRequest function ends up not finding an $id for the member, so it returns null. This then subsequently shows the re-authenticate within the CMS, but soon after finds the user (somehow) and you end up on the "Log in as a different user" screen.

Only thing I can think of is the new session encryption introduced here maybe takes a bit longer to process resulting in a race condition.

[GuySartorelli]

@gligorkot Thank you for looking into this. Can you please give me an idea of how frequently this happens? It will help both reproducing the issue and prioritising working on it.

[gligorkot]

@GuySartorelli it pretty much happens within minutes of us going into the admin section - doesn't happen on the public pages and browsing the site seems all ok, it only happens in the admin section, but happens often and reproducible all the time

[kartikpatel95]

@GuySartorelli I was wondering if you guys had any luck with this defect.

[GuySartorelli]

@kartikpatel95 We have been focused on getting everything ready for the CMS 5 beta release - we'd definitely welcome a community contribution but otherwise this will need to wait until we have resource available.

[GuySartorelli]

@kartikpatel95 @gligorkot I've been unable to reproduce this issue - can you both please provide as much information as you can about your setups and how to reproduce this?

Including:

• PHP version
• Can you reproduce this locally or only in production?
  • If only in production, how is it hosted? Please provide as much detail as you can.
• Can you reproduce this with a fresh installation of silverstripe/installer after adding only hybridsessions?
  • If not, what other setup is required to reproduce this issue?
• exactly what do you do to reproduce this? Please provide a list of steps I can take, including waiting times if you need to wait at any point (e.g. for an expiry time to elapse)
• What db driver are you using (mysql? mariadb? postgres? etc)
• What version of the db driver are you using?
• Is this 100% reliably happening every time you access the CMS? If not, please provide as much detail you can about any patterns you've seen for when it does occur
• Literally anything else you can think of to tell me that might help me reproduce this

[maxime-rainville]

I'll close this since we can't reproduce it. We can look at reopening if we get more context.