[13656] in cryptography@c2.net mail archive
Re: Session Fixation Vulnerability in Web Based Apps
daemon@ATHENA.MIT.EDU (Pete Chown)
Tue Jun 17 07:57:45 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Tue, 17 Jun 2003 09:52:24 +0100
From: Pete Chown <Pete.Chown@skygate.co.uk>
To: cryptography@metzdowd.com
In-Reply-To: <8C9A566C643ED6119E8900A0C9DE297A32469D@saturn.aculab.com>
Jill.Ramonsky@Aculab.com wrote:
> When the user logs in, the server stores the client's IP address in a
> session variable (so it's stored at the server end - the client just gets a
> session id). Authentication of subesequent pages is assumed only if the
> client's IP address matches the IP address stored in the session variable
> corresponding to the client's session.
Unfortunately not all users have a single IP. I know AOL users, for
example, go through a cluster of proxies that all have their own IP
addresses. This means that the web server can see a different IP every
time the browser makes a request.
You might also have a problem with multi user machines. The users on
the machine would be able to take over each others' sessions, even if
they couldn't do it with outsiders.
I don't think this session ID problem is a fundamental design error,
it's just a bug in certain implementations that are out there at the
moment. If a server receives a session ID from a browser that doesn't
exist, it shouldn't simply create it. Instead it should issue a new
random session ID. This solves the problem doesn't it?
--
Pete
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
