note 89381 modified in function.session-set-save-handler by danbrown
| From: | danbrown@php.net | Date: | Sun, 23 Jan 2011 16:14:11 +0000 |
| Subject: | note 89381 modified in function.session-set-save-handler by danbrown | ||
| References: | 1 | Groups: | php.notes |
| Request: | Send a blank email to php-notes+get-176026@lists.php.net to get a copy of this message | ||
The "binary" data that is in the session data appears to surround class/object names, and
if you pass your session data through a function to sanitize it for SQL injection, you may indeed
run in to problems.
For example, using the PDO::quote() function to prepare the data for injection (in my case for
SQLite3), it was stopping short as soon as it encountered the first bit of binary data, causing my
session information to be corrupted.
This change *must* have happened somewhere in the 5.2 series, because I just started encountering
this problem recently on a code base that had been tested & working on earlier versions of PHP
5.2.
This may in fact be a bug - I have not yet checked... but beware, and perhaps using base64 to
encode/decode your session data is a good thing to do just to be sure (though you are now left
unable to visually inspect serialized session information at the storage level which is a rather big
problem for on-the-fly debugging of sessions).
--was--
A bit more information on what patrick at eternalspace dot com stumbled upon (and I have just now as
well)...
The "binary" data that is in the session data appears to surround class/object names, and
if you pass your session data through a function to sanitize it for SQL injection, you may indeed
run in to problems.
For example, using the PDO::quote() function to prepare the data for injection (in my case for
SQLite3), it was stopping short as soon as it encountered the first bit of binary data, causing my
session information to be corrupted.
This change *must* have happened somewhere in the 5.2 series, because I just started encountering
this problem recently on a code base that had been tested & working on earlier versions of PHP
5.2.
This may in fact be a bug - I have not yet checked... but beware, and perhaps using base64 to
encode/decode your session data is a good thing to do just to be sure (though you are now left
unable to visually inspect serialized session information at the storage level which is a rather big
problem for on-the-fly debugging of sessions).
http://php.net/manual/en/function.session-set-save-handler.php