Bug #37780

Possibility to get duplicate sessionId for different user

Added by Sven Weiss about 7 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
-
Target version:
-
Start date:
2012-06-06
Due date:
% Done:

0%

TYPO3 Version:
4.5
PHP Version:
5.3
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

It is possible to get the same sessionId for different users. It actually happened on a high-traffic-site and I could reproduce it on a local test-system with some tweaks in the Core. I analyzed the Core and found out that the "new created sessionId" with createSessionId() is never been checked again the session table/s to found out if it is used for an other user/session. If you get one sessionId which is already defined for an other user/session then your browser keeps it because the session exists and then you have X users with one sessionId.

Now I created a modified version of createSessionId() in t3lib/class.t3lib_userauth.php to check every generated sessionId against the session table/s:
public function createSessionId() {
$createNewSessionId = true;
while($createNewSessionId) {
$sessionId = t3lib_div::getRandomHexString($this->hash_length);
$createNewSessionId = $this->isExistingSessionRecord($sessionId);
}
return $sessionId;
}

It is not the best solution but it works for a hot-fix.
I also found some very old bug tickets which are closed or resolved which are also talking about sessionId problems.

I can really say that it happens! (last time yesterday on a live system, bad!)


Related issues

Related to TYPO3 Core - Feature #73050: Add a CSPRNG to TYPO3 Closed 2016-01-31

History

#1 Updated by Sven Weiss about 7 years ago

From 6. June 04:00 PM to 11. June 02:00 AM it happened 18 times, but with the changed function it did not. I logged this issue with simple log files.

Sven Weiss wrote:

It is possible to get the same sessionId for different users. It actually happened on a high-traffic-site and I could reproduce it on a local test-system with some tweaks in the Core. I analyzed the Core and found out that the "new created sessionId" with createSessionId() is never been checked again the session table/s to found out if it is used for an other user/session. If you get one sessionId which is already defined for an other user/session then your browser keeps it because the session exists and then you have X users with one sessionId.

Now I created a modified version of createSessionId() in t3lib/class.t3lib_userauth.php to check every generated sessionId against the session table/s:
public function createSessionId() {
$createNewSessionId = true;
while($createNewSessionId) {
$sessionId = t3lib_div::getRandomHexString($this->hash_length);
$createNewSessionId = $this->isExistingSessionRecord($sessionId);
}
return $sessionId;
}

It is not the best solution but it works for a hot-fix.
I also found some very old bug tickets which are closed or resolved which are also talking about sessionId problems.

I can really say that it happens! (last time yesterday on a live system, bad!)

#2 Updated by Steffen Ritter about 7 years ago

Sven Weiss wrote:

It is not the best solution but it works for a hot-fix.

It will be the only solution, but we at least we need to optimize the database queries for that, as a normal non-login session

I also found some very old bug tickets which are closed or resolved which are also talking about sessionId problems.

I can really say that it happens! (last time yesterday on a live system, bad!)

As this would trigger two database calls for each login, I opt for not using this one...
It does not matter, if the session id is duplicate for non logged in users.
Therefore if would only check if the session Id is duplicate on login - and reset it in case of duplication.

Doing so we save a lot of database queries.

#3 Updated by Sven Weiss about 7 years ago

Steffen Ritter wrote:

Sven Weiss wrote:

It is not the best solution but it works for a hot-fix.

It will be the only solution, but we at least we need to optimize the database queries for that, as a normal non-login session

I also found some very old bug tickets which are closed or resolved which are also talking about sessionId problems.

I can really say that it happens! (last time yesterday on a live system, bad!)

As this would trigger two database calls for each login, I opt for not using this one...
It does not matter, if the session id is duplicate for non logged in users.
Therefore if would only check if the session Id is duplicate on login - and reset it in case of duplication.

Doing so we save a lot of database queries.

The sessionId is only saved in database if it is in use (saved some data to it). And then it is very critical if an other (not logged in) user get the same sessionId because then he will use it and can access the same sessionData like the other user. And his client holds the sessionId if it exists.
Security first, then performance. Doing two database calls is the only solution at the moment.

#4 Updated by Sven Weiss about 7 years ago

Sven Weiss wrote:

The sessionId is only saved in database if it is in use (saved some data to it). And then it is very critical if an other (not logged in) user get the same sessionId because then he will use it and can access the same sessionData like the other user. And his client holds the sessionId if it exists.
Security first, then performance. Doing two database calls is the only solution at the moment.

Perhaps there is one information missing: I am not talking about users with login. I am using sessions for anonymous users / "users without login".

#5 Updated by Sven Weiss almost 7 years ago

Tracked this issue in my Logs. Happened very often in the last weeks.
July 2012: 218
August 2012: 131

TYPO3 wanted to give the "in use sessionId" to some other (anonymous) user as often as mentioned.

#6 Updated by Mathias Schreiber over 4 years ago

  • Is Regression set to No

Hey Sven,

is this still the case?

#7 Updated by Helmut Hummel over 3 years ago

  • Status changed from New to Needs Feedback

@Sven: what is your OS? If there is a high probability that two similar session ids are created, then there is something wrong with our random number generator

#8 Updated by Riccardo De Contardi over 3 years ago

  • Status changed from Needs Feedback to Closed

No feedback within 90 days => Closing this issue.

If you think this is the wrong decision or experience the issue again, then let us know (on Slack for example - https://typo3.slack.com/ ) or open a new ticket and add a relation to this ticket number. Thank you

Also available in: Atom PDF