18

We store two objects in session. Somehow, one of the objects from another user got loaded into a different user's 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 (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?

Chris
  • 2,955
  • 1
  • 30
  • 43
Josh Stodola
  • 81,538
  • 47
  • 180
  • 227
  • I've seen this, but in .Net 1.1. t was supposedly fixed in 2.0. I have some questions before I attempt to post an answer. First question, are you using cookieless session? – David Oct 29 '09 at 20:44
  • Thanks! Yes, cookieless (it says in the question). – Josh Stodola Oct 29 '09 at 20:45
  • Sorry... Didn't read that. Since using cookieless sessions means that the SessionID is included in the URL as a querystring parameter, have you verified that the SessionID querystring Parameter of the URL is different between the two users when this happens? – David Oct 29 '09 at 20:47
  • Geeze. Im sorry. It is NOT cookieless. Our sessions are powered by cookies. Damn double-negatives!!! – Josh Stodola Oct 29 '09 at 20:52
  • OK. I can't find my original references. I know that at one point a bug like this was fixed by Microsoft. I jut can't seem to find the documentation any more. It is, of course, several years out of date. – David Oct 29 '09 at 21:07
  • The whole session was exchanged, or just a few session variables? – wtaniguchi Oct 29 '09 at 21:52
  • Can you say Session Hijacking? Fairly easy to do. Are you encoding all user input? – mxmissile Oct 29 '09 at 22:02
  • Do you have any logging data available? You can't figure things out like this from the users's perspective. You need see the headers, what was sent when to which IP...etc I doubt this has anything to do with the StateServer. – rick schott Oct 29 '09 at 22:19
  • @wtanguchi Just one variable in session, not the entire session. If it matters, the variable was a .NET `Structure` with about 6 string properties. – Josh Stodola Oct 30 '09 at 13:08
  • @_rick_schott Unfortunately no. Our system administrator is effiency-crazy and he hates the idea of the IIS logs getting big. Ridiculous, I know. – Josh Stodola Oct 30 '09 at 13:09

6 Answers6

15

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://download.microsoft.com/download/3/a/7/3a7fa450-1f33-41f7-9e6d-3aa95b5a6aea/MSDNMagazineJuly2006en-us.chm (the article is titled Keep Sites Running Smoothly By Avoiding These 10 Common ASP.NET Pitfalls by Jeff Prosise in July 2006 edition of MSDN magazine)

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

Good luck.

ChrisW
  • 54,973
  • 13
  • 116
  • 224
Linus
  • 1,236
  • 1
  • 12
  • 23
  • 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 Oct 30 '09 at 13:21
  • +1. Although Josh said only one variable was swapped, not the entire session, as pointed on your link. – wtaniguchi Oct 30 '09 at 13:23
  • To clarify, I only have *proof* that one variable was swapped. – Josh Stodola Oct 30 '09 at 13:28
  • 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 Sep 17 '10 at 05:23
  • I have also ran into this issue(or a very similar one) on IIS 7.5. With a managed HTTP module, there is a [recommendation](http://blogs.iis.net/thomad/archive/2008/02/20/integrated-pipeline-and-the-kernel-mode-cache.aspx) to explicitly disable the kernel caching in the response `Response.DisableKernelCache()`. – jasper Aug 07 '13 at 18:39
  • @JoshStodola: I ran into the same issue. Could you please share your code? – Jacob Phan Jan 19 '16 at 10:41
6

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
  • 122,218
  • 32
  • 205
  • 338
  • 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 Oct 29 '09 at 20:22
  • Additionally, this app has been in production for years and we've only encountered this problem once. – Josh Stodola Oct 29 '09 at 20:24
  • +1 Every time I've seen something like what Josh is describing, that is the culprit. – kemiller2002 Oct 29 '09 at 20:24
  • 4
    "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 Oct 29 '09 at 20:25
  • 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 Oct 29 '09 at 20:31
  • "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 Oct 29 '09 at 20:56
  • 1
    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 Oct 29 '09 at 21:00
  • 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 Sep 17 '10 at 05:15
3

Possible answer - similar isue reported using cookieless session state.

session showing something wrong

Edit - Added

Another possible answer:

An ASP.NET page is stored in the HTTP.sys kernel cache in IIS 6.0 when the ASP.NET page generates an HTTP header that contains a Set-Cookie response

ChrisW
  • 54,973
  • 13
  • 116
  • 224
David
  • 72,686
  • 18
  • 132
  • 173
0

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
  • 307
  • 2
  • 4
  • 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 Oct 29 '09 at 20:36
0

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
  • 6,107
  • 3
  • 31
  • 52
0

Had this problem, turned out to be an OutputCache attribute on a partial view.

Stuart Dobson
  • 3,001
  • 4
  • 35
  • 37