[WEB SECURITY] IP address change: relogin

Bil Corry bil at corry.biz
Wed May 21 23:27:45 EDT 2008

Stephan Wehner wrote on 5/21/2008 3:08 PM: 
> Let's say one records, when a user logs in to a web-app, the user's
> present IP address.
> On a later request, if the user's IP address has changed, the web-app
> could ask for a re-login.

This would catch the scenario where someone's session ID was discovered and used by a hijacker behind a different IP address, but not if the hijacker sat behind the same IP address, such as a common proxy.  It would also catch legitimate users where their IP address changes frequently -- as Shaun pointed out, AOL does this:


AOL does provide the IP addresses to all of their proxies, so you could exclude AOL users from this security check.

Another method is something Ryan alluded to, which is you collect a fingerprint of the browser when the user logs in.  Basically, create a hash of various browser attributes (user-agent, screen size, etc).  This method isn't very good from the stand point that you have to collect the pieces for the hash from the browser on every page request.  In the case of sidejacking, if someone can sniff the session ID off the wire, then they can sniff everything else being sent too.  There's a blurb about device fingerprints here:


Yet another method is to rotate session IDs on every page request.  The idea here is the session ID is good for one request, then it expires and another one is issued.  This forces the hijacker to act immediately on their capture session ID, because once the user browses to the next page, the captured session ID becomes worthless.  The big issue with this method is if you have your session IDs embedded in the links instead of cookies, it breaks the back button and breaks reloading the page.  I haven't ever implemented this method, so there may be other funky behavior.

One final method that I've contemplated, but haven't had time to build a PoC, is to use HTTP Digest Authentication and use XHR to passively "authenticate" the user with the username being their session ID, and the password a random value.  Then using Digest's nonce, you can prevent replay attacks, etc.  The downside is you have to initially seed the browser with their session ID and password, which would be sent in plain-text to the browser (so the browser can use it via XHR to initiate the Digest Authentication).  Of course, if you have users that have to log in anyhow, you can just have them do so using Digest Authentication -- even if someone grabs the session ID, they won't be able to authenticate.

If there are other methods, I'd be interested in hearing about them too.

- Bil

Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn

More information about the websecurity mailing list