mailing list archives
Re: Tying a session to an IP address
From: Imre Kertesz <ikertesz () fastq com>
Date: Mon, 10 May 2004 09:17:02 -0700
The application response should depend upon the desired security level
of the application. Considering that source IP addresses do change due
to dynamic IP addressing, load balancing, etc, you have to consider the
needs of the "legitimate" users over the rare instances where some
wanker is going to share a stolen account with his buddies and go joy
riding - it all looks the same to the application but the implications
are much more devastating in the latter case.
With this in mind, you have to weigh the business requirements (ye old
usability vs. security balance) when deciding how to address this issue
- but there are options based on the level of effort you can invest in
the problem and the desired security level of the application.
1. INVALIDATE the session ID if the IP address changes. You can either
invalidate the old session when a new IP address pops up or ignore all
new session requests while there is an active session under an old IP
address. This works best in a SIPRNET environment where there is a
better chance that the user's IP address is not going to change. This is
the extreme solution and it does present usability problems involving
volatile source IP addresses.
2. DONT invalidate the session, but DO present an alert to the user that
the source IP address has changed. Ideally, instances such as these
should be logged as well and when a danger threshold has been reached
(such as 3 or more IP address changes during a predetermined time
period), the application can generate a flag event to alert an
administrator for possible malicious activity.
3. Reauthenticate - I like Mike Randall's approach and it works well for
situations where you need extra assurance that someone isn't joyriding
with a stolen account. However, this approach is very easy to bypass and
the application (and application administrator) will not be able to
distinguish a valid reauthentication with a reauthentication prompted by
a bunch of geographically separated joyriders pillaging the account.
In any event, the best thing that you can do to maintain the balance of
usability vs. security is MAINTAIN AWARENESS of a source IP address that
changes. It is more likely that a changing IP address is occurring as a
result of dynamic IP addressing and you're only going to piss off the
users if you start killing session IDs or making them reauthenticate.
However, some degree of control will give you the ability to detect
account misuse. If anything at all, implement a mechanism that will make
noise and raise flags if the source IP address changes too many times
within an active session. Most applications don't even do this and have
no way of distinguishing valid behavior from foul play.
Paul Johnston wrote:
I'm interested in the merits of restricting a session to an IP
address. I realise this isn't great security as often many users will
appear to come from the same IP address (NAT, proxies, etc.) However,
if you consider the case where an attacker uses an XSS vulnerability
to steal the session ID, then the IP address restriction raises the
bar considerably for an arbitrary remote attacker to exploit this. I'm
worried that the IP address restriction wouldn't work for all users -
e.g. if their ISP uses load-balanced web caches. Does anyone know how
common such arrangements are in practice? Perhaps something to be done
then is just check the top 16 bits of the IP address. This is likely
to work for all such network arrangements and still raises the bar a
lot for remote attacks.
Does anyone here already restrict sessions by IP address?
-· · ···- · ·-· ·--· · - ·- -··· ··- ·-· -· ·· -· --· -·· --- --·
"If you sit quietly at the edge of a river, eventually
you will see the bodies of your enemies float by"
-A maxim of patience, author unknown
PGP ID: 0xA5DD6F44