ASP.NET Session Mix-up using StateServer (SCARY!)

views:

425

answers:

+2 Q:

ASP.NET Session Mix-up using StateServer (SCARY!)

We store two objects in session. Somehow, one of the objects from another users got loaded into a different users session. The user should have had no access to this particular data, and as soon as they saw it they knew something was very wrong. We have visual proof of the data that was presented to him, and there is certainly no way it could've happened unless the sessions got mixed up. This is a very scary situation which we can not figure out (of course we can not reproduce it). The only answer for us is to blame ASP.NET StateServer for mixing the session variables up, which is completely unacceptable and puts us in a bad position.

Our applications are ASP.NET 2.0 apps running on Windows Server 2003 with IIS6, using the StateServer cookieless="false" session mode and FormsAuthentication.

Has anybody else had this problem? How can we resolve it?

+5 A:

Look for bugs in your own code first - this is by far the most likely explanation. E.g. using static fields or other shared memory such as the ASP.NET cache for user-specific data.

Joe 2009-10-29 20:20:01

I just spend the last ten days doing just this. I emphasized the word "certainly" in my question for a reason. Trust me, our code is bulletproof.

Josh Stodola 2009-10-29 20:22:31

Additionally, this app has been in production for years and we've only encountered this problem once.

Josh Stodola 2009-10-29 20:24:25

+1 Every time I've seen something like what Josh is describing, that is the culprit.

Kevin 2009-10-29 20:24:53

"Trust me, our code is bulletproof." The evidence suggests otherwise! And the fact that a race condition only happened once is not necessarily surprising.

Joe 2009-10-29 20:25:37

I understand your point of view and I appreciate your insight. If I came to this question, my answer would've been the same as yours. That said, please trust that I have spent more time than you could ever imagine on trying to find a bug in our code that would allow this to happen. There's nothing there, it's not an overly complex app, and I am 100% (yes, it is just as difficult for me throw that figure out there as it is for you) certain that the problem is not with our code.

Josh Stodola 2009-10-29 20:31:17

"I am 100% certain" - I'm sure you believe that, but I'm sure you'll understand you'll have a job convincing anyone else without showing them the full source code.

Joe 2009-10-29 20:56:30

I know, Joe. That's why I dug and dug and dug for about 2 weeks before I finally threw in the towel and posted this question.

Josh Stodola 2009-10-29 21:00:02

I've been trying to help solve a problem on a site that hit this same kind of issue. I can understand Josh's frustration - I too have spent countless hours debugging this to come to the conclusion that Select is broken here.

Jeff Handley 2010-09-17 05:15:07

How many times did it occur? Did you check for users using browser back or sending links to each other with session ids?

One way to check for sure about State Server bug is to switch to another session manager, fallback to in-proc if you can or use SQL Server but would be better to find a way to reproduce the bug it first so you could test it.

Wagner 2009-10-29 20:32:33

It has only occurred once. Browser back is definitely not it, because the users authentication would not allow access to this data at any point. There's no way they are doing anything like hacking session IDs either, our users are older businessmen that don't even know what a session is.

Josh Stodola 2009-10-29 20:36:22

+1 A:

Possible answer - similar isue reported using cookieless session state.

http://forums.asp.net/p/1469515/3400095.aspx

Edit - Added

Another possible answer:

http://support.microsoft.com/kb/917072

David Stratton 2009-10-29 20:50:18

David, I was wrong. Session mode is NOT cookieless.

Josh Stodola 2009-10-29 21:00:33

+1 because the second link edited in seems promising.

GBegen 2009-10-29 21:59:13

+3 A:

We ran into this exact issue in my previous company and took 3 weeks to debug it. ASP.NET was giving a user someone else's session state. It was really impossible to duplicate in a debug environment.

The fix when we found it was just something in web.config. I don't fully remember it, so I spent some time googling. I believe the issue had something to do with output caching. Take a look at this article under "Sessions and Output Caching".

http://msdn.microsoft.com/en-us/magazine/cc163577.aspx

If that sounds like your scenario, then the fix might just be disabling the enableKernelOutputCache option in web.config.

Good luck.

Linus 2009-10-29 21:38:37

I believe you are correct! We did in fact have output caching enabled on *one* web form, and the form was the one responsible for populating our discrepent session variable. You are a saint, a scholar, a gentleman, a genius, and I can not thank you enough!!

Josh Stodola 2009-10-30 13:21:27

+1. Although Josh said only one variable was swapped, not the entire session, as pointed on your link.

wtaniguchi 2009-10-30 13:23:20

To clarify, I only have *proof* that one variable was swapped.

Josh Stodola 2009-10-30 13:28:30

Thank you for helping me determine that I'm not insane. I've been battling an issue like this for weeks and I've been stumped. I finally added enough debugging hints to my exception messages that I deduced that sessions were getting crossed over. I was thankful to find a quick answer after coming to that conclusion.

Jeff Handley 2010-09-17 05:23:55

Could the two crossed users both be using the same cacheing proxy? If so, then one user might see data that was cached for another user if the URLs matched, especially if the proxy isn't well behaved.

Wasn't this the main problem with the Google Web Accelerator project (now discontinued)?

GBegen 2009-10-29 21:57:26

ansaurus

tags:

views:

answers:

ASP.NET Session Mix-up using StateServer (SCARY!)

related questions