Doc #74106 [NEW]: session_regenerate_id is misleading

From: Date: Thu, 16 Feb 2017 11:23:37 +0000
Subject: Doc #74106 [NEW]: session_regenerate_id is misleading
Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-14439@lists.php.net to get a copy of this message
From: php at pointpro dot nl Operating system: PHP version: Irrelevant Package: Documentation problem Bug Type: Documentation Problem Bug description:session_regenerate_id is misleading Description: ------------ Please do correct me if I'm wrong, but it seems to me the documentation on session_regenerate_id is a bit dangerous and misleading. It states that you should take additional precautions to avoid session loss, and the example basically gives the following pattern: my_session_start * start session * if session ended in last 10 minutes, redirect to new session * if session ended longer ago, remove authentication information my_session_regenerate_id: * create new session_id * store new session_id in old session * mark current session as destroyed * start new session with new session_id What my usual use case for using session_generate_id is that a user logged in or out. A new session ID is an additional precaution against session hijacking - if an attacker somehow manage to sneak in his own session id to his victim and convinces him to log in, his own session will be logged in because it's the same. Given the pattern described in the documentation, this approach is void because even though a new session id is generated, it is stored in the old session. So if the attacker refreshes his page within 10 minutes after he convinces his victim to log in, he will be redirected to the new session, too, and still be logged in. Unless I'm missing something here, I think the documentation is actually suggesting to introduce a session hijacking vulnerability to users. While it is true that in bad network situations session loss may occur if the newly generated session ID never made it to the client, this risk does not seem worth the vulnerability introduced by work around, and at least there should be a big warning sign stating that this approach introduces other security risks. This problem could be mitigated by at least adding a check for $_SERVER['REMOTE_ADDR'] and $_SERVER['HTTP_USER_AGENT'] before redirecting to the new session. -- Edit bug report at https://bugs.php.net/bug.php?id=74106&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=74106&r=trysnapshot54 Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=74106&r=trysnapshot55 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=74106&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=74106&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=74106&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=74106&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=74106&r=needscript Try newer version: https://bugs.php.net/fix.php?id=74106&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=74106&r=support Expected behavior: https://bugs.php.net/fix.php?id=74106&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=74106&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=74106&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=74106&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=74106&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=74106&r=dst IIS Stability: https://bugs.php.net/fix.php?id=74106&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=74106&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=74106&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=74106&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=74106&r=mysqlcfg

« previous php.doc.bugs (#14439) next »