tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: [Q] Session invalidation and authentication mechanism
Date Mon, 14 Aug 2000 20:30:15 GMT
Dan Kirkpatrick wrote:

> This method is still open to an attack where the attacker hijacks the
> session from a valid user.  Many servlet engines use a predictable method of
> creating the session ID, and thus one user can infer future session IDs
> based upon the session ID originally given to them.  A simple edit of their
> cookie and they have now hijacked another user's session.

A couple of notes that relate to the way Tomcat itself does this:

* As of version 3.2, the algorithm used to calculate the next session ID
  has been made *much* harder to calculate the next session ID value.
  Of course, nothing stops a snooper from swiping the session ID of a
  current session unless you are running across an encrypted connection
  (see more below on this topic).

* Since at least version 3.0, the session ID cookie is created with -1 for
  the lifetime, which means that the cookie goes away when the browser is
  closed.  Among other things, that means the browser need not (and Netscape
  and IE do not) write this cookie to their cookie files on disk.  You have to
  munge around in memory to find them.

> Another approach that should be used is that the IP address of the user
> should be stored server-side.  Future requests should check that the user IP
> address matches the address stored server-side.  If they don't match, the
> session has been hijacked.

Although this is feasible, you don't want it to be standard policy under every
circumstance.  Consider that your client might be on a system whose IP address
is assigned via DHCP, and the original lease expired since the previous
request.  There is no guarantee that the renewed lease will be for the same IP

The same kind of thing can happen behind proxies and firewalls that move
clients around via load balancing techniques, such that the next request may or
may not come from the same IP address.

> -dan

Craig McClanahan

View raw message