Is the way i do, secure enought to avoid session hijacking

Discussion in 'ASP .Net' started by Hope Paka, May 26, 2005.

  1. Hope Paka

    Hope Paka Guest

    I am storing user login information (not password) in the session. I also
    use, cookieless session. I realized that, if someone copy-pastes the URL
    after he/she logged in to the system to another person, the other person's
    browser opens as if the sender logged in.

    1) Person A Logins to the system. (login information is stored in SQL
    Session state)

    2) Person A copy-paster the url and sends it to person B (format of the
    url is http://domain/(sessionid)/XYZ.aspx)

    3) When person B opens the URL, its window opens as if person A was
    logged in to the system.

    This is a security threat. I have overcome this by doing the following.

    When user logins to the system, a login ticket is generated and
    it is stored in the session. This login ticket contains two things, one is
    client ip address, the other one is user-agent.

    Then at the each request, I validate if the registered login ticket
    information is same.

    If person A sends URL to person B, then I assumed that, person Bs ip address
    should be different than person A.

    I found an article on MSND,
    http://msdn.microsoft.com/msdnmag/issues/04/08/WickedCode/ (Foiling Session
    Hijacking Attempts). The way Jeff have done is similar to the one that i
    have done. Is this relaible. The only think i wonder is if the users IP
    address changes at each request!
    Hope Paka, May 26, 2005
    #1
    1. Advertising

  2. Hi Hope,

    Your method looks pretty sound to me. The client's IP address cannot change
    between requests. It is, after all, the "return address" for the client's
    HTTP messages.

    --
    HTH,

    Kevin Spencer
    Microsoft MVP
    ..Net Developer
    Sometimes you eat the elephant.
    Sometimes the elephant eats you.

    "Hope Paka" <> wrote in message
    news:...
    >I am storing user login information (not password) in the session. I also
    >use, cookieless session. I realized that, if someone copy-pastes the URL
    >after he/she logged in to the system to another person, the other person's
    >browser opens as if the sender logged in.
    >
    > 1) Person A Logins to the system. (login information is stored in SQL
    > Session state)
    >
    > 2) Person A copy-paster the url and sends it to person B (format of
    > the url is http://domain/(sessionid)/XYZ.aspx)
    >
    > 3) When person B opens the URL, its window opens as if person A was
    > logged in to the system.
    >
    > This is a security threat. I have overcome this by doing the following.
    >
    > When user logins to the system, a login ticket is generated and
    > it is stored in the session. This login ticket contains two things, one is
    > client ip address, the other one is user-agent.
    >
    > Then at the each request, I validate if the registered login ticket
    > information is same.
    >
    > If person A sends URL to person B, then I assumed that, person Bs ip
    > address should be different than person A.
    >
    > I found an article on MSND,
    > http://msdn.microsoft.com/msdnmag/issues/04/08/WickedCode/ (Foiling
    > Session Hijacking Attempts). The way Jeff have done is similar to the one
    > that i have done. Is this relaible. The only think i wonder is if the
    > users IP address changes at each request!
    >
    >
    Kevin Spencer, May 26, 2005
    #2
    1. Advertising

  3. Hope Paka

    Phillip Ian Guest

    Have you considered routers that do NAT? If I'm not mistaken, requests
    from different computers here on our corporate network will appear to
    come from the same IP, so if I email a link to a co-worker, they might
    end up with my session.

    Just a thought.

    -Phil
    Phillip Ian, May 26, 2005
    #3
  4. Good thinking, Phil. I hadn't considered that. Still, I believe the NAT must
    keep track of the IP address of the originating computer as well, but I'm
    starting to venture outside of my area of expertise here.

    --
    HTH,

    Kevin Spencer
    Microsoft MVP
    ..Net Developer
    Sometimes you eat the elephant.
    Sometimes the elephant eats you.

    "Phillip Ian" <> wrote in message
    news:...
    > Have you considered routers that do NAT? If I'm not mistaken, requests
    > from different computers here on our corporate network will appear to
    > come from the same IP, so if I email a link to a co-worker, they might
    > end up with my session.
    >
    > Just a thought.
    >
    > -Phil
    >
    Kevin Spencer, May 26, 2005
    #4
  5. Hope Paka

    Hope Paka Guest

    You are exactly right Philip?
    Then the only remaining part is the validation of the user-agent. But
    probably, your co-worker have a same browser and machine configuration with
    you. This is a real problem but this couldn't be only my problem. How this
    stateless word can be done more secure??
    I thought only IP and user-agents are specific to clients, are there any
    other third parameter?

    "Phillip Ian" <> wrote in message
    news:...
    > Have you considered routers that do NAT? If I'm not mistaken, requests
    > from different computers here on our corporate network will appear to
    > come from the same IP, so if I email a link to a co-worker, they might
    > end up with my session.
    >
    > Just a thought.
    >
    > -Phil
    >
    Hope Paka, May 26, 2005
    #5
  6. Hope Paka

    gerry Guest

    are you sure about that ?
    from what I have read about AOL proxies and what i see in my IIS logs - it
    seems that this is not true and that there can be multiple ip's for a single
    client within a session.
    i don't have the asp.net session id in the log files so i can't be 100%
    certain.
    Gerry



    "Kevin Spencer" <> wrote in message
    news:...
    > Hi Hope,
    >
    > Your method looks pretty sound to me. The client's IP address cannot

    change
    > between requests. It is, after all, the "return address" for the client's
    > HTTP messages.
    >
    > --
    > HTH,
    >
    > Kevin Spencer
    > Microsoft MVP
    > .Net Developer
    > Sometimes you eat the elephant.
    > Sometimes the elephant eats you.
    >
    > "Hope Paka" <> wrote in message
    > news:...
    > >I am storing user login information (not password) in the session. I also
    > >use, cookieless session. I realized that, if someone copy-pastes the URL
    > >after he/she logged in to the system to another person, the other

    person's
    > >browser opens as if the sender logged in.
    > >
    > > 1) Person A Logins to the system. (login information is stored in

    SQL
    > > Session state)
    > >
    > > 2) Person A copy-paster the url and sends it to person B (format of
    > > the url is http://domain/(sessionid)/XYZ.aspx)
    > >
    > > 3) When person B opens the URL, its window opens as if person A was
    > > logged in to the system.
    > >
    > > This is a security threat. I have overcome this by doing the following.
    > >
    > > When user logins to the system, a login ticket is generated

    and
    > > it is stored in the session. This login ticket contains two things, one

    is
    > > client ip address, the other one is user-agent.
    > >
    > > Then at the each request, I validate if the registered login ticket
    > > information is same.
    > >
    > > If person A sends URL to person B, then I assumed that, person Bs ip
    > > address should be different than person A.
    > >
    > > I found an article on MSND,
    > > http://msdn.microsoft.com/msdnmag/issues/04/08/WickedCode/ (Foiling
    > > Session Hijacking Attempts). The way Jeff have done is similar to the

    one
    > > that i have done. Is this relaible. The only think i wonder is if the
    > > users IP address changes at each request!
    > >
    > >

    >
    >
    gerry, May 26, 2005
    #6
  7. Hope Paka

    Phillip Ian Guest

    Like Kevin, I'm stepping just outside my realm of knowledge, but
    perhaps someone else can confirm this for us...

    I understand that the way NAT works is to send all the requests from
    one IP address, but using different port #s, so that it can tel that
    responses on port 6346 are really meant for the machine at IP such and
    such on port such and such.

    At the server, we must know what port we are responding to, no? Then,
    requests from two machines on the same network with the same IP will
    still have to have different ports. According to what I see, it is in
    Request.ServerVariables("REMOTE_PORT")
    Phillip Ian, May 26, 2005
    #7
  8. Within the AOL LAN, IP addresses are assigned on a per-client-session basis,
    if I'm not mistaken (at least with dial-up connections). But again, this is
    not my area of expertise. Still, I understand quite a bit about networks,
    and I can't imagine why an IP address of a machine inside a network would
    change within the same client session. It is, again, the "return address" of
    the computer on the network.

    --
    HTH,

    Kevin Spencer
    Microsoft MVP
    ..Net Developer
    Sometimes you eat the elephant.
    Sometimes the elephant eats you.

    "gerry" <> wrote in message
    news:...
    > are you sure about that ?
    > from what I have read about AOL proxies and what i see in my IIS logs - it
    > seems that this is not true and that there can be multiple ip's for a
    > single
    > client within a session.
    > i don't have the asp.net session id in the log files so i can't be 100%
    > certain.
    > Gerry
    >
    >
    >
    > "Kevin Spencer" <> wrote in message
    > news:...
    >> Hi Hope,
    >>
    >> Your method looks pretty sound to me. The client's IP address cannot

    > change
    >> between requests. It is, after all, the "return address" for the client's
    >> HTTP messages.
    >>
    >> --
    >> HTH,
    >>
    >> Kevin Spencer
    >> Microsoft MVP
    >> .Net Developer
    >> Sometimes you eat the elephant.
    >> Sometimes the elephant eats you.
    >>
    >> "Hope Paka" <> wrote in message
    >> news:...
    >> >I am storing user login information (not password) in the session. I
    >> >also
    >> >use, cookieless session. I realized that, if someone copy-pastes the URL
    >> >after he/she logged in to the system to another person, the other

    > person's
    >> >browser opens as if the sender logged in.
    >> >
    >> > 1) Person A Logins to the system. (login information is stored in

    > SQL
    >> > Session state)
    >> >
    >> > 2) Person A copy-paster the url and sends it to person B (format
    >> > of
    >> > the url is http://domain/(sessionid)/XYZ.aspx)
    >> >
    >> > 3) When person B opens the URL, its window opens as if person A
    >> > was
    >> > logged in to the system.
    >> >
    >> > This is a security threat. I have overcome this by doing the following.
    >> >
    >> > When user logins to the system, a login ticket is generated

    > and
    >> > it is stored in the session. This login ticket contains two things, one

    > is
    >> > client ip address, the other one is user-agent.
    >> >
    >> > Then at the each request, I validate if the registered login ticket
    >> > information is same.
    >> >
    >> > If person A sends URL to person B, then I assumed that, person Bs ip
    >> > address should be different than person A.
    >> >
    >> > I found an article on MSND,
    >> > http://msdn.microsoft.com/msdnmag/issues/04/08/WickedCode/ (Foiling
    >> > Session Hijacking Attempts). The way Jeff have done is similar to the

    > one
    >> > that i have done. Is this relaible. The only think i wonder is if the
    >> > users IP address changes at each request!
    >> >
    >> >

    >>
    >>

    >
    >
    Kevin Spencer, May 26, 2005
    #8
  9. Hope Paka

    Bruce Barker Guest

    when using a nat translations, there are several options:

    1) there is only one outside nat address, and every interal ipaddress use
    the same nat.
    2) there are multiple outside nat addresses, which are mapped to internal
    segments. in this case the nat adress is stable for a given internal
    ipaddress.
    3) there are a pool of outside nat address (because there are a pool of
    proxy servers) and internal ipaddress may get a different nat address on
    every request (even to the same webserver).

    with http request is one page fetch. the browser usually does a keep alive
    (http 1.1), so that images can be fetched on the same connection. but if a
    user fetches a page, waits a couple of seconds, then posts back, these are
    two separate connection, and may have different nat addresses.

    also be because most browsers support 2 concurrent connection to the same
    web site (allow two image downloads at once), one page request may have two
    nat address (really common with framesets).


    -- bruce (sqlwork.com)




    "Phillip Ian" <> wrote in message
    news:...
    > Like Kevin, I'm stepping just outside my realm of knowledge, but
    > perhaps someone else can confirm this for us...
    >
    > I understand that the way NAT works is to send all the requests from
    > one IP address, but using different port #s, so that it can tel that
    > responses on port 6346 are really meant for the machine at IP such and
    > such on port such and such.
    >
    > At the server, we must know what port we are responding to, no? Then,
    > requests from two machines on the same network with the same IP will
    > still have to have different ports. According to what I see, it is in
    > Request.ServerVariables("REMOTE_PORT")
    >
    Bruce Barker, May 26, 2005
    #9
  10. Hope Paka

    Marina Guest

    What about this:

    If you make sure that the only way users navigate from page to page is via
    posts, then you can require that all your pages send the sessionid as a post
    variable. So just check that.
    Or alternatively you can store some GUID in session, and also pass it around
    as a post variable. And then check that what got posted, is the same thing
    you are storing in session.

    The person who cut and pasted the URL, is going to be getting the URL as a
    GET, not a POST, so you will know it is someone else.

    I know it's not an ideal solution, as you have to change the mechanism of
    the way navigation takes place on your site, but I think it may work.

    "Hope Paka" <> wrote in message
    news:...
    >I am storing user login information (not password) in the session. I also
    >use, cookieless session. I realized that, if someone copy-pastes the URL
    >after he/she logged in to the system to another person, the other person's
    >browser opens as if the sender logged in.
    >
    > 1) Person A Logins to the system. (login information is stored in SQL
    > Session state)
    >
    > 2) Person A copy-paster the url and sends it to person B (format of
    > the url is http://domain/(sessionid)/XYZ.aspx)
    >
    > 3) When person B opens the URL, its window opens as if person A was
    > logged in to the system.
    >
    > This is a security threat. I have overcome this by doing the following.
    >
    > When user logins to the system, a login ticket is generated and
    > it is stored in the session. This login ticket contains two things, one is
    > client ip address, the other one is user-agent.
    >
    > Then at the each request, I validate if the registered login ticket
    > information is same.
    >
    > If person A sends URL to person B, then I assumed that, person Bs ip
    > address should be different than person A.
    >
    > I found an article on MSND,
    > http://msdn.microsoft.com/msdnmag/issues/04/08/WickedCode/ (Foiling
    > Session Hijacking Attempts). The way Jeff have done is similar to the one
    > that i have done. Is this relaible. The only think i wonder is if the
    > users IP address changes at each request!
    >
    >
    Marina, May 26, 2005
    #10
  11. Hope Paka

    gerry Guest

    AOL requests are forwarded via proxy servers - each request is 'round
    robined' through x number of proxy servers, each request in the same session
    can have a different IP because they were proxied through different servers.
    the internal ip address wouldn't change but that isn't the address that the
    web server sees - it sees the addresses of the proxy servers. same
    principle as NAT but via multiple gateways.

    here is a live example from our IIS logs files - some names have been
    changed to protect the innocent ;-) :


    2004-08-05 19:08:18 152.163.253.33 - 80 GET /valens.htm - 200
    www.oursite.com
    Mozilla/4.0+(compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1) -
    2004-08-05 19:09:05 152.163.252.101 - 80 GET /announcements.htm - 200
    www.oursite.com Mozilla/4.0+(compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1)
    http://www.oursite.com/valens.htm
    2004-08-05 19:09:07 152.163.252.194 - 80 GET
    /_derived/announcements.htm_cmp_glacier-roots010_bnr.gif - 200
    www.oursite.com Mozilla/4.0+(compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1)
    http://www.oursite.com/announcements.htm
    2004-08-05 19:09:09 152.163.253.36 - 80 GET /images/AN01249_.gif - 200
    www.oursite.com Mozilla/4.0+(compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1)
    http://www.oursite.com/announcements.htm
    2004-08-05 19:09:18 152.163.252.100 - 80 GET /family_forest.htm - 200
    www.oursite.com Mozilla/4.0+(compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1)
    http://www.oursite.com/announcements.htm
    2004-08-05 19:09:20 152.163.252.194 - 80 GET
    /_derived/family_forest.htm_cmp_glacier-roots010_bnr.gif - 200
    www.oursite.com Mozilla/4.0+(compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1)
    http://www.oursite.com/family_forest.htm
    2004-08-05 19:09:42 152.163.253.9 - 80 GET /gallery.htm - 200
    www.oursite.com Mozilla/4.0+(compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1)
    http://www.oursite.com/family_forest.htm
    2004-08-05 19:09:46 152.163.252.196 - 80 GET
    /_derived/gallery.htm_cmp_glacier-roots010_bnr.gif - 200 www.oursite.com
    Mozilla/4.0+(compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1)
    http://www.oursite.com/gallery.htm
    2004-08-05 19:09:52 152.163.253.36 - 80 GET /contacts.htm - 200
    www.oursite.com Mozilla/4.0+(compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1)
    http://www.oursite.com/gallery.htm
    2004-08-05 19:09:53 152.163.252.98 - 80 GET
    /_derived/contacts.htm_cmp_glacier-roots010_bnr.gif - 200 www.oursite.com
    Mozilla/4.0+(compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1)
    http://www.oursite.com/contacts.htm
    2004-08-05 19:10:05 152.163.253.98 - 80 GET /guest_book.htm - 200
    www.oursite.com Mozilla/4.0+(compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1)
    http://www.oursite.com/contacts.htm
    2004-08-05 19:10:08 152.163.252.104 - 80 GET
    /_derived/guest_book.htm_cmp_glacier-roots010_bnr.gif - 200 www.oursite.com
    Mozilla/4.0+(compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1)
    http://www.oursite.com/guest_book.htm
    2004-08-05 19:10:18 152.163.253.103 - 80 GET /home.htm - 200 www.oursite.com
    Mozilla/4.0+(compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1)
    http://www.oursite.com/guest_book.htm
    2004-08-05 19:10:19 152.163.252.101 - 80 GET
    /_derived/valens.htm_cmp_glacier-roots010_vbtn_a.gif - 200 www.oursite.com
    Mozilla/4.0+(compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1)
    http://www.oursite.com/
    2004-08-05 19:10:19 152.163.253.36 - 80 GET
    /_derived/home.htm_cmp_glacier-roots010_bnr.gif - 200 www.oursite.com
    Mozilla/4.0+(compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1)
    http://www.oursite.com/
    2004-08-05 19:10:19 152.163.253.103 - 80 GET
    /_derived/valens.htm_cmp_glacier-roots010_vbtn.gif - 200 www.oursite.com
    Mozilla/4.0+(compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1)
    http://www.oursite.com/
    2004-08-05 19:10:19 152.163.253.100 - 80 GET /images/j0174006.gif - 200
    www.oursite.com Mozilla/4.0+(compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1)
    http://www.oursite.com/
    2004-08-05 19:10:19 152.163.253.101 - 80 GET /images/HM00287_.gif - 200
    www.oursite.com Mozilla/4.0+(compatible;+MSIE+6.0;+AOL+9.0;+Windows+NT+5.1)
    http://www.oursite.com/
    2004-08-05 19:10:21 152.163.252.98 - 80 GET
    /_themes/glacier-roots/aglabul1.gif - 200 www.oursite.com
    Mozilla/4.0+(compatible;+MSIE+6.0;+A




    "Kevin Spencer" <> wrote in message
    news:...
    > Within the AOL LAN, IP addresses are assigned on a per-client-session

    basis,
    > if I'm not mistaken (at least with dial-up connections). But again, this

    is
    > not my area of expertise. Still, I understand quite a bit about networks,
    > and I can't imagine why an IP address of a machine inside a network would
    > change within the same client session. It is, again, the "return address"

    of
    > the computer on the network.
    >
    > --
    > HTH,
    >
    > Kevin Spencer
    > Microsoft MVP
    > .Net Developer
    > Sometimes you eat the elephant.
    > Sometimes the elephant eats you.
    >
    > "gerry" <> wrote in message
    > news:...
    > > are you sure about that ?
    > > from what I have read about AOL proxies and what i see in my IIS logs -

    it
    > > seems that this is not true and that there can be multiple ip's for a
    > > single
    > > client within a session.
    > > i don't have the asp.net session id in the log files so i can't be 100%
    > > certain.
    > > Gerry
    > >
    > >
    > >
    > > "Kevin Spencer" <> wrote in message
    > > news:...
    > >> Hi Hope,
    > >>
    > >> Your method looks pretty sound to me. The client's IP address cannot

    > > change
    > >> between requests. It is, after all, the "return address" for the

    client's
    > >> HTTP messages.
    > >>
    > >> --
    > >> HTH,
    > >>
    > >> Kevin Spencer
    > >> Microsoft MVP
    > >> .Net Developer
    > >> Sometimes you eat the elephant.
    > >> Sometimes the elephant eats you.
    > >>
    > >> "Hope Paka" <> wrote in message
    > >> news:...
    > >> >I am storing user login information (not password) in the session. I
    > >> >also
    > >> >use, cookieless session. I realized that, if someone copy-pastes the

    URL
    > >> >after he/she logged in to the system to another person, the other

    > > person's
    > >> >browser opens as if the sender logged in.
    > >> >
    > >> > 1) Person A Logins to the system. (login information is stored

    in
    > > SQL
    > >> > Session state)
    > >> >
    > >> > 2) Person A copy-paster the url and sends it to person B (format
    > >> > of
    > >> > the url is http://domain/(sessionid)/XYZ.aspx)
    > >> >
    > >> > 3) When person B opens the URL, its window opens as if person A
    > >> > was
    > >> > logged in to the system.
    > >> >
    > >> > This is a security threat. I have overcome this by doing the

    following.
    > >> >
    > >> > When user logins to the system, a login ticket is

    generated
    > > and
    > >> > it is stored in the session. This login ticket contains two things,

    one
    > > is
    > >> > client ip address, the other one is user-agent.
    > >> >
    > >> > Then at the each request, I validate if the registered login ticket
    > >> > information is same.
    > >> >
    > >> > If person A sends URL to person B, then I assumed that, person Bs ip
    > >> > address should be different than person A.
    > >> >
    > >> > I found an article on MSND,
    > >> > http://msdn.microsoft.com/msdnmag/issues/04/08/WickedCode/ (Foiling
    > >> > Session Hijacking Attempts). The way Jeff have done is similar to the

    > > one
    > >> > that i have done. Is this relaible. The only think i wonder is if the
    > >> > users IP address changes at each request!
    > >> >
    > >> >
    > >>
    > >>

    > >
    > >

    >
    >
    gerry, May 26, 2005
    #11
  12. Hope Paka

    Phillip Ian Guest

    Well, that just blows using IP address in any form right out of the
    water. :)

    Too bad they don't pass us the processor serial number or somesuch on a
    request.
    Phillip Ian, May 26, 2005
    #12
  13. Hope Paka

    Damien Guest

    Marina wrote:
    > What about this:
    >
    > If you make sure that the only way users navigate from page to page is via
    > posts, then you can require that all your pages send the sessionid as a post
    > variable. So just check that.
    > Or alternatively you can store some GUID in session, and also pass it around
    > as a post variable. And then check that what got posted, is the same thing
    > you are storing in session.
    >
    > The person who cut and pasted the URL, is going to be getting the URL as a
    > GET, not a POST, so you will know it is someone else.
    >
    > I know it's not an ideal solution, as you have to change the mechanism of
    > the way navigation takes place on your site, but I think it may work.
    >

    Nice idea. I might use that on my next website (which I'd already
    intended to force all navigation through POST anyway).

    One thing I've done on one of my sites (where I *can* track IP as well,
    due to the nature of the users :)) is to keep track, within the
    session, of which page the user is currently on. If an "impossible"
    navigation occurs (i.e. they suddenly jump to a page they cannot reach
    from the current page), then I abort the session and force them back to
    the login page. So any hijack tends to be:

    Person A is on page 3
    --hijack--
    Person B is on page 3

    now, if person A goes to page 6, any place person B goes (except to
    page 6) will abort the session. Ditto if person B happens to be the
    first to navigate. Okay, it doesn't prevent the hijack, but it detects
    it pretty quickly, unless person B is just performing exactly the same
    actions as person A.
    Damien, May 27, 2005
    #13
  14. I would summarize; you cannot rely on client IP addresses in the HTTP header
    because it is both not unique enough (NAT, Proxy Server, thousands of IPs
    funneling through one firewall) and too unique (load balanced proxy farm
    working in round robbin, multiple firewalls servicing thousands of IPs). I
    would even think you cannot rely on POST only navigation because you have to
    start somewhere and that will always be a GET. Think of users saving
    bookmarks to favorite pages. A well written application should allow a user
    to save a bookmark, then when they go to the bookmark the application should
    check login status, see that they are not logged in and send them to the
    login page then send to their bookmarked page after login. POST only
    navigation would not allow this. My question, why no cookies? It is not
    unreasonable to requires cookies, if a user wants to wear a tin foil hat and
    turn cookies off then perhaps you don't want them using your application.

    "Hope Paka" wrote:

    > I am storing user login information (not password) in the session. I also
    > use, cookieless session. I realized that, if someone copy-pastes the URL
    > after he/she logged in to the system to another person, the other person's
    > browser opens as if the sender logged in.
    >
    > 1) Person A Logins to the system. (login information is stored in SQL
    > Session state)
    >
    > 2) Person A copy-paster the url and sends it to person B (format of the
    > url is http://domain/(sessionid)/XYZ.aspx)
    >
    > 3) When person B opens the URL, its window opens as if person A was
    > logged in to the system.
    >
    > This is a security threat. I have overcome this by doing the following.
    >
    > When user logins to the system, a login ticket is generated and
    > it is stored in the session. This login ticket contains two things, one is
    > client ip address, the other one is user-agent.
    >
    > Then at the each request, I validate if the registered login ticket
    > information is same.
    >
    > If person A sends URL to person B, then I assumed that, person Bs ip address
    > should be different than person A.
    >
    > I found an article on MSND,
    > http://msdn.microsoft.com/msdnmag/issues/04/08/WickedCode/ (Foiling Session
    > Hijacking Attempts). The way Jeff have done is similar to the one that i
    > have done. Is this relaible. The only think i wonder is if the users IP
    > address changes at each request!
    >
    >
    >
    =?Utf-8?B?RG9uYWxkIFNjb3R0?=, Jul 15, 2005
    #14
    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. Christoph Schuster

    ASP.NET Error: Not enought storage is available

    Christoph Schuster, Aug 26, 2003, in forum: ASP .Net
    Replies:
    5
    Views:
    10,360
    Christoph Schuster
    Aug 27, 2003
  2. Kevin

    Session Hijacking?

    Kevin, Oct 26, 2004, in forum: ASP .Net
    Replies:
    3
    Views:
    725
    Kevin
    Oct 27, 2004
  3. Pierre Hanser
    Replies:
    1
    Views:
    338
    Chris Rebert
    Mar 22, 2009
  4. Anton

    How to avoid website hijacking?

    Anton, Sep 5, 2009, in forum: ASP .Net
    Replies:
    3
    Views:
    328
    Patrice
    Sep 5, 2009
  5. Replies:
    3
    Views:
    123
    Chris Hohmann
    Aug 20, 2003
Loading...

Share This Page