User attached to other user's session

[Guest]

Hi,

we're struggling with a strange session problem in an ASP.NET 2.0
application. The application is used by our customers to access
customer-related information such as invoices over the internet. Customer
have to log-in and are then identified by their customer number and some
other information stored in the session. We use the asp.net session cookie
system to keep track of the sessions. This works quite well. Unfortunately
though, we receive occasional reports that customers are able to see and open
the invoices of another customer that has recently logged-in. This happens
immediately after completing the log-in page. Interestingly, after opening an
invoice and clicking the "back" button of the browser, the correct data is
displayed and it is no longer possible to access the other user's data. We've
been investigating this issue for a while now and I can provide the following
information:

- the users use their own computer and do not share it with others
- there is no bug in the application in terms of customer identification.
Each customer has to log-in with their very own customer number and password.
- it doesn't seem to be a browser-specific issue
- there are no static members in the asp.net application
- we cannot reproduce the behavior as it seems to happen sporadically

Two more things might be interesting to mention: the asp.net-website is used
at two different locations of our overall company website. one location opens
the site in a new window, the other location uses frames. The error only
occurrs if the site is embedded in a frame.

The website uses the "SecureSessionModule" provided by msdn magazine. It's a
custom http request handler that adds some machine-specific information to
the session id in order to make it more secure. However, I dont think this
module causes the error since it does nothing special.

I guess that some browsers on some machines have problems with session
handling if the page is embedded in a frame and therefore do not send the
session cookie to the server. However, this does not explain why ASP.NET
attaches the user to another running session (instead of raising an error)
and it does also not explain why the correct session is used after clicking
the browser's "back" button. Could it be that IIS performs some output
caching or something similar which causes this error?

I would really like to solve this problem (not only by getting rid of the
frameset) so any helpful suggestions would be highly appreciated.

regards,
Benjamin

 

[bruce barker]

its a bug in your code. you probably store a reference to session data
in a vb module (or c# static), causing the data to be shared across all
requests.

-- bruce (sqlwork.com)

 

[Mark Rae]

I would really like to solve this problem (not only by getting rid of the
frameset) so any helpful suggestions would be highly appreciated.

Are you using static (Shared in VB.NET) variables anywhere...?

 

[Guest]

No.
I'm also not using any external modules and I'm not storing a reference to
the session anywhere. This is a simple asp.net application using webservices
only.

 

[Aidy]

- the users use their own computer and do not share it with others

One possibility is that this isn't true. What users say often isn't the
truth.

I guess that some browsers on some machines have problems with session
handling if the page is embedded in a frame and therefore do not send the
session cookie to the server.

I've seen this issue myself and never really got to the bottom of it. It
isn't .net related, though, IE (haven't tested in FF) seems to have an issue
dealing with cookies for sites that are imbeded, namely that it won't pass
the right domain cookie to the embeded site. Probably a "security feature".

 

[Mark Rae]

I've seen this issue myself and never really got to the bottom of it. It
isn't .net related, though, IE (haven't tested in FF) seems to have an
issue dealing with cookies for sites that are imbeded, namely that it
won't pass the right domain cookie to the embeded site. Probably a
"security feature".

Session IDs aren't guaranteed to be unique either, especially when different
users share the same computer: http://support.microsoft.com/?kbid=899918

However, I don't think this applies in this case, as the OP says that
hitting the back button sorts it...

 

[George Ter-Saakov]

Most likely you are dealing with Caching issues.

If those users behind a same proxy server then it's quite possible that
proxy cahcing your pages.

I would advice add Response.Expires = -1 for all your pages.




George.

 

[Guest]

Hi,

we're struggling with a strange session problem in an ASP.NET 2.0
application. The application is used by our customers to access
customer-related information such as invoices over the internet. Customer
have to log-in and are then identified by their customer number and some
other information stored in the session. We use the asp.net session cookie
system to keep track of the sessions. This works quite well. Unfortunately
though, we receive occasional reports that customers are able to see and open
the invoices of another customer that has recently logged-in. This happens
immediately after completing the log-in page. Interestingly, after opening an
invoice and clicking the "back" button of the browser, the correct data is
displayed and it is no longer possible to access the other user's data. We've
been investigating this issue for a while now and I can provide the following
information:

- the users use their own computer and do not share it with others
- there is no bug in the application in terms of customer identification.
Each customer has to log-in with their very own customer number and password.
- it doesn't seem to be a browser-specific issue
- there are no static members in the asp.net application
- we cannot reproduce the behavior as it seems to happen sporadically

Two more things might be interesting to mention: the asp.net-website is used
at two different locations of our overall company website. one location opens
the site in a new window, the other location uses frames. The error only
occurrs if the site is embedded in a frame.

The website uses the "SecureSessionModule" provided by msdn magazine. It's a
custom http request handler that adds some machine-specific information to
the session id in order to make it more secure. However, I dont think this
module causes the error since it does nothing special.

I guess that some browsers on some machines have problems with session
handling if the page is embedded in a frame and therefore do not send the
session cookie to the server. However, this does not explain why ASP.NET
attaches the user to another running session (instead of raising an error)
and it does also not explain why the correct session is used after clicking
the browser's "back" button. Could it be that IIS performs some output
caching or something similar which causes this error?

I would really like to solve this problem (not only by getting rid of the
frameset) so any helpful suggestions would be highly appreciated.

regards,
Benjamin

Benjamin,

either try to clean a cookies before the login is proceded (look at
the post of Mark), or try to remove the SecureSessionModule and test
if it helps. I suppose it could be a problem in that module. I had a
quick look into code of the module and see that a validation is based
on a hashed message generated from:

a) the session ID
b) the two chunks of IP address
c) the User-Agent name,
d) and a secret key from the web.config.

As we already know:

a) could be the same
b) no doubt - proxy, LAN, etc
c) no doubt
d) one for all

Hope it helps

 

[Guest]

Benjamin,

either try to clean a cookies before the login is proceded (look at
the post of Mark), or try to remove the SecureSessionModule and test
if it helps. I suppose it could be a problem in that module. I had a
quick look into code of the module and see that a validation is based
on a hashed message generated from:

a) the session ID
b) the two chunks of IP address
c) the User-Agent name,
d) and a secret key from the web.config.

As we already know:

a) could be the same
b) no doubt - proxy, LAN, etc
c) no doubt
d) one for all

Hope it helps

You are right, but don't forget: this is _additional_ data which is appended
to the session id generated by ASP.NET (which is supposed to be as unique as
possible). So even though there might be computers with the same ip chunks
and the same user agent, this has absolutely no effect on the uniqueness of
the session id. What SecureSessionModule does is: "take the id, add some more
stuff and let it go to the client". In case of a postback, it removes the
extra data, compares it with the client information and raises an exception
if it doesn't match. We use this module to minimize the risk of session
hijacking and I dont see why removing it should solve the problem. There is
just no logical reason for this if you think of the facts I mentioned earlier
(e.g: happens only in framesets, works fine after the user hit the
back-button of the browser...)

regards,
Benjamin

 

[Guest]

Just want to make it clear again: The users who reported this error had not
shared their pcs with any other users and hat not called the website from an
internet cafe or something similar. There is also no known connection
betweens these users. I can guarantee this, since we explicitly interviewed
them about their computer and internet environment in order to rule out
client-related session problems. It definitely appears to be a server issue.
I wouldn't post here if it was easy to fix, believe me.

 

[Guest]

You are right, but don't forget: this is _additional_ data which is appended
to the session id generated by ASP.NET (which is supposed to be as unique as
possible). So even though there might be computers with the same ip chunks
and the same user agent, this has absolutely no effect on the uniqueness of
the session id. What SecureSessionModule does is: "take the id, add some more
stuff and let it go to the client". In case of a postback, it removes the
extra data, compares it with the client information and raises an exception
if it doesn't match. We use this module to minimize the risk of session
hijacking and I dont see why removing it should solve the problem. There is
just no logical reason for this if you think of the facts I mentioned earlier
(e.g: happens only in framesets, works fine after the user hit the
back-button of the browser...)

Well, it's probably true (I cannot see the code and I can only guess).
As you cannot find the error you should try to check all possible
reasons and that module is the one you have to really check, I think.

Maybe you can post your code here, otherwise I have no idea.

 

[Guest]

ok, I'm gonna try. However, we don't have a proxy server and the users don't
have one either. Do you think it could be a proxy operated by the user's ISP?

 

[Guest]

I dont think I can post the code here, it's way too much

I will try removing SecureSessionModule as an "action of last ressort" as it
would be a security risk. The problem is that it can take a long time until
we know if this solved the error since it depends on whether or not customers
continue to complain about it.

 

[Guest]

I forgot to mention that the the connection is ssl-secured so a proxy can't
be the reason after all.

 

[Guest]

ok, I'm gonna try. However, we don't have a proxy server and the users don't
have one either. Do you think it could be a proxy operated by the user's ISP?

Actually, who has a problem, a users from your company (no proxy?), or
an external (internet) users?

Regarding proxy:

If you are about my post, your module uses this code

builder.Append (ip.Substring (0, ip.IndexOf ('.', ip.IndexOf ('.') +
1)));

it means it uses a part of the IP address, which can be the same for
one or many ISPs.

 

[Guest]

external internet users have the problem. but i don't really think it could
be a proxy issue since the connection is ssl encrypted.