1

I have an issue with PHP session cookies which is affecting only users of Internet Explorer who are using security software including McAffee, AVG and Norton. Some (but apparently not all) users of IE and these security packages are unable to login or add items to their basket, as it appears the software is blocking the session cookie created by PHP.

  • Using standard IE, Firefox, Opera et al. session cookies work as normal.
  • Changing IE security settings to the max still allows the cookies through.
  • Cookies are not encrypted.
  • We do not have PCI compliance, but we do have an up-to-date EV SSL certificate.
  • Cookies are created by a custom (third-party) session class.
  • We have tried installing the software packages but have not been able to recreate the bug.
  • We know from ecommerce conversion that this is affecting only/mainly IE users.

The session is started using session_start() and we're defining the following settings for it: 

@ini_set('session.use_cookies', 1); 
@ini_set('session.use_trans_sid', 'Off'); 
@ini_set('url_rewriter.tags', ''); 
@ini_set('session.gc_probability', 1); 
@ini_set('session.gc_divisor', 100); 
@ini_set('session.referer_check', ''); 
@ini_set('session.gc_maxlifetime', 604800); 
session_set_cookie_params($this->session_lifespan, '/', null, null, TRUE); 
session_start();

Session lifespan is set to 21600 (six hours)

What could be the possible cause of the cookies being blocked? Are these security packages known for this and are there any coding workarounds?

random
  • 9,774
  • 10
  • 66
  • 83
Matt
  • 31
  • 2
  • Can you show the details of the set-cookie header? Especially what domain/path you use when setting the cookie. – ThiefMaster Feb 25 '11 at 09:59
  • Thanks for your reply. The session is started using session_start() and we're defining the following settings for it: `@ini_set('session.use_cookies', 1);` `@ini_set('session.use_trans_sid', 'Off');` `@ini_set('url_rewriter.tags', '');` `@ini_set('session.gc_probability', 1);` `@ini_set('session.gc_divisor', 100);` `@ini_set('session.referer_check', '');` `@ini_set('session.gc_maxlifetime', 604800);` `session_set_cookie_params($this->session_lifespan, '/', null, null, TRUE);` `session_start();` Session lifespan is set to 21600 (six hours). – Matt Feb 25 '11 at 10:26
  • Never heard about something is blocked just about Cookies. There must be more. – powtac Feb 25 '11 at 10:34
  • SSL: is there a switch to/from SSL? If you set the cookie in HTTPS it can't be read over HTTP. Or are your users seeing pop-ups from their AV software about the blocked cookie? – Rup Feb 25 '11 at 10:39
  • Yes, there is a switch for HTTPS/HTTP. Users don't see any error message in their browser. When they try to add an item to their basket, it isn't added and they're unable to login because the session doesn't work. – Matt Feb 25 '11 at 10:50
  • OK - so why do you suspect the security software? – Rup Feb 25 '11 at 12:14

2 Answers2

0

I believe that you'll need to have a different session when switching from/to Http/Https.

Since the session handler usually uses cookies, and cookies can't be shared between http/https, the session will appear to be lost after the switch.

user643373
  • 1
  • 1
0

What could be the possible cause of the cookies being blocked?

Dumb software for dumb people? Certainly there other people out there thinking they are doing the world a service by breaking existing functionality.

But if you can't replicate the issue, then possibly they are not doing anything wrong.

Session lifespan is set to 21600 (six hours)

Are you setting an expiry time on the session cookies? Id so, now that both FF and MSIE private 'private' browsing functionality - I'd expect this to be a more likely candidate.

Do make sure you're setting the httponly flag on the cookies - and try setting the secure flag (although this obviously has other implications for navigation).

symcbean
  • 47,736
  • 6
  • 59
  • 94