Re: Tying a session to an IP address

["T.J." <tjtoocool () phreaker net>]

One word for you that will break all of your IP restriction hopes: AOL. 
If you don't have any users on AOL, then nevermind. But if you do, your 
users will login, only to be logged out. I learned that the funny way. 
Had a friend of mine who used AOL and didn't know much about computers 
(often the two are mutually exclusive, right? :P) help be the first to 
test one of my apps out, and he kept telling me it wasn't working. So I 
proceeded to make fun of him and tell him it was in fact working he had 
to be doing something wrong until I checked my logs. Oye. If you 
implement ip restriction our AOL users will hate you, and you will hate 
them. So, IMO, put the idea of IP restriction away until AOL goes the 
way of the dinosaur.

Imperva Application Defense Center wrote:

> Hi, 
>
> We have had experience with customers attempting to do such
> restrictions. 
> Despite the obvious security benefits, this does not prove itself as a
> solution that can be used in real world applications. 
>
> There are many cases in which IP is changing throuhgout a session, and
> while these are still not the majority of the sessions, they are a large
> enough portion to make this solution unreasonable in terms of false
> positives. 
>
> Several examples:
>
> 1. Traffic balancers (as you mentioned), that send users throuhg a
> different gateway or ISP.
> 2. Home users disconnecting their connection in the middle of work and
> reconnecting. This is especially relevant for DialUps, but disconnects
> occurs on DSL/Cable solutions as well. The user then reconnects,
> receiving a new IP from the DHCP server.
> 3. Proxies - not as common as the last two, yet some users change their
> proxy settings during a work session (due to performance issues, etc.),
> again - resulting in a none valid IP.
>
>
> What I can recommend, however, is to try and see whether you get false
> positives on this matter on your site (sometimes, the profile of the
> users surfing to you is accurate enough). This can be easily done by
> checking in the beginning of every page whether the IP matches the one
> already stored for that session (have the main page store it of course),
> and log into a file any mismatch. If the log file remains empty or very
> small, then it is likely that you do not suffer these false postivies
> (or just have a bug in your programming ;-) ). 
>
> Sincerely,
>
> Ofer Maor
> Application Defense Center Manager
> Imperva(tm) Inc.
> http://www.imperva.com/adc/
>
>
>
> -----Original Message-----
> From: Paul Johnston [mailto:paul () westpoint ltd uk] 
> Sent: Monday, May 10, 2004 3:14 PM
> To: webappsec () securityfocus com
> Subject: Tying a session to an IP address
>
>
> 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
>
>