Sec Bug->Bug #71101 [Ana]: PHP Session Data Injection Vulnerability

From: 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

« previous php.bugs (#198342) next »