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

Discussion in 'ASP .Net' started by Big Daddy, Apr 15, 2010.

  1. Big Daddy

    Big Daddy Guest

    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 Daddy, Apr 15, 2010
    #1
    1. Advertising

  2. Big Daddy

    Mr. Arnold Guest

    Re: Is there a way to detect two browsers using the same sessionID?

    Big Daddy wrote:
    > 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.
    Mr. Arnold, Apr 15, 2010
    #2
    1. Advertising

  3. On Thu, 15 Apr 2010 00:27:39 -0400, "Mr. Arnold" <>
    wrote:

    >Big Daddy wrote:
    >> 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.
    >

    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.

    >MS indicates that a GUID will not be duplicated or used again once it
    >has been used.
    Registered User, Apr 15, 2010
    #3
  4. Big Daddy

    Mr. Arnold Guest

    Re: Is there a way to detect two browsers using the same sessionID?

    Registered User wrote:
    > On Thu, 15 Apr 2010 00:27:39 -0400, "Mr. Arnold" <>
    > wrote:
    >
    >> Big Daddy wrote:
    >>> 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.
    >>

    > 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.

    >
    >> 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.


    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.
    Mr. Arnold, Apr 15, 2010
    #4
  5. On Thu, 15 Apr 2010 14:24:57 -0400, "Mr. Arnold" <>
    wrote:

    >Registered User wrote:
    >> On Thu, 15 Apr 2010 00:27:39 -0400, "Mr. Arnold" <>
    >> wrote:
    >>
    >>> Big Daddy wrote:
    >>>> 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.
    >>>

    >> 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.


    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 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.
    >

    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.
    >
    >>
    >>> 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.

    >
    >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 User, Apr 15, 2010
    #5
  6. Big Daddy

    Mr. Arnold Guest

    Re: Is there a way to detect two browsers using the same sessionID?

    Registered User wrote:
    > On Thu, 15 Apr 2010 14:24:57 -0400, "Mr. Arnold" <>
    > wrote:
    >
    >> Registered User wrote:
    >>> On Thu, 15 Apr 2010 00:27:39 -0400, "Mr. Arnold" <>
    >>> wrote:
    >>>
    >>>> Big Daddy wrote:
    >>>>> 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.
    >>>>
    >>> 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.

    >
    > 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 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.
    >>

    > 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.
    >>
    >>>> 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.

    >> 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.


    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 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.


    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.

    >
    >> 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.
    >


    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>
    Mr. Arnold, Apr 16, 2010
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. 2pac
    Replies:
    0
    Views:
    738
  2. Replies:
    3
    Views:
    448
  3. Big Daddy
    Replies:
    1
    Views:
    380
    Mark Fitzpatrick
    Nov 22, 2006
  4. Replies:
    8
    Views:
    689
  5. El Kabong

    Browsers, browsers! Quo vadis?

    El Kabong, May 11, 2007, in forum: HTML
    Replies:
    23
    Views:
    890
    dorayme
    May 13, 2007
Loading...

Share This Page