[WEB SECURITY] tying sessions to IP addresses
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.
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.*.*) +
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
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
- a single client can change an IP address. (For example:
- 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:
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
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?
The Web Security Mailing List
The Web Security Mailing List Archives
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the websecurity