Using only the IP address to check for Session Hijacking is prone to false positives as there are legitimate scenarios where different people may have the same IP (corporate NAT or AOL, etc...).  If you want to do detection, you should try and add in other components for correlation (such as User-Agent) as this would help to more uniquely identify the user.  The key is that you want to try and use a piece of data that would not change for the duration of the session.  The UA is pretty good for this, however, some technologies such as Java will alter it.<br>
<br>While not perfect, the best scenario is to correlate IP+UA and then alert/log if either one changes and block (or force a re-login) if they both change.  Increasing audit logging when Session Hijacking is suspected (where as perhaps the default audit log config is to only audit log an attack) is advantageous as you at least then have an audit trail of actions taken using that ID.<br>
<br>-- <br>Ryan C. Barnett<br>ModSecurity Community Manager<br>Breach Security: Director of Application Security<br>Web Application Security Consortium (WASC) Member<br>CIS Apache Benchmark Project Lead<br>SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC<br>
Author: Preventing Web Attacks with Apache<br><br><div class="gmail_quote">On Wed, May 21, 2008 at 4:08 PM, Stephan Wehner <<a href="mailto:stephanwehner@gmail.com">stephanwehner@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Let's say one records, when a user logs in to a web-app, the user's<br>
present IP address.<br>
On a later request, if the user's IP address has changed, the web-app<br>
could ask for a re-login.<br>
<br>
I'm thinking about stolen session id's through javascript-attacks. Are<br>
there arguments against such a scheme?<br>
For example, would some people run into this frequently, because of<br>
the way their ISP's DHCP is setup?<br>
On the other hand sometimes IP addresses are shared. But I guess<br>
cross-site scripting attacks "in the office" are pretty unlikely.<br>
<br>
Thanks,<br>
<br>
Stephan<br>
<br>
--<br>
Stephan Wehner<br>
<br>
-> <a href="http://stephan.sugarmotor.org" target="_blank">http://stephan.sugarmotor.org</a><br>
-> <a href="http://www.thrackle.org" target="_blank">http://www.thrackle.org</a><br>
-> <a href="http://www.buckmaster.ca" target="_blank">http://www.buckmaster.ca</a><br>
-> <a href="http://www.trafficlife.com" target="_blank">http://www.trafficlife.com</a><br>
-> <a href="http://stephansmap.org" target="_blank">http://stephansmap.org</a><br>
<br>
----------------------------------------------------------------------------<br>
Join us on IRC: <a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a> #webappsec<br>
<br>
Have a question? Search The Web Security Mailing List Archives:<br>
<a href="http://www.webappsec.org/lists/websecurity/" target="_blank">http://www.webappsec.org/lists/websecurity/</a><br>
<br>
Subscribe via RSS:<br>
<a href="http://www.webappsec.org/rss/websecurity.rss" target="_blank">http://www.webappsec.org/rss/websecurity.rss</a> [RSS Feed]<br>
<br>
Join WASC on LinkedIn<br>
<a href="http://www.linkedin.com/e/gis/83336/4B20E4374DBA" target="_blank">http://www.linkedin.com/e/gis/83336/4B20E4374DBA</a><br>
<br>
</blockquote></div><br>