CRE LOADED SECURE COOKIES VULNERABLE

[David M. Graham]

Is any solution posted here GUARANTEED to work?//

We guarantee solutions to work when they might reasonably be expected to work.

When an issue is complex and a clear solution depends on a lot of complex variables we say so.

The fact is, this particular issue is a prime example of that sort of scenario.  You just can't have your cake and eat it too.

David

[butlimous]

Is any solution posted here GUARANTEED to work?//

[David M. Graham]

This seems to me to be a prime example of why the best security results from an approach which is more collaborative than traditional "perimeter" style security paradigms.

It is also a clear indication of some of the complexities involved in securing connections - not so much technical challenges as organizational issues which can drastically prolong time to solution.

David

[ccwjr]

Yes, it shows that the session.cookie_secure is only sent over a secure connection.  Therefore is not really a solution to the problem.  However, note that the session.cookie_httponly is a complete solution, but sadly it is not well implemented in browsers yet and requires PHP 5, so older sites cannot take advantage of it.

[inetbiz]

session.cookie_secure boolean

• session.cookie_secure specifies whether cookies should only be sent over secure connections. Defaults to off.
• This setting was added in PHP 4.0.4. See also session_get_cookie_params() and session_set_cookie_params().

session.cookie_httponly boolean

• Marks the cookie as accessible only through the HTTP protocol.
• This means that the cookie won't be accessible by scripting languages, such as JavaScript.
• This setting can effectively help to reduce identity theft through XSS attacks (although it is not supported by all browsers).

   
Is this the particular section?

[ccwjr]

Would there be any useful information on this link? http://www.php.net/manual/en/function.session-set-cookie-params.php

That page is bit lacking, but does give the format of the command.  This pages has some useful information:
http://www.php.net/manual/en/session.configuration.php#ini.session.cookie-secure

[inetbiz]

Would there be any useful information on this link? http://www.php.net/manual/en/function.session-set-cookie-params.php

[ccwjr]

From what I understand, only issuing the "Secure" parameter in code when the connection travels through SSL, allows the browser to decide how to handle the "Secure" cookie.

If the "secure" flag is set on the cookie and the site is access as https, then the browser sends the cookie.  If the "secure" flag is set on the cookie and the site is access as http, no cookie is sent since there is no secure channel for it to travel.

This is fairly easy to test.  Simply change the cookie to secure in the code.  The site will not hold any sessions in http mode, since the cookie is not passing the information.  If you access https and stay only on https pages, the session will hold just fine.
Charles

[inetbiz]

But we need to look deeper and consider what options are available to address this issue at this time.  First, if the domain is access in http mode, the “secure” flag offers no assistance since it will not send the cookie across and unsecure channel.  Since most sites are referenced initially in http mode, all the session cookies are potentially exposed.  Using the above posted code, it sets the session cookie to “secure” when the site moves to https mode.  This would appear to be a good thing, except the session has already been exposed.  But consider what happens when the site moved from https back to http mode, the session cookie is not presented since it is an unsecure channel.  PHP is forced to create a new session resulting in the lost of all session data.

From what I understand, only issuing the "Secure" parameter in code when the connection travels through SSL, allows the browser to decide how to handle the "Secure" cookie.

[ccwjr]

I would argue that the original post of an error is flawed.  The suggestion being made is that because the session cookie is not “secured” there is an alternative and therefore it needs to be fixed.  This assumption needs to be tested.

First, consider that cookies are returned only to the domain that issued them.  Next consider that it is possible that someone has modified a template to pull JavaScript code from another site.  Is possible that this JavaScript could read a cookie destined for its own domain?  I would agree that it is possible.  This would then appear to be a security issue.

But we need to look deeper and consider what options are available to address this issue at this time.  First, if the domain is access in http mode, the “secure” flag offers no assistance since it will not send the cookie across and unsecure channel.  Since most sites are referenced initially in http mode, all the session cookies are potentially exposed.  Using the above posted code, it sets the session cookie to “secure” when the site moves to https mode.  This would appear to be a good thing, except the session has already been exposed.  But consider what happens when the site moved from https back to http mode, the session cookie is not presented since it is an unsecure channel.  PHP is forced to create a new session resulting in the lost of all session data.

Can this be gotten around?  Sure, by placing the session id in the URL or as part of the fields on the page to be posted back, the code can detect and adjust the session name.  But this is the worst security practice.  The browser will enforce returning a cookie to its own domain.  The web page code can be read or posted to whatever site.  Worst, the URL with the session embedded in it can be copy and pasted wherever.   
For the best security, the session ID should appear ONLY in the session cookie and never anywhere else. 

So what we end up with is something that does not work and the only way to make it work is to expose the session even more.

There is an actual proposed solution that solves this issue, but is not currently part of the official W3C standards.  Microsoft, of all people, has proposed the HTTPOnly flag which will prevent the session cookie from being access by JavaScript.  But until it is accepted as a standard, it will have questionable support in the browsers.

[zip1]

the orginal fix I suggest was incorrect, in that I used the word secure. it should have been a php boolean value of TRUE or FALSE

original line:
// set the cookie domain
  $cookie_domain = (($request_type == 'NONSSL') ? HTTP_COOKIE_DOMAIN : HTTPS_COOKIE_DOMAIN);
  $cookie_path = (($request_type == 'NONSSL') ? HTTP_COOKIE_PATH : HTTPS_COOKIE_PATH);

change to:

// set the cookie domain
  $cookie_domain = (($request_type == 'NONSSL') ? HTTP_COOKIE_DOMAIN : HTTPS_COOKIE_DOMAIN);
  $cookie_path = (($request_type == 'NONSSL') ? HTTP_COOKIE_PATH : HTTPS_COOKIE_PATH);
  $secure = (($request_type == 'NONSSL') ? FALSE : TRUE );

original line:
  // set the session cookie parameters
  session_set_cookie_params(0, $cookie_path, $cookie_domain);

change to :
  // set the session cookie parameters
  session_set_cookie_params(0, $cookie_path, $cookie_domain, $secure);

$request_type is a GLOBAL value the is set several lines up. It's values depends on if the url is HTTP or HTTPS.

Cookie can be set via several methods, when building the server header or using the php functions set_cookie or using session_set_cookie_params

since only the basic session id, site, and expire information is placed in the actual cookie.
session_set_cookie_params is used to configure the cookie. Then when the session_start used the cookie
is ready to be sent via the http header.

it must be set before the first session start() is issued. but after the session is named. It must also be reissued before any session restarts

parameters for session_set_cookie_params

lifetime ~ this is how long the cookie will exist before it expires The value 0 means "until the browser is closed." other wise the number of seconds the cookie should exist.

path ~   path the cookie is valid for. If you cart is located in a sub directory of your web site and you only want the cookie to apply to the cart then the sub directory is placed here. The cart uses the
HTTP_COOKIE_PATH or  HTTPS_COOKIE_PATH from the configure.php file
 

domain ~ Domain the cookie is valid for. sure as mysite.com  or mysub.mysite.com. The cart uses the
HTTP_COOKIE_DOMAIN or  HTTPS_COOKIE_DOMAIN from the configure.php file

secure ~ TRUE or FALSE  Is this cookie for a https url. This must be a true php Boolean value, which means
true false must be all caps.

httponly ~ true of false marks the cookie as only being excepted by http protocols. script languages like javascript then won't be able to read the cookie.
this is only support in the following browsers:
IE 6 SP 1 and higher.
Firefox 3 and higher.
Opera 9.50 and higher.
Safari 3.1.1 (April 2008) does not yet support this

[inetbiz]

Code: [Select]

Path: /index.php --> No "Secure" Attribute on Secure Channel (https) : osCsid=bde2545d0a93cb04e08411d68c597cc1; path=/; domain=######.authsecure.com#######=censored

[inetbiz]

I will try the code that you suggested lines 166-171 by replacing:

Code: [Select]

session_set_cookie_params(0, $cookie_path, $cookie_domain);
with:

Code: [Select]

  /// set the session cookie parameters
 if( $request_type = 'NONSSL'){
  session_set_cookie_params(0, $cookie_path, $cookie_domain);
   } else {
  session_set_cookie_params(0, $cookie_path, $cookie_domain, 'secure');
  }

Possible fix:

File: application_top.php

find: session_set_cookie_params(0, $cookie_path, $cookie_domain);

replace with below

Code: [Select]

// set the session cookie parameters
 if( $request_type = 'NONSSL'){
  session_set_cookie_params(0, $cookie_path, $cookie_domain);
   } else {
  session_set_cookie_params(0, $cookie_path, $cookie_domain, 'secure');
  }

[zip1]

Possible fix:

File: application_top.php

find: session_set_cookie_params(0, $cookie_path, $cookie_domain);

replace with:
  // set the session cookie parameters
 if( $request_type = 'NONSSL'){
  session_set_cookie_params(0, $cookie_path, $cookie_domain);
   } else {
  session_set_cookie_params(0, $cookie_path, $cookie_domain, 'secure');
  }

[inetbiz]

Name: CVE-2008-2558
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2558
Reference: MISC:http://oscommerceuniversity.com/lounge/index.php?topic=255.0

CRE Loaded 6.2.13.1 and earlier does not set the "Secure" attribute
for cookies that are sent over HTTPS, which might allow remote
attackers to sniff the cookies if they are sent over HTTP.