Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:12591 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 37339 invoked by uid 1010); 5 Sep 2004 21:18:39 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 33323 invoked from network); 5 Sep 2004 21:15:57 -0000 Received: from unknown (HELO mproxy.gmail.com) (64.233.170.201) by pb1.pair.com with SMTP; 5 Sep 2004 21:15:57 -0000 Received: by mproxy.gmail.com with SMTP id 75so127733rnl for ; Sun, 05 Sep 2004 14:15:57 -0700 (PDT) Received: by 10.38.86.66 with SMTP id j66mr1060371rnb; Sun, 05 Sep 2004 14:15:57 -0700 (PDT) Received: by 10.38.13.33 with HTTP; Sun, 5 Sep 2004 14:15:57 -0700 (PDT) Message-ID: Date: Sun, 5 Sep 2004 23:15:57 +0200 Reply-To: Harry Fuecks To: Jason Garber Cc: internals@lists.php.net In-Reply-To: <1379406779.20040905153328@ionzoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1379406779.20040905153328@ionzoft.com> Subject: Re: [PHP-DEV] unserialize() data from untrusted source From: hfuecks@gmail.com (Harry Fuecks) On Sun, 5 Sep 2004 15:33:28 -0400, Jason Garber wrote: > 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. That's another scenario, and perhaps quite a common one, I hadn't thought of. I guess in this case, as the serialized string was originally generated by your code, you could attach a checksum with it to spot alteration but validating classes against a list would be easier. Checksums only really works though when your PHP script is doing all the serializing; not an option when a remote, untrusted, system will be doing the serializing. > If I understand you correctly, someone could alter the content of > the serialized array so that it would load a class upon > unserialization? Exactly. > If you are auto-loading classes, this might be > even worse. Good point - hadn't considered that. > > 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]) There may be an issue with returned value, come to think of it. Right now unserialize returns FALSE (plus triggers and error) if it was unable to parse the serialized string. Might be a requirement to be able to identify invalid syntax from attempts to load an invalid class (another callback or an exception?).