3

Update: Looks like the issue that started a few days ago was due to incorrect handling of the cookie "secure" flag. We still haven't resolved the problem that started on February 1 though.

I run an internal PHP/Apache site where I work. On February 1 we started getting reports that employees were being logged out of it randomly several times a day. We had not changed any of the authentication code in years, but we noticed that Chrome received a significant update that day: https://chromereleases.googleblog.com/2017/02/stable-channel-update-for-desktop.html.

In the last few days, the issue has gotten significantly worse and Chrome is not storing the session cookie at all for some users. After navigating to the site, the server tries to set a cookie and the employee is redirected to Google for auth, and then when they get back to the site their cookie is gone.

I reproduced the issue with minimal code in this simple php file:

<?php

session_set_cookie_params(60 * 60 * 24 * 7, '/', '.corp.company.com', false, true);
session_name('CompanySessionID');
session_start();
$_SESSION['UserName'] = 'test';

When an affected employee visits the page, the set cookie header comes through as expected, but Chrome does not store the cookie.

Additional details:

  • I've tried all the suggestions on PHP session lost after redirect
  • Originally the problem did not affect incognito mode, but starting a few days ago it does
  • Clearing cache/cookies has never helped the issue
  • Reinstalling Chrome previously would resolve the issue for around a week
  • The problem is not present in Firefox or Safari
  • Not all employees are affected
  • All employees use OS X
  • Changing the session name from CompanySessionID to CompanySession fixed the problem for a subset of users, and broke it for another subset of users
  • The sessions are still there on the server, it's just the cookie that's missing from the browser
  • Using a proxy to watch requests I can see that there are no headers that should be deleting the cookie.
  • We're using PHP 5.4.24

How can I find the source of this issue? Should I file a bug with Chrome?

brismuth
  • 36,149
  • 3
  • 34
  • 37
  • and all other browsers work fine? – cmorrissey Jun 07 '17 at 20:44
  • @cmorrissey firefox and safari both work fine – brismuth Jun 07 '17 at 20:51
  • 2
    there was a new release of Chrome 2 days ago, has that resolved the issue? and are you switching between https and http at all ? – cmorrissey Jun 07 '17 at 21:00
  • We actually rolled out HTTPS a few days ago. Looks like our handling of the secure flag was buggy, we weren't checking if `$_SERVER['HTTPS'] !== 'off'`, just if it was set. – brismuth Jun 07 '17 at 21:03
  • After fixing that and changing the session ID it looks like it's working. I wonder if this could have been causing the random logouts issue as well? I'll update on here if this change fixes that issue as well. Good call to look into that @cmorrissey. I saw https://stackoverflow.com/questions/441496/session-lost-when-switching-from-http-to-https-in-php?noredirect=1&lq=1 but didn't see the second answer. – brismuth Jun 07 '17 at 21:06
  • I found this as well https://productforums.google.com/forum/#!topic/chrome/mi_yiDZoCNc;context-place=topicsearchin/chrome/authorid$3AAPn2wQfnvSGmOzRO6_MHsTJGAbJOPGlSHIprTc5WlFh3iZIoBVkOh-KXSdCSWe19XW6ZR2gZkUrk%7Csort:date%7Cspell:false. Looks like the secure flag could have maybe been responsible for our issue that started Feb 1 as well. The timeline lines up. – brismuth Jun 07 '17 at 21:32

1 Answers1

2

I figured out the more recent issue with help from @cmorrissey. We rolled out HTTPS to the server recently, and when people got new cookies over HTTPS they'd get the secure flag set.

After that, the cookie would no longer be sent on requests over HTTP (as expected). However, what was unexpected is that Chrome would also no longer allow the server to set an insecure session cookie with the same name, since the secure one existed already. That's why the example PHP file shown in the question could not set the cookie at all unless the session name changed.

brismuth
  • 36,149
  • 3
  • 34
  • 37