[WEB SECURITY] tying sessions to IP addresses

Bill Scott Bill.Scott at adelphia.net
Sat Jun 10 00:27:03 EDT 2006


Aren't  these address groups already known?  Specifically, if an AOL address
is used, specifically from Zone X, can't you tell that a particular address
is valid based on the address that it comes from?

Go ahead and pounce on me, I wish to cure my ignorance.

Thanks
bill
  -----Original Message-----
  From: Ryan Barnett [mailto:rcbarnett at gmail.com]
  Sent: Friday, June 09, 2006 9:46 AM
  To: Brian Eaton
  Cc: Web Security
  Subject: Re: [WEB SECURITY] tying sessions to IP addresses


  The best approach is to include some sort of a hashed cookie value that
includes; the SesisonID + Section of IP Network Block (192.168.*.*) +
User-Agent String.

  This data "should" be static for the duration of the session.  The network
block section should be enough of cursory check to catch if someone on a
totally different network is trying to use the cookie while still allowing
access to the valid user while sitting behind load-balanced proxies.
Similarly, the user-agent string should not be dynamic/changing during the
course of a session.  At least I have never seen this with my apps.  Has
anyone seen this before?  If so, what was the cause?

  If anything changes with these 3 attributes, then they need to
re-authenticate.

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

  On 6/9/06, Brian Eaton <eaton.lists at gmail.com> wrote:
    Does anyone have some experience with systems that defend against
    theft of session cookies by verifying that the IP address that uses a
    session is the same one that initiated the session?

    These are the problems with the technique that I'm aware of.

    - many clients can share a single IP address, e.g. a proxy.  (For
    example: http://webmaster.info.aol.com/proxyinfo.html)

    - a single client can change an IP address.  (For example:
    http://vegan.net/lb/archive/08-2004/0109.html )

    - a vulnerability that allows cookie theft can frequently be used for
    attacks other than cookie theft, such as forcing the victim's browser
    to perform some task directly.  (For example:
    http://www.whitehatsec.com/presentations/phishing_superbait.pdf)

    Am I leaving off any important limitations to the technique?  Are the
    limitations I've listed significant problems?

    If you're going to deal with the changing IP address problem, that
    implies some management overhead to identify and eliminate false
    positives where users are prematurely logged out because they happened
    to switch IP addresses.  How much of a problem does this management
    overhead cause?

    It seems like the HttpOnly Microsoft set-cookie extension provides
    most (though not all) of the same benefits as tying sessions to IP
    addresses, while being signficantly easier to implement and manage.
    Any thoughts on that?

    Regards.
    Brian

    ------------------------------------------------------------------------
----
    The Web Security Mailing List
    http://www.webappsec.org/lists/websecurity/

    The Web Security Mailing List Archives
    http://www.webappsec.org/lists/websecurity/archive/





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20060609/90a835da/attachment.html>


More information about the websecurity mailing list