On 2013-03-31 00:27, Stas Malyshev wrote:
Hi!
I think Stas proposes a solution to the problem and I think Anthony
proposes a viable alternative. I would say that Anthony has found the
shortest distance between the two points (the problem and the solution),
however.
The fact is that people do
On 4/1/13 3:18 PM, Stas Malyshev wrote:
Why? Making use of one parameter is orders of magnitude easier than
refactoring your whole application to not use serialize() (especially if
you need object support).
Under the RFC, unserialize could potentially create __PHP_Incomplete_Class objects
(inc
Hi!
> Yeah, well, the people who do that are also the ones that are unlikely
> to make use of the new parameters to secure themselves. In order to make
Why? Making use of one parameter is orders of magnitude easier than
refactoring your whole application to not use serialize() (especially if
you
On 31/03/13 23:18, ALeX wrote:
>> JSON and serialize() are (inherently) different serialization formats with
>> different use-cases [...]
> Yes, and json requires that all strings (including the keys) has to be
> valid utf-8, and I'm sure that's not always the case (serialize can
> use binary data
> JSON and serialize() are (inherently) different serialization formats with
> different use-cases [...]
Yes, and json requires that all strings (including the keys) has to be
valid utf-8, and I'm sure that's not always the case (serialize can
use binary data in both places).
--
PHP Internals -
I think this RFC would worsen the problem of misusing the serialize round-trip.
Even if we make the docs clearer, we'd still be sending the message that there's a new
"safer" unserialize and some would certainly use that new feature to be more lax about
guarding serialized structures.
It also
On Sun, Mar 31, 2013 at 5:27 AM, Stas Malyshev wrote:
> > I think Stas proposes a solution to the problem and I think Anthony
> > proposes a viable alternative. I would say that Anthony has found the
> > shortest distance between the two points (the problem and the solution),
> > however.
>
> The
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 d
>> And what about automatic un/serialize() of objects in $_SESSION?
>> People don't even see those function calls in their code, so dropping
>> the function/ality would be a wildly drastic move.
> Nothing about it, the change is for unserialize() function.
OK. I thought of this as one core securi
Hi!
> And what about automatic un/serialize() of objects in $_SESSION?
> People don't even see those function calls in their code, so dropping
> the function/ality would be a wildly drastic move.
Nothing about it, the change is for unserialize() function.
> tread gently, as in your suggestion of
> 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.
And what about automatic un/serialize() of objects in $_SESSION?
Hi!
> I think Stas proposes a solution to the problem and I think Anthony
> proposes a viable alternative. I would say that Anthony has found the
> shortest distance between the two points (the problem and the solution),
> however.
The fact is that people do use serialize() for data that may be
On Sat, Mar 30, 2013 at 11:05 PM, Anthony Ferrara wrote:
> Stas,
>
> Serious question: Why bother trying to clean this up? Why not just
> recommend using JSON or some other generic serialization without tieing
> into specific objects, and pushing the creation logic into userland (where
> it belong
Stas,
Serious question: Why bother trying to clean this up? Why not just
recommend using JSON or some other generic serialization without tieing
into specific objects, and pushing the creation logic into userland (where
it belongs IMHO, at least from a security perspective). At least for any
times
Hi!
As many probably know, unserialize() has a security issue following from
the fact that you can create objects with data from unserialize(), and
these object may have behavior that is invoked automatically - namely
__destruct - that can result in unintended results. See e.g.
http://heine.famili
15 matches
Mail list logo
