Re: [WEB SECURITY] IP address change: relogin

["Ryan Barnett" <rcbarnett@xxxxxxxxx>]

------=_Part_3437_29436337.1211405977683
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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.

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.

-- 
Ryan C. Barnett
ModSecurity Community Manager
Breach Security: Director of Application Security
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache

On Wed, May 21, 2008 at 4:08 PM, Stephan Wehner <stephanwehner@gmail.com>
wrote:

> 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.
>
> I'm thinking about stolen session id's through javascript-attacks. Are
> there arguments against such a scheme?
> For example, would some people run into this frequently, because of
> the way their ISP's DHCP is setup?
> On the other hand sometimes IP addresses are shared. But I guess
> cross-site scripting attacks "in the office" are pretty unlikely.
>
> Thanks,
>
> Stephan
>
> --
> Stephan Wehner
>
> -> http://stephan.sugarmotor.org
> -> http://www.thrackle.org
> -> http://www.buckmaster.ca
> -> http://www.trafficlife.com
> -> http://stephansmap.org
>
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
>

------=_Part_3437_29436337.1211405977683
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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...).&nbsp; 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.&nbsp; The key is that you want to try and use a piece of data that would not change for the duration of the session.&nbsp; 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.&nbsp; 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 &lt;<a href="mailto:stephanwehner@gmail.com";>stephanwehner@gmail.com</a>&gt; 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&#39;s say one records, when a user logs in to a web-app, the user&#39;s<br>
present IP address.<br>
On a later request, if the user&#39;s IP address has changed, the web-app<br>
could ask for a re-login.<br>
<br>
I&#39;m thinking about stolen session id&#39;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&#39;s DHCP is setup?<br>
On the other hand sometimes IP addresses are shared. But I guess<br>
cross-site scripting attacks &quot;in the office&quot; are pretty unlikely.<br>
<br>
Thanks,<br>
<br>
Stephan<br>
<br>
--<br>
Stephan Wehner<br>
<br>
-&gt; <a href="http://stephan.sugarmotor.org"; target="_blank">http://stephan.sugarmotor.org</a><br>
-&gt; <a href="http://www.thrackle.org"; target="_blank">http://www.thrackle.org</a><br>
-&gt; <a href="http://www.buckmaster.ca"; target="_blank">http://www.buckmaster.ca</a><br>
-&gt; <a href="http://www.trafficlife.com"; target="_blank">http://www.trafficlife.com</a><br>
-&gt; <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>

------=_Part_3437_29436337.1211405977683--