php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #40778 Cookies with secure parameter sent via HTTP
Submitted: 2007-03-11 22:20 UTC Modified: 2007-03-23 15:05 UTC
From: mbowie at buzmo dot com Assigned:
Status: Closed Package: Documentation problem
PHP Version: 5.2.1 OS: FreeBSD 6.0R
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: mbowie at buzmo dot com
New email:
PHP Version: OS:

 

 [2007-03-11 22:20 UTC] mbowie at buzmo dot com
Description:
------------
Cookies sent via the set_cookie method or via PHP's session module with the secure parameter set to true can be sent via HTTP.

http://php.net/set_cookie has notes against the secure flag which states : "Indicates that the cookie should only be transmitted over a secure HTTPS connection. When set to TRUE, the cookie will only be set if a secure connection exists. The default is FALSE.".  This does not appear to be the case.

It's possible that this is by design, but if so, perhaps it's worth noting on the documentation at the secure parameter only refers to the browser's activities, not those of the webserver.

The upshot of this is that an attacker may pickup a visitor's cookie by sniffing HTTP traffic on the wire and craft their own cookie in order to spoof the visitor's identity on the secure side.

The same thing happens on 4.3.9, 5.2.0 and 5.2.1; all of which are compiled via the FreeBSD ports tree and are running on various flavors of FreeBSD.

Reproduce code:
---------------
$domain = 'setme';

setcookie('setcookie', 'insecure', time()+3600, '/', $domain, true);

session_name('session_set_cookie_params');
session_set_cookie_params(
        time()+3600,
        '/',
        $domain,
        true
);
session_start();


Expected result:
----------------
No cookies should be sent to the browser unless the page is requested via an SSL encrypted channel.

Actual result:
--------------
Cookie headers are sent regardless of whether the page is requested via HTTP or HTTPS.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-03-12 09:27 UTC] tony2001@php.net
Secure
  OPTIONAL.  The Secure attribute (with no value) directs the user
  agent to use only (unspecified) secure means to contact the origin
  server whenever it sends back this cookie, to protect the
  confidentially and authenticity of the information in the cookie.

  The user agent (possibly with user interaction) MAY determine what
  level of security it considers appropriate for "secure" cookies.
  The Secure attribute should be considered security advice from the
  server to the user agent, indicating that it is in the session's
  interest to protect the cookie contents.  When it sends a "secure"
  cookie back to a server, the user agent SHOULD use no less than
  the same level of security as was used when it received the cookie
  from the server.
http://www.faqs.org/rfcs/rfc2965.html
 [2007-03-23 15:05 UTC] vrana@php.net
"Indicates that the cookie should only be transmitted over a secure HTTPS connection from the client. On the server-side, it's on the programmer to send this kind of cookie only on secure connection (e.g. with respect to $_SERVER["HTTPS"])."

Tony, I think that browsers send this cookie only through HTTPS, essence of this bug is that secure relates to the client and not to the server IMHO.
 [2007-03-23 15:05 UTC] vrana@php.net
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Nov 24 05:01:32 2024 UTC