Re: Bug #13582: New Session ID's can be specified by the client.
| From: | Markus Fischer | 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-