ColdFusion 10 not writing to cfcookie on same browser but different computers - coldfusion

I am migrating websites from a server using CF 8 to a new one using CF 10. In this one site, I have a query that looks up talent and then writes the resulting list to a cfcookie. On my computer with any browser it works correctly. My client uses the same browser as I normally use (Safari) and his browser is not updating the cfcookie with the new talent list after a search. They are very unhappy making me unhappy also. Any ideas as to what might be causing this problem.
In the application.cfm (yes, I know I should be updating to cfc but not enough hours in the day):
<CFAPPLICATION NAME="lil"
CLIENTMANAGEMENT="yes"
SESSIONMANAGEMENT="yes"
SESSIONTIMEOUT=" #createTimeSpan(0,0,30,0)#"
APPLICATIONTIMEOUT=" #createTimeSpan(0,1,0,0)#"
clientstorage="cookie">
Setting the cfcookie:
<cfif isdefined('getTalent.recordcount') and getTalent.recordcount gt 0>
<cfcookie name="tSearch" value="#valueList(getTalent.talentID)#" httponly="true" expires="1">
</cfif>

How large is the amount of data you are storing in the cookie, and could the client be storing more than you are? Are they possibly using a cookie-blocking security app of some kind?
In a bigger-picture kind of mindset, if the user is doing a search and getting results, rather than storing the results in a cookie, why not use either a session-scoped variable, or simply use the CF identity cookies already in place to store their results in a temporary database location? Cookie issues can be harder to track down, but unless you're not managing sessions in your Application.cfc or cfapplication tag, each user is already getting a unique ID which you can leverage server-side for this type of thing.
One last thought... are you doing any sort of CFLOCATION redirect, after attempting to store the cookie? Redirecting can cause CFCOOKIE commands to not be honored, because in essence the user's browser is redirected before it receives the response.

Related

How do I secure CFID for PCI compliance?

We've been failing our PCI scans because ColdFusion has predictable CFIDs. The exact FAIL we get is "Predictable Cookie Session IDs". Now the CFTOKEN is no longer predictable since I've configured CF to use UUID for CFTOKEN, however, the CFID is still predictable and unaffected by any changes in CF Admin.
I don't really know why the CFID being predictable is a threat, but they want us to fix it.
I have been unable to find anything on the matter by googeling, and I'm really not sure what else to do.
Has anyone else dealt with something like this? Any suggestions?
EDIT:Here is what my Application.cfc file looks like:
<cfcomponent output="false">
<cfset this.name="DatabaseOnline">
<cfset this.sessionManagement=true>
<cfset this.setDomainCookies=true>
<cfset this.setClientCookies=true>
<cfset this.sessionTimeOut=#CreateTimeSpan(0,20,0,0)#>
</cfcomponent>
And my CF admin looks like this: http://i.imgur.com/k9OZH.png
So how do I disable CFID?
Using J2EE session variables should address that problem.
To do that go to CF Administrator. Server Settings --> Memory Variables and check the 'Use J2EE session variables' check box.
You can find some more information here http://helpx.adobe.com/coldfusion/kb/predictable-cookie-session-ids-reported.html
Explain to the scanning agent that the CFID is sequential, but is not valid without a corresponding CFTOKEN cookie which is randomized. Since the session cannot be hijacked with the ID alone, it mitigates the reason for the scan failure. Their automated test assumes that the CFID cookie controls the session on its own, which is not the case. Every scanning vendor that I've worked with has accepted this as a mitigating factor and either disabled or overridden that specific test for me on CF-based sites.
Alternately, if none of the sites on the CF server use session variables, you can disable session management entirely and CF won't issue the cookies at all. If they are needed, the above explanation of how CF sessions are managed should get you through.

Cookie handling in subsequent requests in same page

I'm creating my own (multi threaded) ISAPI based website in C++ and I'm trying to implement correct session management.
The problem is that when a new session should be created, the session is created twice when using subsequent requests in the generated web page.
Here's how it works:
- Client requests http://localhost and sends either no cookie or a cookie with an old session ID in it.
- Server looks at the session cookie and feels that it needs to create a new one because it no longer exists: it prepares a header with a cookie in it with a new session ID and sends the complete header to the client (I tracked this with http live headers plugin in firefox and it is correct). It also prepares some data like the page and and stuff like that (not yet body data, as it is still processing data from the database and stuff like that) and sends what it has back to the client.
- Client should have this new session cookie now, and sees the stylesheet link and immediately sends the stylesheet request http://localhost/css to my server. But... he still does this with the old session ID for some reason, not with the newly received one!
- Server sees this request (with again an no longer existing session id), generates another new session and sends the new session id with a cookie along with the stylesheet data.
So the client has received two session id's now and will from now on keep using the second one as the first one is overwritten, but nevertheless the first page has used the wrong session (or actually, the second page has).
You could say that this is not a problem, but when I start using personalized stylesheets, I will have the wrong stylesheet on the first page and as the page will use AJAX to refresh the content (if available), it is possible that the stylesheet is never reloaded unless the client refreshes.
So, is this a problem that is always there when doing this kind of thing? Will the browser always send an old cookie although it has already received a new one but is still processing the page? Is this a problem that, for example PHP, also has?
Note: before all the discussions start about "use php instead" or something: I am rewriting a website that I had first written in PHP, it became popular, had thousands of (real) visitors every hour and started killing my server (the website doesn't make that kind of money that I can throw lots of servers at it). By writing it in C++, requests take 2ms instead of 200ms in PHP... I can optimize everything. By taking my time to develop this ISAPI correctly, it is safely multi-threaded and can be multi-processed, multi-servered. And most of all, I like the challenge.
Added note: It seems that the problem is only there when an old session exists in the cookies, because when I completely clear all cookies from my browser, and a new one is created and sent back to the client, the subsequent stylesheet request immediately uses the given session id. This seems to be some kind of proof that I'm doing something wrong when an old session id is sent... Should an existing cookie be deleted first? How?
Added note: The cookie is written with an expire-date one year ahead.
I have found out what the problem was, I was in the assumption that setting a cookie without specifying a path would result in making the session work on all paths on that domain.
By using http://foo.bar/home as main page and http://foo.bar/home/css as stylesheet, internally translating that url to ?s1=home and ?s1=home&css=y, I was actually using two different paths according to the browser which did not pass the cookie to the css-request.
For some reason, they actually got together afterwards, I don't fully understand why.
Isn't this silly? Will people not often have a http://foo.bar/index.php and a http://foo.bar/css/style.css.php , just because they use subdirectories to keep their structure clean?
If anyone knows of a way to fix it, to make subpaths also work with the same cookies, let me know, but as I understand it from the definition of cookies, they are stuck within a specific path (although, it seems that if you specifically add a path other than /, it will work on subdirectories as well?)

Coldfusion load session from Id

Is there any way to load a specific user session by providing the correct value of CFTOKEN and/or CFID?
Something like php's session_id($id) function.
Or some way to change data of an specific session.
I need a webservice that will add or change some information on a specific user session. I know the CFID and CFTOKEN values because I share a subdomain cookie. However applications are on different servers
Not that it's the best way of doing things, as it uses undocumented code that can change without notice between versions. But you can use certain methods to access sessions.
<cfscript>
appName = 'zadsApp';
jSessTracker = CreateObject('java', 'coldfusion.runtime.SessionTracker');
appSessions = jSessTracker.getSessionCollection(JavaCast('string', appName));
targetSession = appSessions[appName & '_' & sessionCFID & '_' & sessionCFTOKEN];
// Dumping, reading, writing WILL update the last accessed time.
// There are ways around this if needed...
WriteDump(targetSession);
targetSession.something = 'A new value';
</cfscript>
Now you mention that this is on a different server, can I just double check that you want a seperate server to change a session on another server? Without putting any kind of code like the above on that server (the one with the session)? Although it'd be a heck of a lot easier if the code was on the same server, you might be able to perform code like this remotely using JMX... but I'm sure there must be an easier way to do all of this.
You can do it by passing the correct values on the URL, more information available here
http://ruthsarian.wordpress.com/2005/10/03/cf-session-hijacking/
ColdFusion uses two unique values to keep track of user session
information. These values are CFID and CFTOKEN. They are stored as
cookies but can also be passed along the URL and inside POST data.
Session variables are a place to store information specific to the
user and to the current session (such as whether or not a user is
logged in).
It is possible to hijack a user’s session by supplying the correct
CFID and CFTOKEN values to the server, either on the URL, or wherever
else you want.
What it sounds like you are trying to do is effecitvely described by this post http://old.nabble.com/ColdFusion-9-Session-Replication-td32621620.html which advises against session replication on grounds of high network usage due to it.
Where you are trying to maintain a specific sessions scope across multiple physical servers. The way I've worked around this in the past is to maintain a database storing the information which needs to be passed between physical servers tied to a UUID. For this purpose you could just use the CFID/CFTOKEN values as your database PK's, or you could make another PK altogether. This would then allow you to pass the CFID etc on the URL string, and then if it hits a server which it hasn't so far hit (i.e. no session / session wasn't loaded using those CFID/CFTOKEN) then you can load the variables you need from a database.
Edit an alternative non-database method
Firstly set up a script on one server i.e. getSessionData.cfm which returns
the data in the session scope in transportable format i.e. using
SaveObject() (if on CF9), or maybe SerializeJSON(), something like
that
<!--- on source server, getSessionData.cfm --->
<cfscript>
WriteOutput(ToBase64(ObjectSave(session)));
</cfscript>
Then set up a handler that will request data from the other server
using a cfhttp request populating CFID/CFTOKEN to access the session, and then pull that data into the session on the new server.
<!--- on target server --->
<cfhttp url="http://sourceserver/getSessionData.cfm">
<!--- Params to pass through CFID/CFTOKEN or any other cookie/url/post params etc --->
</cfhttp>
<cfscript>
structToImportToSession = ObjectLoad(ToBinary(cfhttp.FileContent));
for (thisStructKey in structToImportToSession) {
session[thisStructKey] = structToImportToSession[thisStructKey];
}
</cfscript>
The problem with this is that I would feel uneasy with this kind of script being on my server in a production environment. It also means that you will need to know explicitly which physical server the user came from so that you can request the getSessionData.cfm script from the correct server.
This post from Ben Nadel seems to employ a similar principle to update session data, same could be applied for updating it I expect, http://www.bennadel.com/blog/725-Maintaining-Sessions-Across-Multiple-ColdFusion-CFHttp-Requests.htm
Personally I'd still advise the database-drive method as it gives you clearer mechanics by which to purge old sessions etc, however this second option should be viable and give you access to what you need.
as long as the session isn't expired you can access a session by using the CFID and CFTOKEN in the url

Coldfusion uses wrong (cached?) variables at random

We have a dedicated server running CentOS and Coldfusion 8.
All cfmail email is routed through Google with cfmail and smtp.
Every now and then, when cfmail is used, the 'FROM' field uses an address from a totally different website.
For instance:
Use form on Site A
Get an email: "Subject: On Site A From: siteb#siteb.com"
Where the from is a completely different variable in another set of code on another part of the server- there is no reason it should see this.
On the other side, sometimes sending an email to sitea#sitea.com has email wind up in Site B inbox, a completely different Google account.
What causes this to happen? Some kind of memory/cache issue? Or is there a funky DNS record causing issue?
Example:
Application.cfm (starts with some UDF includes, and then):
<cfinvoke component="#request.componentPath#.variables" method="getGlobal" />
Variables.cfc (a lot of variables defined within, but here is the cfmail vars):
<cffunction name="getGlobal" access="public" output="false" returntype="void">
<cfscript>
request.siteEmail = "email#mysite.com";
request.siteMailServer = "smtp.gmail.com";
request.siteMailUsername = "root#mysite.com";
request.siteMailPassword = "[redacted]";
</cfscript>
</cffunction>
It sounds like it's possible it could be a var scoping issue, but we can't know for sure until you share some code...
Looks like you're running multiple sites? there's a setting in the CF caching page in admin to do with caching web server paths:
From http://help.adobe.com/en_US/ColdFusion/9.0/Admin/WSc3ff6d0ea77859461172e0811cbf3638e6-7ffc.html :
Disabling the cacheRealPath attribute To ensure that ColdFusion always returns pages from the correct server, disable Cache Web Server Paths in the Caching page of the ColdFusion Administrator. (When you use the multiserver configuration, set the cacheRealPath attribute to false for the ProxyService in the jrun_root/servers/servername/SERVER-INF/jrun.xml file.)
Might not be it, but it's at least quick to try out.

Cookie write fails to work on hosted site

I have created a basic but extensive javascript-html page that depends on cookies to keep user information. It runs perfectly on my computer (MAC - Firefox) but when loaded into my hosted web site (the page is in my domain) the cookies are not being written when the page is opened.
I was hoping that by keeping all the programming in javascript I could get some basic interactivity. Is this assumption wrong? Must the cookies be written using PHP?
My cookie writes are very vanilla.
document.cookie = cookieArray[ja]+expires+"; path=/"; // writes cookie data into browser.
update
well cookies are now being written since I added "path=/; domain=.my.org". But now there is one other problem.
It seems that safari and Firefox write the cookies in reverse order to each other. I create the cookies by altering an array then simply stepping thru the array to write the cookies. I was hoping that I could simply read the cookies one by one and keep the order. Ah well.
Did you added the ";" between cookieArray[ja] and expires?
document.cookie = 'cookie-name=cookie-value; expires=Thu, 01-Jan-70 00:00:01 GMT;';
Also the cookieArray[ja] have to contain the cookie-name.
Do you really need the path? This parameter is also optional.
Cookies are, by default, available to all other files in the same directory the cookie was created in.
http://www.comptechdoc.org/independent/web/cgi/javamanual/javacookie.html