Change ASPSessionID

Discussion in 'ASP General' started by Joseph Shoe, Jul 18, 2005.

  1. Joseph Shoe

    Joseph Shoe Guest

    How do you change the ASPSessionID during a web session? I have an ASP
    application in SSL. The first screen is a login screen, which requests user
    id and password. An ASPSessionID is assigned for this page. Once the user
    is authenticated by valid id/pwd, the second page starts the real
    applicaiton. I want to change the ASPSessionID to be different from the
    first login page, which was issued to an unauthenticated user. How do I do
    that in ASP?

    Thanks.
    Joseph
    Joseph Shoe, Jul 18, 2005
    #1
    1. Advertising

  2. The sessionID is like a surrogate key, its value has no real meaning and I
    have no idea why you need them to be different.




    "Joseph Shoe" <Joseph > wrote in message
    news:...
    > How do you change the ASPSessionID during a web session? I have an ASP
    > application in SSL. The first screen is a login screen, which requests
    > user
    > id and password. An ASPSessionID is assigned for this page. Once the
    > user
    > is authenticated by valid id/pwd, the second page starts the real
    > applicaiton. I want to change the ASPSessionID to be different from the
    > first login page, which was issued to an unauthenticated user. How do I
    > do
    > that in ASP?
    >
    > Thanks.
    > Joseph
    Aaron Bertrand [SQL Server MVP], Jul 18, 2005
    #2
    1. Advertising

  3. Joseph Shoe

    Joseph Shoe Guest

    ASP maintains the same sessionID for the duration of a session, whether the
    user has passed the authentication. The sessionID can be used by someone to
    gain access to the part of a sessoin that is considered authenticated, i.e.,
    session fixation attachs.

    It is a good practice that the server changes the session ID after a user is
    sucessfully authenticated.

    "Aaron Bertrand [SQL Server MVP]" wrote:

    > The sessionID is like a surrogate key, its value has no real meaning and I
    > have no idea why you need them to be different.
    >
    >
    >
    >
    > "Joseph Shoe" <Joseph > wrote in message
    > news:...
    > > How do you change the ASPSessionID during a web session? I have an ASP
    > > application in SSL. The first screen is a login screen, which requests
    > > user
    > > id and password. An ASPSessionID is assigned for this page. Once the
    > > user
    > > is authenticated by valid id/pwd, the second page starts the real
    > > applicaiton. I want to change the ASPSessionID to be different from the
    > > first login page, which was issued to an unauthenticated user. How do I
    > > do
    > > that in ASP?
    > >
    > > Thanks.
    > > Joseph

    >
    >
    >
    Joseph Shoe, Jul 18, 2005
    #3
  4. > session fixation attachs.

    I have no idea what this is. But have you ever tried to fake out or
    impersonate a session?

    > It is a good practice that the server changes the session ID after a user
    > is
    > sucessfully authenticated.


    So the user changes to some other SessionID. Whoopty-doo. If a malicious
    user has the ability to impersonate a specific sessionID then certainly they
    would be able to impersonate an "authenticated" one.

    How and why are you relying on sessionID to allow access to certain parts of
    the application? Why not a variable like Session("authenticated")?
    Aaron Bertrand [SQL Server MVP], Jul 18, 2005
    #4
  5. > Not necessary, if the sessionID is changed for the authenticated part of
    > the session.


    Sorry, but I have been working with ASP for 10 years, and this still does
    not make any sense to me.

    > "How and why are you relying on sessionID to allow access to certain parts
    > of the application?" I don't, ASP does.


    How does ASP in and of itself know absolutely anything about different parts
    of your application?

    > I'm hoping to find an ASP function call that allows me to change the value
    > of ASPSessionID.


    Sorry, this is read only. Even if you could change it, I am still 100%
    unclear as to what you would have hoped to accomplish.
    Aaron Bertrand [SQL Server MVP], Jul 18, 2005
    #5
  6. Joseph Shoe

    Mark Schupp Guest

    I think what Aaron was saying is that if a hacker can grab the
    "unauthenticated" session id and impersonate a session then they would be
    able to grab the "authenticated" one as well. What are you doing to protect
    the "authenticated" id that you cannot do for the "unauthenticated" one?

    As far as I know, the only way that a session id changes is if the client's
    browser is closed and restarted (or if session cookies are disabled, in
    which case you have to do something else anyway).

    --
    --Mark Schupp


    "Joe Hsu" <> wrote in message
    news:vwQCe.9498$...
    > It is session fixation attacKs. Sorry for the typo.
    >
    > "If a malicious user has the ability to impersonate a specific sessionID
    > then certainly they would be able to impersonate an "authenticated" one."
    > Not necessary, if the sessionID is changed for the authenticated part of
    > the session.
    >
    > "How and why are you relying on sessionID to allow access to certain parts
    > of the application?" I don't, ASP does. I'm hoping to find an ASP
    > function call that allows me to change the value of ASPSessionID.
    >
    >
    > "Aaron Bertrand [SQL Server MVP]" <> wrote in
    > message news:...
    >>> session fixation attachs.

    >>
    >> I have no idea what this is. But have you ever tried to fake out or
    >> impersonate a session?
    >>
    >>> It is a good practice that the server changes the session ID after a
    >>> user is
    >>> sucessfully authenticated.

    >>
    >> So the user changes to some other SessionID. Whoopty-doo. If a
    >> malicious user has the ability to impersonate a specific sessionID then
    >> certainly they would be able to impersonate an "authenticated" one.
    >>
    >> How and why are you relying on sessionID to allow access to certain parts
    >> of the application? Why not a variable like Session("authenticated")?
    >>

    >
    >
    Mark Schupp, Jul 18, 2005
    #6
  7. Joseph Shoe

    Joseph Shoe Guest

    As I understand it, the ASPSessionID is used as a reference to all session
    variables maintained by ASP for each session. If anybody gains the sessionID
    from the unauthenticated screen, they will be able to use it to gain access
    to the sesion data I maintain during the subsequent authenticated session.
    BTW, it is not difficult to see the pattern of the ASPSessionID of any given
    site.

    The whitepaper in SANS on "Secure Session Mangement" has the following
    advice on page 16:
    "9. Force Server-side Session ID Creation
    The server should never assume the value of a session ID that is given
    before login. Instead the server mush create a unique session ID after the
    user successfully authenticates (a strict web application). This will foil
    session fixatin attacks."

    Again, I'm looking for any ASP API to change the SessionID. If it is not
    available, then I'll need to find other means.

    Thanks!


    "Mark Schupp" wrote:

    > I think what Aaron was saying is that if a hacker can grab the
    > "unauthenticated" session id and impersonate a session then they would be
    > able to grab the "authenticated" one as well. What are you doing to protect
    > the "authenticated" id that you cannot do for the "unauthenticated" one?
    >
    > As far as I know, the only way that a session id changes is if the client's
    > browser is closed and restarted (or if session cookies are disabled, in
    > which case you have to do something else anyway).
    >
    > --
    > --Mark Schupp
    >
    >
    > "Joe Hsu" <> wrote in message
    > news:vwQCe.9498$...
    > > It is session fixation attacKs. Sorry for the typo.
    > >
    > > "If a malicious user has the ability to impersonate a specific sessionID
    > > then certainly they would be able to impersonate an "authenticated" one."
    > > Not necessary, if the sessionID is changed for the authenticated part of
    > > the session.
    > >
    > > "How and why are you relying on sessionID to allow access to certain parts
    > > of the application?" I don't, ASP does. I'm hoping to find an ASP
    > > function call that allows me to change the value of ASPSessionID.
    > >
    > >
    > > "Aaron Bertrand [SQL Server MVP]" <> wrote in
    > > message news:...
    > >>> session fixation attachs.
    > >>
    > >> I have no idea what this is. But have you ever tried to fake out or
    > >> impersonate a session?
    > >>
    > >>> It is a good practice that the server changes the session ID after a
    > >>> user is
    > >>> sucessfully authenticated.
    > >>
    > >> So the user changes to some other SessionID. Whoopty-doo. If a
    > >> malicious user has the ability to impersonate a specific sessionID then
    > >> certainly they would be able to impersonate an "authenticated" one.
    > >>
    > >> How and why are you relying on sessionID to allow access to certain parts
    > >> of the application? Why not a variable like Session("authenticated")?
    > >>

    > >
    > >

    >
    >
    >
    Joseph Shoe, Jul 18, 2005
    #7
  8. > As I understand it, the ASPSessionID is used as a reference to all session
    > variables maintained by ASP for each session. If anybody gains the
    > sessionID
    > from the unauthenticated screen, they will be able to use it to gain
    > access
    > to the sesion data I maintain during the subsequent authenticated session.


    Can you please demonstrate either of these two parts.

    I have never seen a demonstration of guessing or sniffing a currently active
    sessionID, much less impersonating it.

    > "9. Force Server-side Session ID Creation
    > The server should never assume the value of a session ID that is given
    > before login. Instead the server mush create a unique session ID after
    > the
    > user successfully authenticates (a strict web application). This will
    > foil
    > session fixatin attacks."


    I think you're chasing the wrong squirrel up the wrong tree. I think they
    are talking about authenticating here via e.g. Windows Authentication, not
    some silly login form in your own app. Your own web application is only as
    strong as you make it.

    Do you understand the statement that changing the SessionID is not going to
    make your application any more secure?
    Aaron Bertrand [SQL Server MVP], Jul 18, 2005
    #8
  9. Joseph Shoe

    Joseph Shoe Guest

    Thank you for replies. For confidentiality, I could not reveal more than
    what I've stated so far. I'll need to look elsewhere. BTW, there is no
    "silly login form" in the application.

    "Aaron Bertrand [SQL Server MVP]" wrote:

    > > As I understand it, the ASPSessionID is used as a reference to all session
    > > variables maintained by ASP for each session. If anybody gains the
    > > sessionID
    > > from the unauthenticated screen, they will be able to use it to gain
    > > access
    > > to the sesion data I maintain during the subsequent authenticated session.

    >
    > Can you please demonstrate either of these two parts.
    >
    > I have never seen a demonstration of guessing or sniffing a currently active
    > sessionID, much less impersonating it.
    >
    > > "9. Force Server-side Session ID Creation
    > > The server should never assume the value of a session ID that is given
    > > before login. Instead the server mush create a unique session ID after
    > > the
    > > user successfully authenticates (a strict web application). This will
    > > foil
    > > session fixatin attacks."

    >
    > I think you're chasing the wrong squirrel up the wrong tree. I think they
    > are talking about authenticating here via e.g. Windows Authentication, not
    > some silly login form in your own app. Your own web application is only as
    > strong as you make it.
    >
    > Do you understand the statement that changing the SessionID is not going to
    > make your application any more secure?
    >
    >
    >
    Joseph Shoe, Jul 18, 2005
    #9
  10. Joseph Shoe

    Tim Williams Guest

    How about this scenario (multi-user PC) ?

    1. User A attempts to log in, has no valid UN/PW but is able to grab the
    value of the SessionId using (eg.) a js bookmarklet
    2. User B logs in (on the same PC, before the session has timed out) and
    begins using the application.

    Can user A now access user B's session from another PC by setting a session
    cookie to the same value they captured in Step 1 ? Seems to me that they
    they might be able to...

    --
    Tim Williams
    Palo Alto, CA


    "Aaron Bertrand [SQL Server MVP]" <> wrote in message
    news:...
    > > As I understand it, the ASPSessionID is used as a reference to all

    session
    > > variables maintained by ASP for each session. If anybody gains the
    > > sessionID
    > > from the unauthenticated screen, they will be able to use it to gain
    > > access
    > > to the sesion data I maintain during the subsequent authenticated

    session.
    >
    > Can you please demonstrate either of these two parts.
    >
    > I have never seen a demonstration of guessing or sniffing a currently

    active
    > sessionID, much less impersonating it.
    >
    > > "9. Force Server-side Session ID Creation
    > > The server should never assume the value of a session ID that is given
    > > before login. Instead the server mush create a unique session ID after
    > > the
    > > user successfully authenticates (a strict web application). This will
    > > foil
    > > session fixatin attacks."

    >
    > I think you're chasing the wrong squirrel up the wrong tree. I think they
    > are talking about authenticating here via e.g. Windows Authentication, not
    > some silly login form in your own app. Your own web application is only

    as
    > strong as you make it.
    >
    > Do you understand the statement that changing the SessionID is not going

    to
    > make your application any more secure?
    >
    >
    Tim Williams, Jul 18, 2005
    #10
  11. Joseph Shoe

    Adrienne Guest

    Gazing into my crystal ball I observed "Tim Williams" <saxifrax at
    pacbell dot net> writing in news:eEZhIN#:

    > How about this scenario (multi-user PC) ?
    >
    > 1. User A attempts to log in, has no valid UN/PW but is able to grab
    > the value of the SessionId using (eg.) a js bookmarklet
    > 2. User B logs in (on the same PC, before the session has timed out)
    > and begins using the application.
    >
    > Can user A now access user B's session from another PC by setting a
    > session cookie to the same value they captured in Step 1 ? Seems to me
    > that they they might be able to...
    >
    >


    The problem is that if someone really wants to break in, they will. And
    sometimes, things just happen. For example, there's a PC at the bank so
    you can look up your account information online. Sometimes (a lot of
    times), people forget to logout when they're done, and the bank doesn't
    automatically log you out for inactivity for 5 minutes. Someone can get
    a lot of information in 5 minutes.

    --
    Adrienne Boswell
    http://www.cavalcade-of-coding.info
    Please respond to the group so others can share
    Adrienne, Jul 19, 2005
    #11
  12. Joseph Shoe

    Tim Williams Guest

    If someone really wants to break into your car they will.
    Doesn't mean it's not worth locking your doors.

    Tim.

    --
    Tim Williams
    Palo Alto, CA


    "Adrienne" <> wrote in message
    news:Xns9697A3D31DDCFarbpenyahoocom@207.115.63.158...
    > Gazing into my crystal ball I observed "Tim Williams" <saxifrax at
    > pacbell dot net> writing in news:eEZhIN#:
    >
    > > How about this scenario (multi-user PC) ?
    > >
    > > 1. User A attempts to log in, has no valid UN/PW but is able to grab
    > > the value of the SessionId using (eg.) a js bookmarklet
    > > 2. User B logs in (on the same PC, before the session has timed out)
    > > and begins using the application.
    > >
    > > Can user A now access user B's session from another PC by setting a
    > > session cookie to the same value they captured in Step 1 ? Seems to me
    > > that they they might be able to...
    > >
    > >

    >
    > The problem is that if someone really wants to break in, they will. And
    > sometimes, things just happen. For example, there's a PC at the bank so
    > you can look up your account information online. Sometimes (a lot of
    > times), people forget to logout when they're done, and the bank doesn't
    > automatically log you out for inactivity for 5 minutes. Someone can get
    > a lot of information in 5 minutes.
    >
    > --
    > Adrienne Boswell
    > http://www.cavalcade-of-coding.info
    > Please respond to the group so others can share
    Tim Williams, Jul 19, 2005
    #12
  13. > Can user A now access user B's session from another PC by setting a
    > session
    > cookie to the same value they captured in Step 1 ?


    No, because (a) I don't think JS has the ability to read a server-side
    sessionID, even if the author of the web page would put it there, and (b)
    you can't access user B's session just by changing your cookie.
    Aaron Bertrand [SQL Server MVP], Jul 19, 2005
    #13
  14. Joseph Shoe

    Tim Williams Guest

    alert (document.cookie);

    works if I remember correctly. The cookie can be set in similar
    fashion (eg) using a js bookmarklet. Since you would then have the
    "correct" SessionId why couldn't you access the other session?

    Tim.


    "Aaron Bertrand [SQL Server MVP]" <> wrote in
    message news:...
    >> Can user A now access user B's session from another PC by setting a
    >> session
    >> cookie to the same value they captured in Step 1 ?

    >
    > No, because (a) I don't think JS has the ability to read a
    > server-side sessionID, even if the author of the web page would put
    > it there, and (b) you can't access user B's session just by changing
    > your cookie.
    >
    Tim Williams, Jul 19, 2005
    #14
  15. > works if I remember correctly. The cookie can be set in similar fashion
    > (eg) using a js bookmarklet. Since you would then have the "correct"
    > SessionId


    Well, let me know exactly how you plan to do it. See if you can set a
    session variable for a browser on one machine, get the cookie without having
    access to the ASP file(s) directly, then use another machine and fiddle with
    the cookie however you see fit, and see if you can retrieve the session
    variable on machine B that was set for the user on machine A.

    My experiments in the past have proved to me that it will not work.

    In any case, even if the above were to work, a malicious user would have to
    have access to the first user's session to get their sessionID at all, and
    if they can do that, why not just continue their session?
    Aaron Bertrand [SQL Server MVP], Jul 19, 2005
    #15
  16. Joseph Shoe

    Tim Williams Guest

    So said so done. Exactly as described.

    Opened login page on PC1, copied sessionid cookie name/value to text
    file. Then logged in on PC1 using a known UN/PW.

    Few minutes later on PC2, used an "edit cookie" bookmarklet to create
    the session cookie from PC1, and was able to bypass the login page and
    go directly to a "protected" page. This page would normally (on
    seeing there is no "logged in=yes" session variable) redirect me to
    the login page but in this case the session from PC1 is referenced due
    to the copied cookie.

    Bookmarklet for editing the session cookie was from here:
    http://visitjesper.homeip.net/bookmarklets.html

    However unlikely the scenario, it has to be admitted to be possible
    (and not that difficult either). That is the only point I'm trying to
    make here.
    Easy to prevent just by adding another session cookie on login and
    checking for both that *and* the session variable, rather than relying
    only on the session variable.

    Tim.


    "Aaron Bertrand [SQL Server MVP]" <> wrote in
    message news:...
    >> works if I remember correctly. The cookie can be set in similar
    >> fashion (eg) using a js bookmarklet. Since you would then have the
    >> "correct" SessionId

    >
    > Well, let me know exactly how you plan to do it. See if you can set
    > a session variable for a browser on one machine, get the cookie
    > without having access to the ASP file(s) directly, then use another
    > machine and fiddle with the cookie however you see fit, and see if
    > you can retrieve the session variable on machine B that was set for
    > the user on machine A.
    >
    > My experiments in the past have proved to me that it will not work.
    >
    > In any case, even if the above were to work, a malicious user would
    > have to have access to the first user's session to get their
    > sessionID at all, and if they can do that, why not just continue
    > their session?
    >
    Tim Williams, Jul 19, 2005
    #16
  17. Joseph Shoe wrote:
    > How do you change the ASPSessionID during a web session? I have an ASP
    > application in SSL. The first screen is a login screen, which requests user
    > id and password. An ASPSessionID is assigned for this page. Once the user
    > is authenticated by valid id/pwd, the second page starts the real
    > applicaiton. I want to change the ASPSessionID to be different from the
    > first login page, which was issued to an unauthenticated user. How do I do
    > that in ASP?


    Don't use ASP sessions. Instead create and maintain your own "session
    ID" passed in the querystring or in hidden field(s). Then you can change
    it wherever and whenever you wish, even with each page submission.
    Michael D. Kersey, Jul 19, 2005
    #17
  18. > However unlikely the scenario, it has to be admitted to be possible
    > (and not that difficult either). That is the only point I'm trying to
    > make here.


    I wasn't able to reproduce, but I'll take your word for it for now.

    > Easy to prevent just by adding another session cookie on login and
    > checking for both that *and* the session variable, rather than relying
    > only on the session variable.


    Which is what I suggested further up in the thread (I also still didn't get
    a decent answer to my question, what would be accomplished by changing the
    sessionID).
    Aaron Bertrand [SQL Server MVP], Jul 19, 2005
    #18
  19. Joseph Shoe

    Joseph Shoe Guest

    Thanks, Tim. Your description is mostly correct. One clarificaiton: when
    PC2 is able to get to the protected page of PC1 using the same SessionID, the
    session variable "logged in" would be yes for PC2, as seen by PC1. PC2 will
    not be redirected to the login page.

    Your suggestion of using a second session cookie is a sound one. I was
    merely looking for a shortcut. Afterall, it shouldn't be much difficult for
    ASP to provide an API to change the SessionID.

    "Tim Williams" wrote:

    > So said so done. Exactly as described.
    >
    > Opened login page on PC1, copied sessionid cookie name/value to text
    > file. Then logged in on PC1 using a known UN/PW.
    >
    > Few minutes later on PC2, used an "edit cookie" bookmarklet to create
    > the session cookie from PC1, and was able to bypass the login page and
    > go directly to a "protected" page. This page would normally (on
    > seeing there is no "logged in=yes" session variable) redirect me to
    > the login page but in this case the session from PC1 is referenced due
    > to the copied cookie.
    >
    > Bookmarklet for editing the session cookie was from here:
    > http://visitjesper.homeip.net/bookmarklets.html
    >
    > However unlikely the scenario, it has to be admitted to be possible
    > (and not that difficult either). That is the only point I'm trying to
    > make here.
    > Easy to prevent just by adding another session cookie on login and
    > checking for both that *and* the session variable, rather than relying
    > only on the session variable.
    >
    > Tim.
    >
    >
    > "Aaron Bertrand [SQL Server MVP]" <> wrote in
    > message news:...
    > >> works if I remember correctly. The cookie can be set in similar
    > >> fashion (eg) using a js bookmarklet. Since you would then have the
    > >> "correct" SessionId

    > >
    > > Well, let me know exactly how you plan to do it. See if you can set
    > > a session variable for a browser on one machine, get the cookie
    > > without having access to the ASP file(s) directly, then use another
    > > machine and fiddle with the cookie however you see fit, and see if
    > > you can retrieve the session variable on machine B that was set for
    > > the user on machine A.
    > >
    > > My experiments in the past have proved to me that it will not work.
    > >
    > > In any case, even if the above were to work, a malicious user would
    > > have to have access to the first user's session to get their
    > > sessionID at all, and if they can do that, why not just continue
    > > their session?
    > >

    >
    >
    >
    Joseph Shoe, Jul 19, 2005
    #19
  20. > Thanks, Tim. Your description is mostly correct. One clarificaiton: when
    > PC2 is able to get to the protected page of PC1 using the same SessionID,
    > the
    > session variable "logged in" would be yes for PC2, as seen by PC1.


    I am not sure I understand how you expect a user on PC2 to be able to
    install some javascript bookmarklet thing on PC1 or on your server in order
    to find out his sessionID. If the user of PC2 has access to PC1, couldn't
    he just use that access to find out the user's password (which he probably
    has in a file somewhere, or on a sticky note on his monitor) or just take
    over his session from there? There is nothing you can do in ASP to make a
    user's workstation more secure. Of course it's easy to emulate this when
    you're in control of both PC1 and PC2, as well as the web server. I don't
    think it's even remotely likely in the real world. But I can't tell you
    what to focus your energy on.
    Aaron Bertrand [SQL Server MVP], Jul 19, 2005
    #20
    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. JR
    Replies:
    2
    Views:
    1,507
  2. Chris

    ASPSessionID Location & attributes?

    Chris, Aug 18, 2005, in forum: ASP General
    Replies:
    0
    Views:
    120
    Chris
    Aug 18, 2005
  3. Replies:
    3
    Views:
    245
    Anthony Jones
    Sep 18, 2006
  4. Steve Embry
    Replies:
    1
    Views:
    406
    Anthony Jones
    Apr 5, 2007
  5. Andrew
    Replies:
    4
    Views:
    4,068
    Andrew
    Feb 15, 2010
Loading...

Share This Page