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, eventuallyyou 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
Current thread:
- Tying a session to an IP address Paul Johnston (May 10)
- Re: Tying a session to an IP address exon (May 10)
- Re: Tying a session to an IP address Rogan Dawes (May 10)
- Re: Tying a session to an IP address exon (May 10)
- Re: Tying a session to an IP address Rogan Dawes (May 10)
- Re: Tying a session to an IP address Chris Burton (May 10)
- Re: Tying a session to an IP address Imre Kertesz (May 10)
- Re: Tying a session to an IP address [summary] Paul Johnston (May 12)
- <Possible follow-ups>
- RE: Tying a session to an IP address Mike Randall (May 10)
- RE: Tying a session to an IP address Imperva Application Defense Center (May 10)
- Re: Tying a session to an IP address T.J. (May 10)
- Re: Tying a session to an IP address Adam Tuliper (May 10)
- RE: Tying a session to an IP address Steve McCullough (May 11)
- RE: Tying a session to an IP address Wolf, Yonah (May 10)
- RE: Tying a session to an IP address Scovetta, Michael V (May 10)
- Re: Tying a session to an IP address exon (May 10)
- Re: Tying a session to an IP address Mark Foster (May 10)
(Thread continues...)
- Re: Tying a session to an IP address exon (May 10)