Home page logo
/

webappsec logo WebApp Sec 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.

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



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]