Re: Bug #13582: New Session ID's can be specified by the client.

From: Date: Sun, 07 Oct 2001 06:06:24 +0000
Subject: Re: Bug #13582: New Session ID's can be specified by the client.
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-67464@lists.php.net to get a copy of this message
I guess I'm missing something here. It is _not true_ if you have already accessed the page. Ie, you can't change the session id afterwards. If the page is accessed the _first_ time this, then is true. IMO it's the responsibility of the developer to ensure that the ID is actually valid one. There are many ways of doing this. - Markus On Sun, Oct 07, 2001 at 04:40:52AM -0000, max@blueroo.net wrote : > From: max@blueroo.net > Operating system: Both Linux & Windows > PHP version: 4.0.4pl1 > PHP Bug Type: Session related > Bug description: New Session ID's can be specified by the client. > > PHP allows a client to specify what its SID will be by passing a Cookie, > GET, or POST variable to a script, with the same session name as the script > uses. > > An example script: > > <? > session_name('id'); > session_start(); > print 'In ' . phpversion() . ', your session ID is: ' . session_id(); > ?> > > If the above script is accessed via > http://www.example.com/test.php?id=blehbleh > > This will print "In 4.0.x, your session ID is: blehbleh" > > (Tested in php 4.0.4pl1 & 4.0.6) > > After discussions with several people, we were unable to find any reason > why the client should be able to specify what its SID should be, unless a > session with that SID has been started. > > IMHO, If a session with the provided SID has not been started, the server > should generate an ID and give it to the client, instead of the accepting > the client specified SID. > > A workaround is to add the following code: > > srand ((double) microtime() * 1000000); > $new_id = md5(rand()); > session_id($new_id); > > > ...after session_name() and before session_start(), on a page that will re > initialiase/destroy a session, such as a login or logout page. > > With this workaround (and/or a fix) it is possible to create login scripts > which are more secure. ie a script that does not send plain text > passwords, and does not transmit the same encrypted details on consecutive > logins. > > Although I have provided a workaround, i thought it should be mentioned, > (or fixed within the codebase itsself) > > Please excuse me if I am missing something, and this is actually a > feature. > > Regards, > > Max Holman > > PS: I will be releasing a script to demonstrate the (more) secure login, if > you are interested, please email me (note that it requires Javascript on > the client side) > -- > Edit bug report at: http://bugs.php.net/?id=13582&edit=1 > > > -- > 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 -- Markus Fischer, http://guru.josefine.at/~mfischer/ EMail: mfischer@guru.josefine.at PGP Public Key: http://guru.josefine.at/~mfischer/C2272BD0.asc PGP Fingerprint: D3B0 DD4F E12B F911 3CE1 C2B5 D674 B445 C227 2BD0 -All your scripts are belong to Zend-

« previous php.dev (#67464) next »