RE: Session Management and IP address - experiences?

["Thomas Schreiber" <ts () secure-net de>]

Let me take this response to explain the background of my question a little
further:

  > -----Original Message-----
  > From: David Wall @ Yozons, Inc. [mailto:dwall () yozons com]
  > Sent: Thursday, September 02, 2004 9:40 PM
  > To: webappsec () lists securityfocus com
  > Subject: Re: Session Management and IP address - experiences?
  >
  >
  > > It is common knowledge, that things like loadbalanced
  > proxies, where the
  > ip
  > > address might change within a running session, interfere with
  > this kind of
  > > security enhanced session management.
  >
  > It's pretty common, especially for those using the biggest ISPs who use
  > these schemes.  Most others come from a single proxy or NAT/gw so the IP
  > wouldn't change.
  >
  > > Is it perhaps exceptable, as it happens only in rare cases?
  > If this is the
  > > case, one might present the user another login where he can prove his
  > > identity again and continue with the session.
  >
  > But what ACTUAL problem are you trying to avoid?  Have you seen
  > someone step
  > in the middle of one of your users activities, steal a session
  > cookie, and
  > then impersonate them?  If not, perhaps you are solving
  > problems you don't
  > really have, so why put the headache in for those who will have issues
  > because they are being such proxies?

It is not the (seldom possible) man-in-the-middle attack. It's the
(widespread) session-hijacking issue from remote, i.e. cookie stealing and
cookie injection, referer leakage, reading the session id out of various
locations. Most of it carried out by exploiting a cross-site scripting
weakness using JavaScript. *Theoretically* binding the session id to the
client ip would mitigate this weakness (which we consider one of the
greatest weaknesses of web technology today) in reducing the risk of getting
hijacked tremendously.

But:

1. Because of loadbalanced proxies (the web entrance into the internet of
most enterprises use something like that) or changing client ips (eg. AOL,
in Germany eg. freenet) binding the ip address is not a good idea at first
sight.

2. Security gains are limited, because there are a lot of cases where the
attacker may acquire the same ip as the victim, namely if he is inside the
same company as the victim or if he uses the same dialup provider
(besides: It is sometimes argued, that ip address spoofing maybe possible.
To my understandig it is not because http won't work with spoofed ips,
except perhaps in some very exotic network environments - correct me if I'm
wrong)

But-but (now the *practice* comes into play):

to 1:
The suggested method (to let the user reauthenticate if IP address change
happens) might be a functioning practical solution. Hence the question about
real world experiences. Some answers suggest that it is a good idea, others
said, forget it! Hhm!?
Especially:
- saphyr vom Swizerland reported positive experiences with local (european?)
visitors
- Mike Randall observed something interesting with the problematic AOL-case:
"For the most part, the AOL users were flip-flopping between two or three IP
addresses, so we
had them authenticate once for each distinct IP address."
This sounds that the proposed method with a little modification - remember
all the ips the user has already authenticated for and only let him
reauthenticate if a new ip comes into play - might work, as the number of
necessery authentication is at most 2 to 3 within a session - probably  no
reauthentication necessary in most cases! That should be reasonable in most
cases, isn't it?

to 2:
Session binding to ip address is not the silver bullet but as Jeremiah said
"It makes the wall just a little bit higher". To my opinion, especially in
B2B-environments, it makes it substantially higher.

In order to anticipate another objection: Of course, the true solution to
this session hijacking problem is using client certificates - be it software
or hardare based. But this is not yet enforcable in most cases.


Thomas Schreiber
____________________________________________________________
SecureNet GmbH - http://www.securenet.de


  > > (It is another story that session-ip-binding wouldn't solve the whole
  > > problem, as there are several szenarios, where an attacker
  > might use the
  > > same proxy etc. as the victim...)
  >
  > Exactly, which also leads to the question of why bother?

Proxies and NAT environments on the client side are
  >
  > Perhaps if IPv6 ever gets into widespread use (ha ha ha?!) this will be
  > powerful because such proxies may no longer be there.  Today,
  > it seems like
  > solving a problem that perhaps doesn't exist.  Couple a good session id
  > (random and long) with SSL and you'll find most of your
  > security violations
  > result from bad passwords and social engineering attacks --
  > they are much
  > easier to hack than stepping in the middle of a session...
  >
  > David