php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #75496 Session ID Collision happened few times
Submitted: 2017-11-07 11:13 UTC Modified: 2017-11-09 10:59 UTC
From: dmitry dot yeskin at gmail dot com Assigned: yohgaki (profile)
Status: Closed Package: Session related
PHP Version: 7.0.25 OS: Amazon OS
Private report: No CVE-ID: None
 [2017-11-07 11:13 UTC] dmitry dot yeskin at gmail dot com
Description:
------------
Hello!

We have an e-commerce website written with Yii2 framework.

We don't modify session ids ourself. We just use session_start();

So here is what happened: we have a good traffic like 12000 unique users in 3 hrs of mornings every day. And for last 2 weeks - we got a session id collision 2 times. I mean - 2 customers came to website exactly at the same second and got shared session id.

In result, they were able to see content of each other in their cart, until they started removing that content and even made a checkout, and then complained that ordered wrong item.

Here is data from nginx log:
--------
[ec2-user@scw ~]$ grep -r "73.111.163.135\|73.19.225.170" log.log 
73.111.163.135 - - [26/Oct/2017:18:43:52 -0600] "GET /postcard?r=26oct2017 HTTP/2.0" 200
73.19.225.170 - - [26/Oct/2017:18:43:52 -0600] "GET /postcard?r=26oct2017 HTTP/2.0" 200
73.111.163.135 - - [26/Oct/2017:18:47:09 -0600] "POST /postcard?r=26oct2017 HTTP/2.0" 30
73.111.163.135 - - [26/Oct/2017:18:47:09 -0600] "GET /postcard?r=26oct2017 HTTP/2.0" 200
73.111.163.135 - - [26/Oct/2017:18:47:12 -0600] "GET /cart HTTP/2.0" 200
73.111.163.135 - - [26/Oct/2017:18:47:42 -0600] "POST /cart HTTP/2.0" 200
73.111.163.135 - - [26/Oct/2017:18:48:48 -0600] "GET /cart/checkout/ HTTP/2.0" 200
73.19.225.170 - - [26/Oct/2017:18:50:39 -0600] "POST /postcard?r=26oct2017 HTTP/2.0" 302
73.19.225.170 - - [26/Oct/2017:18:50:39 -0600] "GET /postcard?r=26oct2017 HTTP/2.0" 200
73.19.225.170 - - [26/Oct/2017:18:50:46 -0600] "GET /cart HTTP/2.0" 200
73.19.225.170 - - [26/Oct/2017:18:51:00 -0600] "GET /cart/remove/1 HTTP/2.0" 302
73.19.225.170 - - [26/Oct/2017:18:51:00 -0600] "GET /cart HTTP/2.0" 200
73.111.163.135 - - [26/Oct/2017:18:51:09 -0600] "POST /cart/checkout/ HTTP/2.0" 302
73.111.163.135 - - [26/Oct/2017:18:51:09 -0600] "GET /cart/checkout/complete HTTP/2.0" 200
73.19.225.170 - - [26/Oct/2017:18:51:17 -0600] "GET /cart/checkout/ HTTP/2.0" 200
------------

You may see that both customers came to website at the same moment to postcard page (then they clicked add to cart and proceeded to cart, and then one of users saw wrong item there and called /cart/remove/1, then another user completed checkout, but he bought a wrong item and then complained to us).

For 2 weeks we got 2 similar cases.

After the first case we changed a hash entropy php settings in php.ini so session_id is now 48 chars but it didn't help to prevent second case.

We solved this issue by adding user_agent to session var on controller init:

            if (session_status() == PHP_SESSION_NONE) {
                session_start();
            }

            if (!isset($_SESSION['user_agent']) || empty($_SESSION['user_agent']) || $_SESSION['user_agent'] === Yii::$app->request->getUserAgent()) {
            } else {
                session_regenerate_id();
                unset($_SESSION['user_agent']);
                unset($_SESSION['cart']);
            }
            if (!isset($_SESSION['user_agent'])) {
                $_SESSION['user_agent'] = Yii::$app->request->getUserAgent();
            }

But still wondered why this happens? I read in github php source code that php must use IP address and random value for session_id generation so it must be unique and i also read that php has some mechanisms to prevent session_id collisions. But looks like it doesn't work correctly.

Again - everything great for thousands users. It only happened twice for last 2 weeks.

We dont modify session_id value ourself. We just use session_start and work with $_SESSION variables after that. What are we doing wrong?

Is it a bug?

We have PHP 7.0.21 working as php-fpm and nginx

PS. Doing PHP coding for 20 years, and see this for the first time.

Test script:
---------------
    /**
    * Process adding line-item to cart
    *
    * @return boolean the status of addition
    */
    public function addToCart() {

        if (session_status() == PHP_SESSION_NONE) {
            session_start();
        }

        if (!isset($_SESSION['cart'])) {
            //$_SESSION['cart'] = array('items' => array(), 'coupon' => array(), 'subtotal' => '', 'discount' => '', 'shipping' => '', 'total' => '');
            $_SESSION['cart'] = array('items' => array(), 'coupon' => array(), 'cost' => '', 'discount' => '', 'shipping' => '', 'total' => '');
        }

        $cost = ($this->price + 1 - 1); // Converting string to number

        if (is_array($this->addons) && count($this->addons)>0) {
            foreach ($this->addons as $addon) {
                if (isset($addon['price']) && is_numeric($addon['price']) && !empty($addon['price'] + 1 - 1)) $cost += $addon['price'];
            }
        }

        $shippingCost = 0;
        if ($this->type == 'package' || $this->type == 'postcard' || $this->type == 'book') {
            $data = $this->data;
            if (isset($data['shipping']) && !empty($data['shipping']) && isset($data[$data['shipping']]) && is_numeric($data[$data['shipping']]) && !empty($data[$data['shipping']] + 1 - 1)) $shippingCost = $data[$data['shipping']];
        }

        $_SESSION['cart']['items'][] = array(
            'id' => $this->id,
            'product_id' => $this->product_id,
            'sku' => $this->sku,
            'title' => $this->title,
            'type' => $this->type,
            'description' => $this->description,
            'price' => number_format((float)$this->price, 2, '.', ''),
            'picture' => $this->picture,
            'data' => $this->data,
            'address' => $this->address,
            'addons' => $this->addons,
            'cost' => number_format((float)$cost, 2, '.', ''),
            'shipping' => number_format((float)$shippingCost, 2, '.', ''),
            'subtotal' => number_format((float)($cost + $shippingCost), 2, '.', ''),
            'draft' => $this->draft,
        );

        $cost = 0;
        $shipping = 0;
        foreach ($_SESSION['cart']['items'] as $key => $item) {
            $cost += $item['cost'];
            $shipping += $item['shipping'];
        }

        $discount = (isset($_SESSION['cart']['discount']) && !empty($_SESSION['cart']['discount'])) ? $_SESSION['cart']['discount'] : 0;

        $_SESSION['cart']['cost'] = number_format((float)$cost, 2, '.', '');
        $_SESSION['cart']['shipping'] = number_format((float)$shipping, 2, '.', '');
        $_SESSION['cart']['total'] = number_format((float)($cost + $shipping - $discount), 2, '.', '');

        return true;

    }


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-11-08 02:23 UTC] yohgaki@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: yohgaki
 [2017-11-08 02:23 UTC] yohgaki@php.net
Could you get session related INI settings by phpinfo() on the server? 
Thank you.

Anyway, it would be some kind of attack most likely. As you may knew already, unremovable cookies are created easily by JS, etc. If you don't have session_regenerate_id() before user authentication flag is set, you(your users) might have been attacked. 

I strongly suggest to enable session ID collision detection feature (session.use_strict_mode=1) which is disabled by default. Beware that it has some overheads which I would like to eliminate someday. Your code should be prepared for session_start() failure by ID collision.
 [2017-11-08 09:20 UTC] dmitry dot yeskin at gmail dot com
-Status: Feedback +Status: Assigned
 [2017-11-08 09:20 UTC] dmitry dot yeskin at gmail dot com
Thanks for your response.

It was not an attack. It was 2 old ladies who both bought Christmas postcards for children. Both successfully paid. And both complained that wrong data in their orders.

These 2 customers were even anonymous customers - they made orders without any login. Website is simple - you come to postcard page - click "Add to cart", and information about postcard added to user $_SESSION. Then in cart and checkout - they just pay for it and data about order saved to database. Nothing too fancy. I attached code for addToCart method as example.

Regarding your question of php.ini settings, here it is:
---
session.auto_start	Off
session.cache_expire	180
session.cache_limiter	nocache
session.cookie_domain	no value
session.cookie_httponly	On
session.cookie_lifetime	0
session.cookie_path	/
session.cookie_secure	On
session.entropy_file	/dev/urandom
session.entropy_length	32
session.gc_divisor	1000
session.gc_maxlifetime	1440
session.gc_probability	1
session.hash_bits_per_character	6
session.hash_function	sha256
session.lazy_write	On
session.name	PHPSESSID
session.referer_check	no value
session.save_handler	files
session.save_path	/var/lib/php/7.0/session
session.serialize_handler	php
session.upload_progress.cleanup	On
session.upload_progress.enabled	On
session.upload_progress.freq	1%
session.upload_progress.min_freq	1
session.upload_progress.name	PHP_SESSION_UPLOAD_PROGRESS
session.upload_progress.prefix	upload_progress_
session.use_cookies	On
session.use_only_cookies	On
session.use_strict_mode	Off
session.use_trans_sid	0
---

We really don't have session.use_strict_mode on. But do you think it could be a reason? I thought that PHP must check for session collisions even without it? I mean, purpose of strict mode is to protect site from starting uninitialized sessions. I think thats not a case. Thats more against hackers and hijackings, not about session collisions. Am I wrong? Do you really think it will solve the problem if I enable it?
 [2017-11-08 13:18 UTC] 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.
 [2017-11-08 14:05 UTC] 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 17:33 UTC] 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 18:58 UTC] 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 21:44 UTC] 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-09 10:59 UTC] dmitry dot yeskin at gmail dot com
-Status: Assigned +Status: Closed
 [2017-11-09 10:59 UTC] dmitry dot yeskin at gmail dot com
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.
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Tue Mar 31 20:01:24 2020 UTC