Bug #75496 [Asn->Csd]: Session ID Collision happened few times
| From: | dmitry dot yeskin at gmail dot com | Date: | Thu, 09 Nov 2017 11:00:03 +0000 |
| Subject: | Bug #75496 [Asn->Csd]: Session ID Collision happened few times | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-212528@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=75496&edit=1
ID: 75496
User updated by: dmitry dot yeskin at gmail dot com
Reported by: dmitry dot yeskin at gmail dot com
Summary: Session ID Collision happened few times
-Status: Assigned
+Status: Closed
Type: Bug
Package: Session related
Operating System: Amazon OS
PHP Version: 7.0.25
Assigned To: yohgaki
Block user comment: N
Private report: N
New Comment:
Okay guys that was a reason.
FastCGI micro caching at nginx that cached 200 responses together with session cookies.
Of course maybe it was set wrong at our server, but its definitely has nothing to do with PHP.
So this bug case can be closed and this is not a PHP bug.
Thanks.
Previous Comments:
------------------------------------------------------------------------
[2017-11-08 21:44:27] dmitry dot yeskin at gmail dot com
I found a possible reason for this.
We have nginx and there is fastcgi microcache is turned on. So I think that is a reason. So I
disabled all fastcgi caching and now looking if i get any collisions.
Will update you tomorrow with results but I think its a reason 99%
Thanks.
------------------------------------------------------------------------
[2017-11-08 18:58:27] dmitry dot yeskin at gmail dot com
In my controller in init() method I added this code for tracking:
if (session_status() == PHP_SESSION_NONE) {
session_start();
}
if (isset($_SESSION['user_agent']) && !empty($_SESSION['user_agent'])
&& $_SESSION['user_agent'] != Yii::$app->request->getUserAgent()) {
$data = 'Session ID: ' . session_id() . "\n" . 'User Agent: ' .
Yii::$app->request->getUserAgent() . "\n" . 'IP: ' .
Yii::$app->request->getUserIP() . "\n" . 'SESSION: ' . print_r($_SESSION,
true);
@mail('[MY EMAIL HERE]', 'Session ID Collision', $data);
session_regenerate_id();
session_destroy();
session_start();
session_regenerate_id();
unset($_SESSION['user_agent']);
$_SESSION['cart'] = array();
unset($_SESSION['cart']);
}
if (!isset($_SESSION['user_agent'])) {
$_SESSION['user_agent'] = Yii::$app->request->getUserAgent();
$_SESSION['ip_address'] = Yii::$app->request->getUserIP();
}
So it works like: if you dont have user_agent in your session - it adds it there. And if you have
session started but your user_agent is not like one saved in your session (that is what happens when
session shared), it send me email with data about "new session owner" and content of
session from previous owner (his user_agent and IP) and trying to regenerate session (yes, I do it
now 2 times + session_destroy in the middle to more guarantee).
So I got today already 5 notifications about session collisions.
Here is just example from one of emails:
-------
Session ID: Y4gXw2l8fZZRHVgu0KoLamr5ywVyw5UauP0BOKdjpg0
User Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 11_0_3 like Mac OS X) AppleWebKit/604.1.38 (KHTML,
like Gecko) Mobile/15A432
[FBAN/FBIOS;FBAV/147.0.0.46.81;FBBV/76961488;FBDV/iPhone9,2;FBMD/iPhone;FBSN/iOS;FBSV/11.0.3;FBSS/3;FBCR/Verizon;FBID/phone;FBLC/en_US;FBOP/5;FBRV/0]
IP: 174.200.9.242
SESSION: Array
(
[user_agent] => Mozilla/5.0 (Linux; Android 7.0; SM-N920T Build/NRD90M; wv) AppleWebKit/537.36
(KHTML, like Gecko) Version/4.0 Chrome/62.0.3202.84 Mobile Safari/537.36
[FB_IAB/FB4A;FBAV/148.0.0.51.62;]
[ip_address] => 172.58.110.205
[__flash] => Array
(
)
)
------
So as described above in code, new customer with IP 174.200.9.242 assigned already existing session
ID Y4gXw2l8fZZRHVgu0KoLamr5ywVyw5UauP0BOKdjpg0 which is owned and initiated by customer with IP
172.58.110.205.
This can be confirmed with server nginx logs.
That already happened 5 times today. I didn't track for collisions before and just had
complaints from customers, but I believe that in the past days we had a much more collisions than we
think. Right now, I can track every single collision but not sure what to do with this and what is
the reason of it.
Maybe some RAM memory overload? Maybe CPU overload? Maybe because PHP is working as php-fpm? What
can I do more to help identify this issue?
------------------------------------------------------------------------
[2017-11-08 17:33:11] dmitry dot yeskin at gmail dot com
Thanks for comment nikic!
It was a good idea but unfortunately looks like thats not a case.
I tried this code to verify it:
$fp = fopen('/dev/urandom','rb');
if ($fp !== FALSE) {
$result = fread($fp, 100);
fclose($fp);
print $result;
} else {
die('Can not open /dev/urandom.');
}
And I got random string in result.
But few minutes ago I got one more collision! So 2 collisions only today!!! Yes traffic is not small
- already 430 successful orders this morning. Only 2 collisions. But anyway - thats not normal!
And I have all day today session.use_strict_mode enabled after Yasuo Ohgaki comment!
Please help.
------------------------------------------------------------------------
[2017-11-08 14:05:20] nikic@php.net
Even without an explicit check, random session ID collisions are vanishingly unlikely. Looking at
how the session ID generation worked in PHP 7.0 and your configuration, my best guess would be that
/dev/urandom is not readable from PHP. In PHP 7.0 this error case is unfortunately silently ignored,
while PHP 7.1 will trigger an error. Can you verify that /dev/urandom is readable from PHP?
------------------------------------------------------------------------
[2017-11-08 13:18:12] dmitry dot yeskin at gmail dot com
I updated session.use_strict_mode to 1 this mornjng but a fee minutes ago another collision happened
again. So strict mode doesnt help.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=75496
--
Edit this bug report at https://bugs.php.net/bug.php?id=75496&edit=1