Doc #74106 [NEW]: session_regenerate_id is misleading
| From: | php at pointpro dot nl | 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