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

[Hope Paka]

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]

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.

 

[Phillip Ian]

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]

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.

 

[Hope Paka]

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?

 

[gerry]

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

 

[Phillip Ian]

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")

 

[Kevin Spencer]

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.

 

[Bruce Barker]

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)

 

[Marina]

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.

 

[gerry]

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

 

[Phillip Ian]

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.

 

[Damien]

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.

 

[Guest]

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.