Home page logo

webappsec logo WebApp Sec mailing list archives

Re: Tying a session to an IP address
From: "T.J." <tjtoocool () phreaker net>
Date: Mon, 10 May 2004 07:43:02 -0700

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:

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
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 ;-) ).

Ofer Maor
Application Defense Center Manager
Imperva(tm) Inc.

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


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?



  By Date           By Thread  

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