Sec Bug->Bug #71101 [Ana]: PHP Session Data Injection Vulnerability
| From: | stas@php.net | Date: | Fri, 01 Jan 2016 02:29:39 +0000 |
| Subject: | Sec Bug->Bug #71101 [Ana]: PHP Session Data Injection Vulnerability | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-198342@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=71101&edit=1
ID: 71101
Updated by: stas@php.net
Reported by: taoguangchen at icloud dot com
Summary: PHP Session Data Injection Vulnerability
Status: Analyzed
-Type: Security
+Type: Bug
Package: Session related
Operating System: *
PHP Version: Irrelevant
Block user comment: N
Private report: Y
New Comment:
As this requires specific (and erroneous) user action to trigger, I don't think it is a
security issue. I leave it open in case somebody has any ideas of how to prevent such mistake.
Previous Comments:
------------------------------------------------------------------------
[2015-12-29 02:01:00] stas@php.net
That would be a big BC break (would break ZF code above for example) and also won't solve the
problem completely as you could have different scripts (with different settings) use the same
session.
------------------------------------------------------------------------
[2015-12-29 01:29:46] taoguangchen at icloud dot com
Maybe you can consider change session.serialize_handler to PHP_INI_PERDIR.
------------------------------------------------------------------------
[2015-12-29 01:16:48] stas@php.net
It is probably a bad idea to do this in conjunction with upload tracking feature, since it means
upload tracking will access the session with wrong handler. I do not see however what can be done
about it except telling people not to do it. Session module can not predict that somebody in the
future would change a handler and try to load session data with wrong handler.
------------------------------------------------------------------------
[2015-12-29 01:06:44] taoguangchen at icloud dot com
In fact, some frameworks or apps allow set serializer in mid-script. ex: zend framework
https://github.com/zendframework/zend-session/blob/6d5557494e3e36df1e550314a6fcfde389993333/src/Config/SessionConfig.php#L172
https://github.com/zendframework/zend-session/blob/6d5557494e3e36df1e550314a6fcfde389993333/test/Config/SessionConfigTest.php#L211
------------------------------------------------------------------------
[2015-12-29 00:45:03] stas@php.net
It looks like the problem comes from the fact that you switch serializers mid-script, which causes
php_binary unserializer to be applied to session data serialized with php serializer. This, however,
does not seem to be a security issue, as for this you need explicit action of switching the
serializers in mid-script. If you set the correct serializer in ini values, everything is fine. I
don't see how PHP could prevent you from writing session data with one serializer and then
trying to read them with another.
What we could do, maybe, is to apply the same restrictions to PHP_SESSION_UPLOAD_PROGRESS name as we
do for session ID, but I'm not sure that would even help - php_binary is a binary format and
there may be other binary formats so one could craft a string of purely ASCII symbols that have
special meaning in that format.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=71101
--
Edit this bug report at https://bugs.php.net/bug.php?id=71101&edit=1