Edit report at https://bugs.php.net/bug.php?id=67146&edit=1
ID: 67146
Updated by: stas@php.net
Reported by: lightnb at bellsouth dot net
Summary: PHP sends session info in the clear when secure is
enabled
Status: Open
-Type: Security
+Type: Feature/Change Request
Package: Session related
Operating System: Ubuntu 14.04
PHP Version: 5.5.11
Block user comment: N
Private report: Y
Previous Comments:
------------------------------------------------------------------------
[2014-04-28 23:55:13] stas@php.net
PHp can not know if the connection is secure or not, since PHP has no idea what network
infrastructure between the end client and PHP looks like. There could be relays, VPNs, multiple
routers and load balancers adding and removing layers of SSL... And PHP code be a responder at the
end of FastCGI protocol which doesn't have any knowledge even of the nearest hop, let alone all
the hops on the road. So checking for SSL on the last hop is useless security-wise, and may break
many valid setups which add SSL layer later.
The secure setting is not for PHP, it is for the browser - that does know if it's using HTTPS
or not to connect. PHP, however, has no good way to know if the browser used HTTPS or not and if it
will be using HTTPS in the future, since PHP may not be talking to the browser directly.
------------------------------------------------------------------------
[2014-04-28 15:30:45] lightnb at bellsouth dot net
Description:
------------
Using session_set_cookie_params() to enable "secure" cookies, PHP will set a cookie with
the secure flag, but does not check if the session_start() occurred over a secure connection to
begin with.
This creates two problems:
1. The SessionID is translated in the clear to the browser, which defeats the purpose of secure
SSL-only Session cookies.
2. Since the cookie is set to secure, it is not submitted when the page is refreshed or another
non-SSL page is navigated to. This is correct, but the result is PHP does not get the cookie and PHP
re-issues a new session ID cookie, which it then again, submits over plain text. When switching
between SSL and non-SSL, this can silently create all sorts of session oddities.
The user can solve this by wrapping the session setup in a block that checks if SSL is enabled, but
if the user does not realize this, they may think they are setting up a secure cookie, when in fact
they end of with a cookie that is transferred in the clear and reset on each non-SSL page.
Test script:
---------------
// Run over a non SSL connection:
session_set_cookie_params(0,'/','domain.com',true,true);
session_start();
Expected result:
----------------
I think this should throw at least a warning if not a fatal exception.
Either refuse to create the session and create a warning: "Session was not created. You asked
for a secure session cookie but this page is running over an unsecured connection".
OR
"Fatal Error: Cannot start secure session over an insecure connection"
Actual result:
--------------
From above:
1. The SessionID is translated in the clear to the browser, which defeats the purpose of secure
SSL-only Session cookies.
2. Since the cookie is set to secure, it is not submitted when the page is refreshed or another
non-SSL page is navigated to. This is correct, but the result is PHP does not get the cookie and PHP
re-issues a new session ID cookie, which it then again, submits over plain text. When switching
between SSL and non-SSL, this can silently create all sorts of session oddities.
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=67146&edit=1