«

We ran into a strange issue 2 days back in our client's production
environment. A remote user, logs in and finds out that the data available in
the web page are from a different user. The client environement is having
..net 3.5 running on Windows 2003 server connected to an Oracle 10g DB. The
web server is on NLB and in a DMZ. The sessions are maintained In proc.

We analysed the IIS logs and the network logs for that duration and were not
able to conclude if this was a security issue or a genuine application
related issue.

Request your inputs in solving this issue.

Benjamin Sunil wrote:
> We ran into a strange issue 2 days back in our client's production
> environment. A remote user, logs in and finds out that the data
> available in the web page are from a different user. The client
> environement is having .net 3.5 running on Windows 2003 server
> connected to an Oracle 10g DB. The web server is on NLB and in a DMZ.
> The sessions are maintained In proc.
>
> We analysed the IIS logs and the network logs for that duration and
> were not able to conclude if this was a security issue or a genuine
> application related issue.
>
> Request your inputs in solving this issue.

The problem appears to be that you're using NLB so any server could respond
to the requests, but you're using in-process session state, so each server
has its own version of that session's state. You need to have one machine
looking after the session state for all the servers.

"ASP.NET Session State"
http://msdn.microsoft.com/en-us/library/ms972429.aspx

Andrew

Andrew Morton wrote:
> "ASP.NET Session State"
> http://msdn.microsoft.com/en-us/library/ms972429.aspx

Or the current version instead of the 10-year-old one:
http://msdn.microsoft.com/en-us/library/z1hkazw7.aspx

Andrew

your application probably stores session/request info in a static
variable (or vb module) so its shared between all requests.

-- bruce (sqlwork.com)



Benjamin Sunil wrote:
> We ran into a strange issue 2 days back in our client's production
> environment. A remote user, logs in and finds out that the data available in
> the web page are from a different user. The client environement is having
> .net 3.5 running on Windows 2003 server connected to an Oracle 10g DB. The
> web server is on NLB and in a DMZ. The sessions are maintained In proc.
>
> We analysed the IIS logs and the network logs for that duration and were not
> able to conclude if this was a security issue or a genuine application
> related issue.
>
> Request your inputs in solving this issue.

Benjamin Sunil wrote:
> We ran into a strange issue 2 days back in our client's production
> environment. A remote user, logs in and finds out that the data available in
> the web page are from a different user. The client environement is having
> .net 3.5 running on Windows 2003 server connected to an Oracle 10g DB. The
> web server is on NLB and in a DMZ. The sessions are maintained In proc.
>
> We analysed the IIS logs and the network logs for that duration and were not
> able to conclude if this was a security issue or a genuine application
> related issue.
>
> Request your inputs in solving this issue.

Same application being used by two clients at about the same time. The
session variables have the same names assigned being used in both
sessions with the application. In affect, they are using the same memory.

One user does a save, and the session variables are re-populated.
However, the other user does something to cause a postback, and now, the
user has the session variables information that were populated by the
other user.

The same application used by two or more users with session variables
can step on each other's session variables in a InProc with session
state in memory.

The way you get around this is that each session variable name should
have unique name base on some type of unique user information.

As an example, if a user has a userid, that would be the uniqueness
needed to segregate the session variables between the users.

SessionVariableName + userid -- on a concatenation of
SessionVariableName + userid will make the SessionVariableName unique to
the user's session.

The session variables will not be stepped on, if you make session-names
unique to the user.

Benjamin Sunil wrote:

<snipped>

I will say that it was happening with users that had the same
application opened twice in the same session that inproc session
variables were being stepped on, and the session variables were made
unique within the same session.

I recall now what I had to do to correct it.

"Andrew Morton" wrote:

> Benjamin Sunil wrote:
> > We ran into a strange issue 2 days back in our client's production
> > environment. A remote user, logs in and finds out that the data
> > available in the web page are from a different user. The client
> > environement is having .net 3.5 running on Windows 2003 server
> > connected to an Oracle 10g DB. The web server is on NLB and in a DMZ.
> > The sessions are maintained In proc.
> >
> > We analysed the IIS logs and the network logs for that duration and
> > were not able to conclude if this was a security issue or a genuine
> > application related issue.
> >
> > Request your inputs in solving this issue.
>
> The problem appears to be that you're using NLB so any server could respond
> to the requests, but you're using in-process session state, so each server
> has its own version of that session's state. You need to have one machine
> looking after the session state for all the servers.
>
> "ASP.NET Session State"
> http://msdn.microsoft.com/en-us/library/ms972429.aspx
>
> Andrew
>
>
> .
>

Thanks much Andrew, but strangely in another client instance of the
application, where there is no NLB, we faced the same issue. As explained by
Arnold, this may be due to the same session name being used that gets
populated to another user if there are accessing the application at the same
time.

Will explore on this, meanwhile if there are any inputs please do share as
it will be helpful in solving this at the earliest.

Thanks much,
Benjamin

Benjamin Sunil wrote:
> Thanks much Andrew, but strangely in another client instance of the
> application, where there is no NLB, we faced the same issue. As
> explained by Arnold, this may be due to the same session name being
> used that gets populated to another user if there are accessing the
> application at the same time.
>
> Will explore on this, meanwhile if there are any inputs please do
> share as it will be helpful in solving this at the earliest.

On the server not using load-balancing, does it happen to have Web Garden
set to use more than one worker process for the Application Pool
(Properties->Performance tab) for that web site? That has the same effect;
using out-of-process session state is imperative in that case. Or else much
"hilarity" ensues when we're testing.

Andrew

Hi,

Unfortunately, we encountered the same issue yesterday in the client
environment. User1 gets details of User2 who had logged in earlier in the
day. We have asked the client to disable the NLB for now and monitor for
re-occurrence of this issue.

Meanwhile will try out the session related solutions as advise.

If there are any more inputs please do share.

Thanks much.

"Mr. Arnold" wrote:

> Benjamin Sunil wrote:
>
> <snipped>
>
> I will say that it was happening with users that had the same
> application opened twice in the same session that inproc session
> variables were being stepped on, and the session variables were made
> unique within the same session.
>
> I recall now what I had to do to correct it.
> .
>