Also, ISPs (like AOL) who use farms of proxy caches will change a users apparent ip during a single session. (i.e. concurrent requests may come from different ips).
George
On Friday, February 1, 2002, at 11:58 AM, Rasmus Lerdorf wrote:
Bringing the user's ip into the mix is going to cause all sorts of hard to
track down problems as many many people do not have static ips. Having a
session break because their lease expires and they are assigned a new one
will confuse everyone.
As far as I am concerned this is a documentation issue.
-Rasmus
On Fri, 1 Feb 2002, Sander Roobol wrote:
[PROBLEM]
Sessions can easily be taken over by other, malicious users. All you
need is the session-id and you're done.
User who have read-access to the directory where PHP stores it's
session-data, can read the ids directly from the filenames. I don't
think many administrators are aware of the security risks involved in
storing sessions in world-readable directories (like /tmp, which is the
default by now).
As you'll understand, the possibility of taking over sessions, and that
way claiming to be somebody else, can be a serious security hazard.
There is a workaround, but IMO, PHP should be as secure as possible
without a tricky configuration.
Note: this problem is only valid for filebased sessions.
[WORKAROUND]
A workaround is to create a directory which is only readable by the
user who runs the webserver.
[PROPOSAL]
Instead of directly using the session-id, an alternate id which depends
on the session-id and possibly some client-specific data should be used
to construct a filename to store the session data.
A good option would be, IMO, creating a MD5 hash of the session-id and
some client-specific data, like his IP address. That MD5 hash will be
the alternate id used to construct the filename to store the session
data.
[ADVANTAGES]
No tricky configuration necessary to assure a safe session-setup.
[DISADVANTAGES]
There's a slight overhead involved in creating the hash to construct
the filename with the session data for each request.
Unfortunately my C skills and my knowlegde of PHP internals are by far
not supporting to implement this.
However, I would like hear any reactions on this proposal.
Sander
--
PHP Development Mailing List <
http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net
For additional commands, e-mail: php-dev-help@lists.php.net
To contact the list administrators, e-mail: php-list-
admin@lists.php.net
--
PHP Development Mailing List <
http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net
For additional commands, e-mail: php-dev-help@lists.php.net
To contact the list administrators, e-mail: php-list-admin@lists.php.net