URGENT HELP NEEDED - Credit Card Security Issue

[shunnyboy]

I have a session problem that appears to be Server/Coldfusion related - not caused by my code (pretty sure), any insight suggestions would be greatly appreciated.

I was wondering if anyone has any experience with where a Coldfusion session for an individual user gets given as a session to another completely new/different user as their session?

I have an online shopping cart and the issue is that when the onSessionStart event is fired in the Application.cfc a component instance is created for the user. This just initialises default user variables (logged in, name etc), and at this point they are obviously not logged in to any account. The user component stays like this until they either a) successfully register or b) they login successfully to an existing account.

These are the only two methods that a user may be logged in. However I have had (twice) where a user has arrived at the website and should have a brand new session yet instead of this they are able to view an entirely different user's session (this is bad as you can imagine as they are able to see someone else's personal details/credit card information) :(

I have no idea how it is possible for someone who should get a brand new session to receive someone else's session???

I have re-checked my code and confirmed that the only way that a user can be logged in is via the login/registration pages, in this case neither has happened - the user only arrived at the home page.

Any help would be great.
Regards,
Shaun Byrnes
Web Developer
Netgrow
W www.netgrow.com.au
E shaun@netgrow.com.au
P 02 9718 5446
F 02 9718 0623

[Newsgroup_User]

cached templates on the server? are you sure your user is not seeing a
cached version of the page from server cache?

other than that, which version f CF? which web server? how do you log
users in (CF's login famework or some custom code?)? how do you log them
out/expire their sessions (overwriting session cookies?)?

i believe it is highly unlikely that CF assigns exactly same session to
a completely different user... unless both are using the same computer
and you have problems with session expiration/user logout...

Azadi

[shunnyboy]

I am not caching any templates on the server myself, The CF version is: ColdFusion MX 7.0.2, It is custom loging code that confirms the login register is successful and stores that users data in a CFC in the session scope, the session expires after 1hr as defined in the Application.cfc or they can click a logout button which sets a login status in the session based user component to false (rendering them "logged out")

I hope that that info gives you some more insight...

[iKnowKungFoo]

Are all your session variables written to and read from using cflock? CFMX is multi-threaded, so if they aren't locked then it's possible that, under load, information could be leaking across sessions.

[shunnyboy]

Hi,

Thanks for the relpy. There is no locking being done when the user component is created, as this is done inside the onSessionStart method of the application.cfc I was under the impression that this was not neccessary as it is a single threaded operation? (please clarify this point if possible)

And yes the website is under a reasonable ammout of load so what you are saying could be feasable. Any ideas?

[iKnowKungFoo]

Is there any application variable that access this session User object? Is the session User object injected into any other component that is then placed in the application scope? Is there any place other than onSessionStart() where a session variable is changed? Are your User bean's setters all access="private"?

I'd suggest reading There are no Pointers in ColdFusion to see if the example describes the issue you're having. I've a post on my site that may be relevant as well: Using a Session Facade to handle evolving session variables. Check the section marked "The Pitfalls" to see if that type of code looks familiar.

[Stressed_Simon]

Make sure that when you are using cflocation that you put addtoken="false" this prevents the cfid and cftoken getting appended to the url. If these get shared at any point then sessions can get hijacked.

[shunnyboy]

@Stressed_Simon
I have checked and there was some locations that were passing CGI.QUERY_STRING as part of the url aswell as addtoken="true" - I have fixed this (in the case of what was happening though - a brand new user arriving at the website I don't think this is an issue but changed it none the less)

@cf_menace
There are no variables in the APPLICATION scope that reference vars in the SESSION scope.

Thanks for the replys - any other suggestions?

[JohnEric]

Is there perhaps a var scoping issue in the onSessionStart method?

[shunnyboy]

var scoping issue? please elaborate...

[iKnowKungFoo]

The var scope makes a variable available to the current cffunction only. If you have two functions and each define the variable "foo", without using the var scope ( <cfset var foo = "Hello" /> ), then foo is placed into the variables scope ( variables.foo ), which is available to every function in the component.

When this happens, there is only one instance of "foo" and both functionA and functionB can alter its value.
If you var scope the variable, then there is an instance of "foo" for funcitonA and an instance of "foo" for functionB. functionA can't alter the value of foo inside functionB and vice-versa.

Dave Shuck posted a Thread safety example: Var scope your loop index in ColdFusion CFCs, so you can see exactly what this means.

[JohnEric]

not only can FunctionA and FunctionB both alter foo, FunctionA run in Session1 can change the value of foo for FunctionA in Session2.

[chexonec]

"However I have had (twice) where a user has arrived at the website and should have a brand new session yet instead of this they are able to view an entirely different user's session"

Do you know how these users got to your site? If they clicked a link (in a search engine, or in an email or anywhere else) that contains a cftoken and cfID, then anybody using that link will be sharing the same session.

You can see if this is the problem by adding something like this to your application.cfm file:

<cfif isDefined('URL.cftoken')>
<cfmail to:"you@domain.com" from:"you@domain.com">
Someone tried to access my page with a URL with CFToken in it
The referrer is #CGI.http_referrer#
</cfmail>
</cfif>

That way, if there is a published URL somwhere with session info, you'll know it.

HTH

[shunnyboy]

@cf_menace
All local vars are created locally with the "var" directive, all instance vars are in the private VARIABLES scope.

@chexonec
In the case where this happened the person said that they just typed in the URL of the website and saw it on the first page...

As far as doing something like this:
<cfif isDefined('URL.cftoken')>
<cfmail to:"you@domain.com" from:"you@domain.com">
Someone tried to access my page with a URL with CFToken in it
The referrer is #CGI.http_referrer#
</cfmail>
</cfif>

What would be the point every page on the entire website passes the SESSION token though the URL to account for the fact they may have cookies disabled.

Any other suggestions?

All help is greatly appreciated.

[chexonec]

"What would be the point every page on the entire website passes the SESSION token though the URL to account for the fact they may have cookies disabled."

That is a big security risk. It will inevitably lead to session crossing as people share links and links are indexed. Unless you writ your own session tracking code, and don;t use CF's, then you must require cookies. My two cents... from experience.

[shunnyboy]

@chexonec

I'm not quite sure that I follow exactly, I am just following the suggestion in the WACK book by Ben Forta/Ray Camden in the section regarding sessions and cookies and passing the URLToken through to every page to match up a client to their session. Obviously cookies do the job if they are there but this was supposed to be a fallback regardless of if they were enabled or not. What are you supposed to tell the users that have cookies turned of when the website doesn't work?

Additionally this error was apperent when the user had typed in just the root url ie no session token existed in the url yet it still happened...

Any more ideas/suggestions?

[chexonec]

"What are you supposed to tell the users that have cookies turned of when the website doesn't work?"

Sorry, you must enable cookies to use this site...

Try disabling your cookies and see how many of the popular internet sites won't let you in. It's pretty standard for sites to require cookies. That said, it IS possible to do a more secure job than the standard CF does. But it requires some work. I think there is a custom tag out there that does it well.

I know this doesn;t solve your problem, but it will BECOME a problem as your site gets bigger. The following happened to me a couple years ago: I was using the URL tokens for people who didn;t have cookies enabled. A search engine crawled my site, and it didn't have cookies enabled, so it indexed some URLs with the URL session tokens in them. Anybody who clicked on those linked ended up on the same session. It was a nightmare.

Godd luck with your current problem. I;m sorry I can't be of more help.

[shunnyboy]

Thanks for the heads up, as this has become more apparent as it has been get more and more traffic. A question though - wouln'd the sessions that were indexed have expired by the time that they were found in google?

Another thing, despite that being good info, this doesnt explain why when someone typed in http://www.domain.com (notice no URLToken) that they had this issue...

[Steve Sommers]

For the sites I create, I try to depend on cookies as little as possible BUT I do depend on cookies. By this I mean that people can surf and view pages all they want with or without cookies enabled but if they put something in their basket, my basket page has code to detect if cookies are enabled and if not, I do display "Sorry, you must enable cookies to use this feature..."

I ran into this same problem years ago and still have not found an alternative that did not have more security issues than the problem I was trying to solve.

IMHO, cookies are not as evil as they were five or ten years ago so the chances are less and less that a person will have them disabled. Chances are even less that the security conscience person with cookies disabled is so paranoid that he/she won't temporarily enable them even to place an order. Heck, if they are that paranoid, why would they key in their personal information on an order form?