Is there a way to detect two browsers using the same session ID?

  • Thread starter Thread starter Big Daddy
  • Start date Start date
B

Big Daddy

It's possible for a user to open two different browsers that are both
using the same session ID when connecting to my ASP.NET application,
but I want to detect that condition and not allow them to do it. The
reason is that if one user logs in and minimizes their browser, and
another user walks up and logs in, both browsers are now sharing the
same session, which is bad news. Is there any way for the server to
identify a particular browser instance besides cookies? Cookies won't
work because they can be shared by multiple browsers, which is why the
session state can be shared too. Cookieless sessions could help, but
that's not an option in our context.
thanks in advance,
John
 
Big said:
It's possible for a user to open two different browsers that are both
using the same session ID when connecting to my ASP.NET application,
but I want to detect that condition and not allow them to do it. The
reason is that if one user logs in and minimizes their browser, and
another user walks up and logs in, both browsers are now sharing the
same session, which is bad news. Is there any way for the server to
identify a particular browser instance besides cookies? Cookies won't
work because they can be shared by multiple browsers, which is why the
session state can be shared too. Cookieless sessions could help, but
that's not an option in our context.
thanks in advance,
John

If you're concerned about session variables being shared by two browsers
in the same session, they can step on each other's the session variables
between the browsers, even the same browser being used more than once in
the same session.

One way to protect against this is to assign a GUID.ToString() at the
start of the application and put it in a hidden field on the page.

As you formulate a session variable name like BigDaddy. you concatenate
the hiddenfield.value to the session variable name --
BigDaddy+hiddenfield.value, which will make the session variable name
unique to the user's session.

MS indicates that a GUID will not be duplicated or used again once it
has been used.
 
If you're concerned about session variables being shared by two browsers
in the same session, they can step on each other's the session variables
between the browsers, even the same browser being used more than once in
the same session.
Multiple instances of a browser do share a common session. Sometimes
this behavior appears to get in the way. In this case it is user
behavior which gets in the way.

There is no programmatic solution for the user who walks away. In the
scenario described the minimized browser instance could be restored
and used by anyone without the need to log in. Short of educating the
users about such security issues, the best than can be done is to
minimize the window of opportunity by reducing the Session's Timeout
setting.
One way to protect against this is to assign a GUID.ToString() at the
start of the application and put it in a hidden field on the page.

As you formulate a session variable name like BigDaddy. you concatenate
the hiddenfield.value to the session variable name --
BigDaddy+hiddenfield.value, which will make the session variable name
unique to the user's session.

The idea of having multiple users share a session is not a good
practice. Ideally a new session should be created after the user logs
in and should be destroyed either when the user logs out or the
session expires.

regards
A.G.
 
Registered said:
Multiple instances of a browser do share a common session. Sometimes
this behavior appears to get in the way. In this case it is user
behavior which gets in the way.

But it's a fact that it happens, and you cannot control the user
behavior opening one or more browsers with user using the same Web UI
application in the same session.

They are going to do it, they are going to ask why can't they do it and
why did my data get clobbered just because I had the application opened
one or more time by browsers using the same application in the session.
There is no programmatic solution for the user who walks away. In the
scenario described the minimized browser instance could be restored
and used by anyone without the need to log in. Short of educating the
users about such security issues, the best than can be done is to
minimize the window of opportunity by reducing the Session's Timeout
setting.

There is the use of sticky sessions, and the user wants the data back if
the user walks away for hours there are no session variables being used
in this situation.

On the other hand, session variables are being used there is a session
timeout, but the user wants the session back intact with all session
variables restored to their original state before the timeout happened.

They want it back like the timeout never happened, which can be done
with an object state table on SQL server serializing an object or object
graph and writing an state object to the table, every time the page
unloads, which is based on a guid that was trapped on the application
start-up that is applied the the table key.

That object or object graph is not in session setting at null, then it's
get the last object state record, deserialize the object or object graph
and put the object back into session.
The idea of having multiple users share a session is not a good
practice. Ideally a new session should be created after the user logs
in and should be destroyed either when the user logs out or the
session expires.

This is not reality on some networks where the same user can have
multiple browsers opened in the same session, using the same application
and with no timeouts with stick sessions or give the illusions of
nothing has timed out.

The use of the guid per each browser session, which is held on all pages
to be applied in formulating the unique session variable name as I have
shown works for me. I don't care if they have 1,000 browsers opened in
the same session and using the same application, because each is unique
because of the guid.

However, the user must login and use a CAT card to even get on a machine
or on the network for what that is worth.
 
But it's a fact that it happens, and you cannot control the user
behavior opening one or more browsers with user using the same Web UI
application in the same session.

They are going to do it, they are going to ask why can't they do it and
why did my data get clobbered just because I had the application opened
one or more time by browsers using the same application in the session.

Yes it does happen. There can be problems with a single user and
multiple browsers pointing at the same web app. The big issue occurs
when the user logs out in one browser and expects the other browser
instances to be unaffected.
There is the use of sticky sessions, and the user wants the data back if
the user walks away for hours there are no session variables being used
in this situation.
The problem is one user leaves the browser open without signing out so
that anyone with access to the machine has access to the existing
session by either opening a new browser and pointing to the app or
using the existing browser instance.
On the other hand, session variables are being used there is a session
timeout, but the user wants the session back intact with all session
variables restored to their original state before the timeout happened.

They want it back like the timeout never happened, which can be done
with an object state table on SQL server serializing an object or object
graph and writing an state object to the table, every time the page
unloads, which is based on a guid that was trapped on the application
start-up that is applied the the table key.
If the second user uses the browser instance left open by the first
user, what protects the first user's data from being viewed or
altered?
That object or object graph is not in session setting at null, then it's
get the last object state record, deserialize the object or object graph
and put the object back into session.


This is not reality on some networks where the same user can have
multiple browsers opened in the same session, using the same application
and with no timeouts with stick sessions or give the illusions of
nothing has timed out.
Perhaps I'm misreading this but it doesn't make a lot of sense.
Multiple browser instances on a single machine pointing at a single
web application share the session. TMK the network itself has no
impact WRT a browser's inherent behavior. Session data can be
persisted when a session expires but this has nothing to do with
sticky sessions.
The use of the guid per each browser session, which is held on all pages
to be applied in formulating the unique session variable name as I have
shown works for me. I don't care if they have 1,000 browsers opened in
the same session and using the same application, because each is unique
because of the guid.
The described problem isn't with a single user and multiple browsers.
The solution you have provided assumes the second user will log in
through a new browser instance rather than just use the instance that
someone else has left open. There is no programmatic protection
against the latter.

In an environment where multiple users share the same computer it is
imperative that each individual take the necessary precautions to
protect their data from other users. Failure to do so is an invitation
for some form of malfeasance to occur.
However, the user must login and use a CAT card to even get on a machine
or on the network for what that is worth.

Security is only an illusion if the user walks away from the machine
leaving the application open and their CAT card in place.

regards
A.G.
 
Registered said:
Yes it does happen. There can be problems with a single user and
multiple browsers pointing at the same web app. The big issue occurs
when the user logs out in one browser and expects the other browser
instances to be unaffected.

The problem is one user leaves the browser open without signing out so
that anyone with access to the machine has access to the existing
session by either opening a new browser and pointing to the app or
using the existing browser instance.

If the second user uses the browser instance left open by the first
user, what protects the first user's data from being viewed or
altered?

Perhaps I'm misreading this but it doesn't make a lot of sense.
Multiple browser instances on a single machine pointing at a single
web application share the session. TMK the network itself has no
impact WRT a browser's inherent behavior. Session data can be
persisted when a session expires but this has nothing to do with
sticky sessions.

But it has everything to do with an application that uses SESSION
VARIABLES. I gave you two examples.

One was with sticky sessions that has no timeouts and is to bring back
everything if the user has left for hours or days even and came back to
that workstation logged back into the workstation and picked up and
started working in the session as if nothing never happened.

And one was given using session variables that cannot loose session
variable data if it times out, it must bring back everything intact and
he or she can be gone for hours or days, expecting to resume a session
as if nothing had happened.

There are a mixture of these application running on the front-end Web
servers using .NET and classic ASP solutions.
The described problem isn't with a single user and multiple browsers.
The solution you have provided assumes the second user will log in
through a new browser instance rather than just use the instance that
someone else has left open. There is no programmatic protection
against the latter.

They only login in onetime and that's it, and that same user can start
another browser session within the established session and no login is
needed as he or she is already logged into the workstation and the
network through the portal.

No other user comes to his or her machine and does anything on a DoD
network, that requires a individual CAT card for authentication to
access the network or access the machine. It doesn't happen.
In an environment where multiple users share the same computer it is
imperative that each individual take the necessary precautions to
protect their data from other users. Failure to do so is an invitation
for some form of malfeasance to occur.

This is a DoD network a closed network, and it doesn't happen that a
user can walk-up and use another user's workstation.

I have worked in environments large corporations where they do look for
infractions, have back doors on the machine, like a workstation, and
they are on someone like a hawk always looking for infractions.

So no in some cases, no one just gets up and walks away from that
machine without locking it out on a coffee break.
Security is only an illusion if the user walks away from the machine
leaving the application open and their CAT card in place.

It don't happen on a DoD network that has secret and top secret data
flying around on the network. They are very aware of what is going on,
very aware of the user, and the user is very aware of the ramifications
of a user not following security protocols.

I can't even leave the country on vacation without getting a security
clearance to leave the county with full travel itinerary given.

There is no illusion of security with fine, imprisonment or both.

I don't see you sitting there in the cubical next to me. <smile>
 
Back
Top