[WEB SECURITY] tying sessions to IP addresses

Brian Eaton eaton.lists at gmail.com
Fri Jun 9 12:12:10 EDT 2006

On 6/9/06, Ryan Barnett <rcbarnett at gmail.com> wrote:
> 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?

I believe java applets will end up sending a different user-agent
string, though I haven't checked in a while.  (I've seen at least one
deployment that passed the session cookie as a parameter to an applet,
and then the applet forwarded that cookie along with HTTP requests.)
I don't think including the user-agent string makes an attacker's job
much harder, since it is so easy to determine the victim's user-agent
and adjust your own user-agent string to match.  The only tricky bit
for them would be figuring out that the web app is checking that the
user-agent hasn't changed.

Including the IP address does make the attacker's task somewhat
harder, since that requires that the attacker find a way to establish
a connection from the same or similar IP.

Offlist, I got a response from someone saying they have a setup where
they have three different IPs from different providers, all in
different net blocks.  Because of this they are unable to use a web
app that binds sessions to IP addresses.  So that's one vote for not
doing this at all.  AOL clients are also prone to shift between
completely different net blocks, particularly when switching from http
to https connections.

- Brian

The Web Security Mailing List

The Web Security Mailing List Archives

More information about the websecurity mailing list