Re: Tying a session to an IP address

[Imre Kertesz <ikertesz () fastq com>]

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.

High Assurance:
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.

-I

Paul Johnston wrote:

> Hi,
>
> 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?
>
> Regards,
>
> Paul

--

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

Imre Kertesz
office:         480.722.9011
mobile:         480.363.1492
PGP ID:         0xA5DD6F44