tracker issue : CF-3572565

Duplicate ID:	CF-3593673

Problem Description:  CF10 is writing CFID and CFToken cookies as DOMAIN cookies, and (apparently) ignoring the 'SetClientCookies' attribute on CFApplication.  Net result is CFID/CFToken pair global to the entire domain, leading to session loss if any other CF instance (anywhere in the entire domain) is accessed.  In combination with another bug found in both CF9 and CF10 (also submitted by me, number not available because it was reported as a 'security' bug), if the CF10 instance creates the first cookie for a given user, that user will not be able to establish a session with any other CF9 instance in the domain.

Steps to Reproduce:
   set up the configuration described below
   browse to the CF10 instance at http://red.test.xyz:8010/test/test.cfm
   > view cookies in firebug
   >>>> - observe that the CFID/CFToken cookies have the domain '.test.xyz' - 'red.test.xyz' is expected
   >>>> - also observe that the cookies are NOT session cookies, as they should be (according to the CFCookie attributes)

For worst-case scenario...
  now browse to the CF9 instance at http://green.test.xyz.8009/test/test.cfm
  >> observe that new CFID/CFToken values were created (this is expected - first hit to 'green'
  >> view cookies - observe that there are now duplicate cookies for CFID/CFToken - one set for .test.xyz, one for green.test.xyz
  reload this page...
  >>> observe duplicate keys in CFDump output (this is the other issue I reported)
  >> observe also that the CFID/CFToken values are NOT the same as the previous request - these will update *for every subsequent request*


Actual Result:
domain-wide chaos >> NOTE - the 'adobe.com' domain is affected by this problem - as noted in other issue - if a user's first visit (since clearing cookies) is to a CF10 instance in adobe.com (so a .adobe.com CFID/CFToken pair exists in their cookie jar) and then attempts to access bugbase.adobe.com - infinite redirect [bugbase appears to not be upgraded to CF10 yet]

Expected Result: unique CFID/CFToken pairs maintained for each server name

Any Workarounds: adding '-Dcoldfusion.session.protectfixation=false' in jvm.config is a partial solution, but must be done for all CF instances in domain, resulting in substantial (and unacceptable) security risk

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3572565

External Customer Info:
External Company:  
External Customer Name: TParker
External Customer Email:  
External Test Config: To see the bug itself, all you need is one CF10 instance and a site with session management enabled and a fully-qualified server name (test1.adobe.com).



For ease of viewing cookies, use either FireFox with FireBug installed... or Chrome



for the worst-case scenario, you will need at least one CF10 instance and at least one CF9 instance.  For discussion, let's say these instances are on port 8009 (the CF9 instance) and 8010 (the CF10 instance)



Add the following entries to the 'hosts' file on the machine where your browser is running [update the IP address as appropriate so these aliases all point to the server where the CF instances are running]:



127.0.0.1 red.test.xyz

127.0.0.1 green.test.xyz

127.0.0.1 blue.test.xyz



Place the following two files in an otherwise-empty directory ('test', for purposes of discussion) at the web root for each CF instance:



Application.cfm:

==============



<cfset sessionTimeout = CreateTimeSpan(0,0,60,0)>



<CFAPPLICATION NAME="CommonSpot" SESSIONMANAGEMENT="Yes" SESSIONTIMEOUT="#sessionTimeout#" SetClientCookies="NO">



<cfcookie name="CFID" value="#Session.CFID#">

<cfcookie name="CFToken" value="#Session.CFToken#">



==============

test.cfm

========

<CFOutput>hello, world<br /></CFOutput>

<cfcookie name="hello" value="hello cookie set at #Now()#">

<cfscript>

	foo = StructNew();

	foo.name = "goodbye";

	foo.value = "goodbye cookie set at #Now()#";

	foo.httponly="yes";

</cfscript>

<cfcookie AttributeCollection=#foo#>



<cfdump var=#cookie# label="Cookie">



=========================

Attachments:

Comments: