Hello Harry,
This is an interesting point you bring up. When we have large
registration processes or similar multi-page forms, we write our
data array to a hidden field using.
base64_encode(serialize($aData))
and read it in with
unserialize(base64_decode($_POST['aData']))
passing it from page to page with POST.
If I understand you correctly, someone could alter the content of
the serialized array so that it would load a class upon
unserialization? If you are auto-loading classes, this might be
even worse.
That being the case, I would be much in favor of an optional second
array parameter to unserialize that would be a list of accepted
classes, or an empty array to that would (obviously) allow no
classes (if you were working with simple data types).
mixed unserialize ( string str[, array classes])
I'd be interested to hear other comment on this.
--
Best regards,
Jason mailto:[EMAIL PROTECTED]
Sunday, September 5, 2004, 11:29:53 AM, you wrote:
HF> Hi All,
HF> Have a situation where I want to unserialize a string received from an
HF> untrusted source over HTTP (a Javascript client in this case). For
HF> basic types this is no concern but when it comes to objects, would be
HF> nice to be able to restrict the class of object to a member of a known
HF> list, to prevent "unplanned objects" being created from classes which
HF> happened to be defined but were not intended for unserialization (such
HF> as the growing number pre-loaded classes in PHP5), and the possible
HF> security issues that might introduce.
HF> Checking the type of class once the object has been created might be
HF> too late, depending on what the constructor does. That leaves manually
HF> parsing the serialized string in PHP, before called unserialize, as
HF> the only really safe option.
HF> Could be this is outside of the scope of intended use of unserialize()
HF> but PHP's serialized representation of data makes a pretty nice
HF> encoding for exchange with other systems and I notice others doing the
HF> same e.g.;
HF> http://www.aagh.net/projects/ruby-php-serialize
HF> http://hcs.harvard.edu/~pli/code/serialPHP.pm
HF> http://www.cpan.org/modules/by-module/PHP/JBROWN/php-serialization/
HF> http://hurring.com/code/perl/serialize/
HF> Serialized data is also often used with sessions which means the usual
HF> issues with shared hosts and session files (OK - smarter users avoid
HF> this but...)
HF> Perhaps unserialize could take a second (optional) argument which is a
HF> list of allowed classes to validate against.
HF> Many thanks,
HF> Harry
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
