Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66870
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5157AD1D.3020606@sugarcrm.com>
References: <5157A55A.1070507@sugarcrm.com>
	<CAAyV7nGtz94NaFdeQ4KL9X3_LX-dc=zbt35o=qoqd1zWGTFgaA@mail.gmail.com>
	<CAL+t6cF_pzrQtNSYMjCmxhm67QtbfhpEUiWx4xGWxAJpafrwkQ@mail.gmail.com>
	<5157AD1D.3020606@sugarcrm.com>
Date: Sun, 31 Mar 2013 08:04:50 -0400
Message-ID: <CAAyV7nFBxXRTr367DkFqrjOSedKbpCCyMEjykvsdwEMFa1oTug@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Sherif Ramadan <theanomaly.is@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b675b26b5ff0a04d9374fe2
Subject: Re: [PHP-DEV] [RFC] more secure unserialize()
From: ircmaxell@gmail.com (Anthony Ferrara)

--047d7b675b26b5ff0a04d9374fe2
Content-Type: text/plain; charset=ISO-8859-1

Stas,


The fact is that people do use serialize() for data that may be
> accessible by the user (or made accessible by unrelated security issues,
> which may be upgraded in severity by this - e.g. from SQL injection to
> persistent code backdoor on the server). There are many ways to do
> things differently, and they are known. However, as I said, the fact is
> people do use serialize() and may not even realize the data aren't as
> secure as they are. That's why many security tools flag any object with
> dtor in application using unserialize as insecure. This is not a good
> situation, and presently there are no way to avoid it except dropping
> serialize() completely - which may not be an option is some cases and in
> any case would require serious changes to the production code.
>
> This enhancement is to fix this problem. It is not to change best
> practices or give advice on how to write the most secure system - it is
> to make existing code more secure easily.


I definitely see your point, and don't disagree with it at all. Again, my
concern is that people will then be tempted to use serialization to the
client as it's "safe" (with these modifications). Which I think we should
discourage for new code....

So what if we did this: We implement your RFC, but also put a warning in
the docs that serialize() shouldn't be used in places where a user or third
party can modify the output (to use json_encode() for those areas). That
way we're not encouraging serialize to be used in places it shouldn't, but
also give those with legacy codebases or really awkward use-cases the
ability to be "more secure"...

Thoughts?

--047d7b675b26b5ff0a04d9374fe2--