[PHP-DEV] [off] PHP: a fractal of bad design

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Joe Gillotti — Wed, 09 May 2012 10:22:54 +0200

Nothing's stopping you from using === for integer comparison or
validating your integer string using either ctype_digit() or
is_numeric() before comparing it. (The difference between these two
functions is is_numeric() allows for decimal points)

On 05/07/2012 09:25 PM, Raymond Irving wrote:
> I was very surprised when I came across the == issue sometime ago. IMO
> strings should be compared as strings. They should never be converted to
> integer.
>
>
> 1=="1" // always convert the number value to a string and then
> compare it
> "foo" == 0 // should return false
>
> "123abc" == "123nth" // compare as string. Do not convert to numeric values
>
> "0"==0 // true
> 0=="0." // false
>
> PHP is great but if we can work together to remove the flaws, then we can
> make it even greater. We have to leave the past behind us and look at where
> we want PHP to be in the next 5 years
>
>
> Best regards,
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Sanford Whiteman — Tue, 08 May 2012 07:20:03 +0200

> At most, I'd remove the part that truncates numeric strings like
> "123abc" and always convert them to 0, because that's almost *never*
> an intended effect.

I too find it hard to think of the situation in which data must be
stored, even in a temporary form, as "123abc" but is meant to be
equivalent to 123. But it obviously has happened a bunch after all
these years.

Maybe a non-accidental example is where "123a", 123b", and "123c" are
all expected to be juggled to 123 -- i.e. the code is purposely
utilizing the PHP behavior in place of explicit truncation in order to
group certain items together. I'm 99.999% sure I've never done this,
but it would be devilishly hard to find the bugs that would come from
changing this behavior. Enough that I could see it being a major event
that tarnishes the release of PHP-dot-whatever-makes-this-change.

I also want to point out, as I did the other month when this came up,
that MySQL does autoconversion that is identical to this case [1], and
with **MP pairings so absurdly common, it makes sense to keep this
behavior in PHP for this reason alone.

-- S.

[1] SELECT '123abc' = 123 // true in MySQL (but not in all RDBMSes)

> One could argue that "123" == 123 is, however.

> On May 7, 2012, at 6:25 PM, Raymond Irving wrote:

>> I was very surprised when I came across the == issue sometime ago. IMO
>> strings should be compared as strings. They should never be converted to
>> integer.
>>
>>
>> 1=="1" // always convert the number value to a string and then
>> compare it
>> "foo" == 0 // should return false
>>
>> "123abc" == "123nth" // compare as string. Do not convert to numeric values
>>
>> "0"==0 // true
>> 0=="0." // false
>>
>> PHP is great but if we can work together to remove the flaws, then we can
>> make it even greater. We have to leave the past behind us and look at where
>> we want PHP to be in the next 5 years
>>
>>
>> Best regards,

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Matt Wilson — Tue, 08 May 2012 04:10:02 +0200

While it's not the prettiest of side effects in php, I don't agree it should be "fixed"

On top of a massive BC break, it's not as if the results are inconsistent. Learning php means learning how type juggling works.

At most, I'd remove the part that truncates numeric strings like "123abc" and always convert them to 0, because that's almost *never* an intended effect. One could argue that "123" == 123 is, however.

On May 7, 2012, at 6:25 PM, Raymond Irving wrote:

> I was very surprised when I came across the == issue sometime ago. IMO
> strings should be compared as strings. They should never be converted to
> integer.
>
>
> 1=="1" // always convert the number value to a string and then
> compare it
> "foo" == 0 // should return false
>
> "123abc" == "123nth" // compare as string. Do not convert to numeric values
>
> "0"==0 // true
> 0=="0." // false
>
> PHP is great but if we can work together to remove the flaws, then we can
> make it even greater. We have to leave the past behind us and look at where
> we want PHP to be in the next 5 years
>
>
> Best regards,

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Raymond Irving — Tue, 08 May 2012 03:30:02 +0200

I was very surprised when I came across the == issue sometime ago. IMO
strings should be compared as strings. They should never be converted to
integer.

1=="1" // always convert the number value to a string and then
compare it
"foo" == 0 // should return false

"123abc" == "123nth" // compare as string. Do not convert to numeric values

"0"==0 // true
0=="0." // false

PHP is great but if we can work together to remove the flaws, then we can
make it even greater. We have to leave the past behind us and look at where
we want PHP to be in the next 5 years

Best regards,

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Tjerk Anne Meesters — Mon, 07 May 2012 20:10:02 +0200

> On 05/07/2012 05:32 AM, Tjerk Anne Meesters wrote:
>
>> Validated or not, why would type juggling even come into the picture
>> if both variables are of the same type?
>
> For the simple reason that web forms return all input as strings, even
> if the input is actually meant to be numeric
>
> Many PHP database backend functions also return all result fields
> as strings regardless of the actual result type, e.g. mysql_fetch_*(),
> mysqli_fetch_*() and pg_fetch_*() (although that's more debatable)

Granted, I realized that my comment came across a bit too generic.
What I meant to say is that the type juggling should be applied within
its realm of usefulness and skipped otherwise lest it tell me "they're
both pretty big numbers" :)

I've always felt overly pedantic when I used === or strcmp() in string
comparisons (assuming the equality edge cases were not an issue; e.g.
same string composition).

>
> So if both operands look numeric (even though they are actually of
> type string) type juggling kicks, and in your MD5 example it
> unfortunately kicks in with a conversion to float for both sides
> and you're running into the "never compare floats for equality"
> trap ... (which is being worked on for the string comparison case
> though, i just don't have the bug number at hand right now)

I'm assuming that you're referring to this bug reference:
https://bugs.php.net/bug.php?id=54547

The proposed patch therein looks okay, though I'm not sure why the
added test case is for 64bit systems only; seems to me that it can /
should be run for other systems too.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Hartmut Holzgraefe — Mon, 07 May 2012 14:40:01 +0200

On 05/07/2012 05:32 AM, Tjerk Anne Meesters wrote:

> Validated or not, why would type juggling even come into the picture
> if both variables are of the same type?

For the simple reason that web forms return all input as strings, even
if the input is actually meant to be numeric

Many PHP database backend functions also return all result fields
as strings regardless of the actual result type, e.g. mysql_fetch_*(),
mysqli_fetch_*() and pg_fetch_*() (although that's more debatable)

So if both operands look numeric (even though they are actually of
type string) type juggling kicks, and in your MD5 example it
unfortunately kicks in with a conversion to float for both sides
and you're running into the "never compare floats for equality"
trap ... (which is being worked on for the string comparison case
though, i just don't have the bug number at hand right now)

--
hartmut

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Hartmut Holzgraefe — Mon, 07 May 2012 14:30:01 +0200

On 05/07/2012 09:28 AM, Arvids Godjuks wrote:
> Hello internals,
>
> I should voice my opinion that such things like comparing two strings
> starting with numbers and that they resolve to actual integer/float for
> comparation is bad, really bad. That just defies the logic and yealds
> absolutly unexpected results. I pride myself that i know the juggling rules
> well, but I'm shocked by this to say the least..

you have to see this in the "web context" where all input from a
HTTP client arrives as strings without type information (and some
database result data comes in as string data, too)

In that context it perfectly makes sense that

"1" == "1.0"

returns true even if both operands are strings.

"123ABF453..." == "123DFEABC..." is a different story though,
and guess what? These are *not* considered equal, at least not
by the 5.3.6 instance on the system i'm currently testing with:

$a = "123ABF453..."; //a password
$b = "123DFEABC..."; //another one
if ($a == $b){
echo "you're in";
} else {
echo "no, you don't get in *that* easy!";
}
?>

will print "no, you don't get in *that* easy!" just fine

--
hartmut

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Arvids Godjuks — Mon, 07 May 2012 12:50:02 +0200

Easy - you see == everywhere and === is used rarely, in docs you see it in
some places like strpos(). This is one thing that has to be communicated
through every channel available (including docs) with clear examples that
show why it should be used instead of ==.
Take me for example, I never had any idea that comparing two hashes that
start with numbers can generate a logical truth despite the hashes being
different. I haven't seen anything related to this in docs and never
stumbled upon in the internet, ever. So I use == for comparing strings all
the time. Now I will change that because I have the knowledge why I should
use === instead of ==.
Well, now I do know, from this mailing list (witch is for PHP development)
- not many user-land developers read this list.

And in my previous message I said essentially the same as you did, just in
different words and style. English is not my native language and I have
been learning the British variant of it, so it's more formal that
American English :)

2012/5/7 Kris Craig

>
>
> On Mon, May 7, 2012 at 12:28 AM, Arvids Godjuks wrote:
>
>> Hello internals,
>>
>> I should voice my opinion that such things like comparing two strings
>> starting with numbers and that they resolve to actual integer/float for
>> comparation is bad, really bad. That just defies the logic and yealds
>> absolutly unexpected results. I pride myself that i know the juggling
>> rules
>> well, but I'm shocked by this to say the least...
>> In my opinion this should change no matter the BC breaks it will create,
>> this one affects security big time. It's good I actually hash my passwrds
>> in the MySQL and not on the PHP side, but I have seen hash comparations
>> with == all the time. And now that this has been discussed in detail I
>> expect this to be used as an attack method grow wide.
>> 07.05.2012 5:32 пользователь "Tjerk Anne Meesters"
>> написал:
>
>
> Forgive me if I'm missing something, but why are people using == for
> security-sensitive string comparisons (like hashed passwords) in the first
> place?! If you needs something that's safe, isn't that what strcmp() and
> strcasecmp() are for? For my part, I pretty much never use == on string
> comparison, though admittedly that's probably just a matter of having
> having come from a C background before PHP.
>
> That being said, I agree that this *definitely* should be fixed if the
> examples cited are indeed accurate (I've been working with PHP for over 10
> years and I was never aware of this bizarre behavior, either). I don't
> know the history of this, but I at least would consider it to be a bug. A
> rather large one, in fact; though I think some of the fears expressed are a
> bit hyperbolic. And if you're fixing a serious bug or security
> vulnerability, as a general rule of thumb, this automatically supercedes
> any concerns regarding BC breakage IMHO. But if that really is a lingering
> concern, I'd suggest targetting the fix for PHP 6, since people would (or
> at least should) expect that some PHP 5 code may behave differently in PHP
> 6 anyway given that it's a major release
>
> --Kris
>
>

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Tjerk Anne Meesters — Mon, 07 May 2012 11:40:02 +0200

>
> I agree with Rasmus (and others) on this one
> (http://www.mail-archive.com/internals@lists.php.net/msg57949.html), type
> numeric conversion on strings on both sides should only happen if both
> strings can be represented as numbers without losing data/precision.
> if one or both of the two sides can't be converted to numeric without data
> loss, then we should compare them as strings.
> the patch from Cataphract (attached at
> https://bugs.php.net/bug.php?id=54547) implements this behavior
>

+1 ... that patch has been lying on a dusty shelf for more than a year =p

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Ferenc Kovacs — Mon, 07 May 2012 11:40:02 +0200

On Mon, May 7, 2012 at 11:22 AM, Kris Craig wrote:

> On Mon, May 7, 2012 at 1:46 AM, Gustavo Lopes > >wrote:
>
> > On Mon, 07 May 2012 10:31:00 +0200, Kris Craig
> > wrote:
> >
> > That being said, I agree that this *definitely* should be fixed if the
> >>
> >> examples cited are indeed accurate (I've been working with PHP for over
> >> 10 years and I was never aware of this bizarre behavior, either). I
> don't
> >> know the history of this, but I at least would consider it to be a bug..
> >> A rather large one, in fact; though I think some of the fears expressed
> >> are a bit hyperbolic. And if you're fixing a serious bug or security
> >> vulnerability, as a general rule of thumb, this automatically supercedes
> >> any concerns regarding BC breakage IMHO.
> >>
> >
> > This has already been discussed in its own thread, see
> > http://comments.gmane.org/**gmane.comp.php.devel/72790<;
> http://comments.gmane.org/gmane.comp.php.devel/72790>;; see also
> > https://bugs.php.net/bug.php?**id=54547<;
> https://bugs.php.net/bug.php?id=54547>;
> >
> > Doing away entirely with this behavior (e.g. making " 2" == "2" compare
> > false) would be a rather large BC break, that discussion is restricted to
> > whether integers in strings should be treated differently from integer
> > literals for comparison purposes when their range is exceeded. I wrote a
> > patch for that, and, while not really caring one way or the other, I'm
> not
> > convinced it's necessary and I some have consistency concerns (though
> float
> > overflows already get a similar treatment).
> >
> > --
> > Gustavo Lopes
> >
>
> Agreed. While it's no secret that I believe optional strong typing would
> be helpful in this context, setting that aside I would definitely not want
> to see implicit conversions like "2" == 2 or even " 2" == 2 go away (though
> I do wish more PHP devs were familiar with the various trim() functions
> lol).
>
> That being said, this is what had me scratching my head from a previous
> message in this thread:
>
> >$a = "123ABF453..."; //a password
> >$b = "123DFEABC..."; //another one
> >if ($a == $b){
> > //you're in.
> >}
>
>
> The thought that $a == $b would actually evaluate to TRUE is utterly
> absurd.... Only catch is, it doesn't. As I was sharpening my pitchfork
> getting ready to argue why this should be considered a bug and not
> conflated with implicit conversions like " 2" == 2, I decided to do a
> little test script against 5.3.11. I was unable to reproduce the behavior
> being reported in the above example. In my tests, $a == $b returned FALSE.
> As it should.
>
>
juggling won't happen here, because both sides are strings, and they aren't
numerical strings, so that example was bogus indeed.
the discussion here is about whether it is not expected that the numerical
strings will compared as numbers even in they can only represented as
number if some kind of precision loss occurs.
about numerical strings:
http://php.net/manual/en/language.operators.comparison.php
"If you compare a number with a string or the comparison involves numerical
strings, then each string is converted to a
number<http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion>;
and
the comparison performed numerically. These rules also apply to the
switchhttp://www.php.net/manual/en/control-structures.switch.php
statement.
The type conversion does not take place when the comparison is === or !==
as this involves comparing the type as well as the value."

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Kris Craig — Mon, 07 May 2012 11:30:02 +0200

On Mon, May 7, 2012 at 1:46 AM, Gustavo Lopes wrote:

> On Mon, 07 May 2012 10:31:00 +0200, Kris Craig
> wrote:
>
> That being said, I agree that this *definitely* should be fixed if the
>>
>> examples cited are indeed accurate (I've been working with PHP for over
>> 10 years and I was never aware of this bizarre behavior, either). I don't
>> know the history of this, but I at least would consider it to be a bug.
>> A rather large one, in fact; though I think some of the fears expressed
>> are a bit hyperbolic. And if you're fixing a serious bug or security
>> vulnerability, as a general rule of thumb, this automatically supercedes
>> any concerns regarding BC breakage IMHO.
>>
>
> This has already been discussed in its own thread, see
> http://comments.gmane.org/**gmane.comp.php.devel/72790http://comments.gmane.org/gmane.comp.php.devel/72790; see also
> https://bugs.php.net/bug.php?**id=54547https://bugs.php.net/bug.php?id=54547
>
> Doing away entirely with this behavior (e.g. making " 2" == "2" compare
> false) would be a rather large BC break, that discussion is restricted to
> whether integers in strings should be treated differently from integer
> literals for comparison purposes when their range is exceeded. I wrote a
> patch for that, and, while not really caring one way or the other, I'm not
> convinced it's necessary and I some have consistency concerns (though float
> overflows already get a similar treatment).
>
> --
> Gustavo Lopes
>

Agreed. While it's no secret that I believe optional strong typing would
be helpful in this context, setting that aside I would definitely not want
to see implicit conversions like "2" == 2 or even " 2" == 2 go away (though
I do wish more PHP devs were familiar with the various trim() functions
lol).

That being said, this is what had me scratching my head from a previous
message in this thread:

>$a = "123ABF453..."; //a password
>$b = "123DFEABC..."; //another one
>if ($a == $b){
> //you're in.
>}

The thought that $a == $b would actually evaluate to TRUE is utterly
absurd.... Only catch is, it doesn't. As I was sharpening my pitchfork
getting ready to argue why this should be considered a bug and not
conflated with implicit conversions like " 2" == 2, I decided to do a
little test script against 5.3.11. I was unable to reproduce the behavior
being reported in the above example. In my tests, $a == $b returned FALSE.
As it should.

@Richard Could you clarify what you were trying to illustrate with that
code? I wasn't able to find anything wrong with how PHP handled it. So
either you were mistaken or I misunderstood your point (if the latter,
please tell me how so I can try again to repro the problem you're raising
concern about).

So with that in mind, the point I raised in the second paragraph of my last
email is moot because I was referring to behavior that doesn't actually
exist (again, unless I was testing for the wrong thing somehow?). Implicit
conversions like " 1" == 1.0 I fully support so long as they can both be
converted to numbers without loss of precision.

--Kris

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Ferenc Kovacs — Mon, 07 May 2012 11:00:03 +0200

On Mon, May 7, 2012 at 10:31 AM, Kris Craig wrote:

> On Mon, May 7, 2012 at 12:28 AM, Arvids Godjuks > >wrote:
>
> > Hello internals,
> >
> > I should voice my opinion that such things like comparing two strings
> > starting with numbers and that they resolve to actual integer/float for
> > comparation is bad, really bad. That just defies the logic and yealds
> > absolutly unexpected results. I pride myself that i know the juggling
> rules
> > well, but I'm shocked by this to say the least...
> > In my opinion this should change no matter the BC breaks it will create,
> > this one affects security big time. It's good I actually hash my
> passwords
> > in the MySQL and not on the PHP side, but I have seen hash comparations
> > with == all the time. And now that this has been discussed in detail I
> > expect this to be used as an attack method grow wide.
> > 07.05.2012 5:32 пользователь "Tjerk Anne Meesters"
> > написал:
>
>
> Forgive me if I'm missing something, but why are people using == for
> security-sensitive string comparisons (like hashed passwords) in the first
> place?! If you needs something that's safe, isn't that what strcmp() and
> strcasecmp() are for? For my part, I pretty much never use == on string
> comparison, though admittedly that's probably just a matter of having
> having come from a C background before PHP.
>
> That being said, I agree that this *definitely* should be fixed if the
> examples cited are indeed accurate (I've been working with PHP for over 10
> years and I was never aware of this bizarre behavior, either). I don't
> know the history of this, but I at least would consider it to be a bug. A
> rather large one, in fact; though I think some of the fears expressed are a
> bit hyperbolic. And if you're fixing a serious bug or security
> vulnerability, as a general rule of thumb, this automatically supercedes
> any concerns regarding BC breakage IMHO. But if that really is a lingering
> concern, I'd suggest targetting the fix for PHP 6, since people would (or
> at least should) expect that some PHP 5 code may behave differently in PHP
> 6 anyway given that it's a major release
>
>
I agree with Rasmus (and others) on this one (
http://www.mail-archive.com/internals@lists.php.net/msg57949.html), type
numeric conversion on strings on both sides should only happen if both
strings can be represented as numbers without losing data/precision.
if one or both of the two sides can't be converted to numeric without data
loss, then we should compare them as strings.
the patch from Cataphract (attached at https://bugs.php.net/bug.php?id=54547)
implements this behavior

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Gustavo Lopes — Mon, 07 May 2012 10:50:02 +0200

On Mon, 07 May 2012 10:31:00 +0200, Kris Craig
wrote:

> That being said, I agree that this *definitely* should be fixed if the
> examples cited are indeed accurate (I've been working with PHP for over
> 10 years and I was never aware of this bizarre behavior, either). I
> don't
> know the history of this, but I at least would consider it to be a bug.
> A rather large one, in fact; though I think some of the fears expressed
> are a bit hyperbolic. And if you're fixing a serious bug or security
> vulnerability, as a general rule of thumb, this automatically supercedes
> any concerns regarding BC breakage IMHO.

This has already been discussed in its own thread, see
http://comments.gmane.org/gmane.comp.php.devel/72790 ; see also
https://bugs.php.net/bug.php?id=54547

Doing away entirely with this behavior (e.g. making " 2" == "2" compare
false) would be a rather large BC break, that discussion is restricted to
whether integers in strings should be treated differently from integer
literals for comparison purposes when their range is exceeded. I wrote a
patch for that, and, while not really caring one way or the other, I'm not
convinced it's necessary and I some have consistency concerns (though
float overflows already get a similar treatment).

--
Gustavo Lopes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Kris Craig — Mon, 07 May 2012 10:40:07 +0200

On Mon, May 7, 2012 at 12:28 AM, Arvids Godjuks wrote:

> Hello internals,
>
> I should voice my opinion that such things like comparing two strings
> starting with numbers and that they resolve to actual integer/float for
> comparation is bad, really bad. That just defies the logic and yealds
> absolutly unexpected results. I pride myself that i know the juggling rules
> well, but I'm shocked by this to say the least...
> In my opinion this should change no matter the BC breaks it will create,
> this one affects security big time. It's good I actually hash my passwords
> in the MySQL and not on the PHP side, but I have seen hash comparations
> with == all the time. And now that this has been discussed in detail I
> expect this to be used as an attack method grow wide.
> 07.05.2012 5:32 пользователь "Tjerk Anne Meesters"
> написал:

Forgive me if I'm missing something, but why are people using == for
security-sensitive string comparisons (like hashed passwords) in the first
place?! If you needs something that's safe, isn't that what strcmp() and
strcasecmp() are for? For my part, I pretty much never use == on string
comparison, though admittedly that's probably just a matter of having
having come from a C background before PHP.

That being said, I agree that this *definitely* should be fixed if the
examples cited are indeed accurate (I've been working with PHP for over 10
years and I was never aware of this bizarre behavior, either). I don't
know the history of this, but I at least would consider it to be a bug. A
rather large one, in fact; though I think some of the fears expressed are a
bit hyperbolic. And if you're fixing a serious bug or security
vulnerability, as a general rule of thumb, this automatically supercedes
any concerns regarding BC breakage IMHO. But if that really is a lingering
concern, I'd suggest targetting the fix for PHP 6, since people would (or
at least should) expect that some PHP 5 code may behave differently in PHP
6 anyway given that it's a major release

--Kris

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Arvids Godjuks — Mon, 07 May 2012 09:30:05 +0200

Hello internals,

I should voice my opinion that such things like comparing two strings
starting with numbers and that they resolve to actual integer/float for
comparation is bad, really bad. That just defies the logic and yealds
absolutly unexpected results. I pride myself that i know the juggling rules
well, but I'm shocked by this to say the least...
In my opinion this should change no matter the BC breaks it will create,
this one affects security big time. It's good I actually hash my passwords
in the MySQL and not on the PHP side, but I have seen hash comparations
with == all the time. And now that this has been discussed in detail I
expect this to be used as an attack method grow wide.
07.05.2012 5:32 пользователь "Tjerk Anne Meesters"
написал:

> On Sun, May 6, 2012 at 12:17 AM, Richard Lynch wrote:
> >> What exactly valid points? == is a converting operator, === is a
> >> strict
> >> operator. OK, in his favorite language it is not. Where exactly the
> >> valid point is? Author goes at great lengths to refuse to make even a
> >> slight mental effort to understand how it works (really, it's not that
> >> hard) and then complains it's "useless". Well, a lot of things would
> >> be
> >> useless if you don't want to know how to use them.
> >
> > He has a few valid points in the part I read before I got bored...
> >
> > $a = "123ABF453..."; //a password
> > $b = "123DFEABC..."; //another one
> > if ($a == $b){
> > //you're in.
> > }
> >
> > Yes, one should have validated the input...
> >
> > But you don't have to be THAT naive to think that the hashed value of
> > an SQL injection attack just isn't going to work, so it's "safe"...
> >
> > I'll bet I have some of these in my (recent) code, for that matter.
> >
> > On the other hand, if you accept type juggling, you have to expect the
> > other cases he has for == being a bit strange.
>
> Validated or not, why would type juggling even come into the picture
> if both variables are of the same type?
>
> 123 == "123abc" // sure, why not
> "61529519452809720693702583126814" ==
> "61529519452809720000000000000000" // WAT?!
>
> In the above, only the first ~50% of an md5 hash has to be correct.
> This gets even worse for SHA256 hashes.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Tjerk Anne Meesters — Mon, 07 May 2012 05:40:03 +0200

On Sun, May 6, 2012 at 12:17 AM, Richard Lynch wrote:
>> What exactly valid points? == is a converting operator, === is a
>> strict
>> operator. OK, in his favorite language it is not. Where exactly the
>> valid point is? Author goes at great lengths to refuse to make even a
>> slight mental effort to understand how it works (really, it's not that
>> hard) and then complains it's "useless". Well, a lot of things would
>> be
>> useless if you don't want to know how to use them.
>
> He has a few valid points in the part I read before I got bored...
>
> $a = "123ABF453..."; //a password
> $b = "123DFEABC..."; //another one
> if ($a == $b){
> //you're in.
> }
>
> Yes, one should have validated the input...
>
> But you don't have to be THAT naive to think that the hashed value of
> an SQL injection attack just isn't going to work, so it's "safe"...
>
> I'll bet I have some of these in my (recent) code, for that matter.
>
> On the other hand, if you accept type juggling, you have to expect the
> other cases he has for == being a bit strange.

Validated or not, why would type juggling even come into the picture
if both variables are of the same type?

123 == "123abc" // sure, why not
"61529519452809720693702583126814" ==
"61529519452809720000000000000000" // WAT?!

In the above, only the first ~50% of an md5 hash has to be correct.
This gets even worse for SHA256 hashes.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Richard Lynch — Sat, 05 May 2012 18:20:01 +0200

On Tue, April 10, 2012 1:27 pm, Stas Malyshev wrote:
> Hi!
>
>> Scroll down a bit; he gets into valid points about the == operator,
>> for instance. It's not a useless post. He does cite too many things
>> that he has to follow up himself by saying "this was fixed in PHP
>> 5.x.y." If it was fixed, why is it on your laundry list still?
>
> What exactly valid points? == is a converting operator, === is a
> strict
> operator. OK, in his favorite language it is not. Where exactly the
> valid point is? Author goes at great lengths to refuse to make even a
> slight mental effort to understand how it works (really, it's not that
> hard) and then complains it's "useless". Well, a lot of things would
> be
> useless if you don't want to know how to use them.

He has a few valid points in the part I read before I got bored...

$a = "123ABF453..."; //a password
$b = "123DFEABC..."; //another one
if ($a == $b){
//you're in.
}

Yes, one should have validated the input...

But you don't have to be THAT naive to think that the hashed value of
an SQL injection attack just isn't going to work, so it's "safe"...

I'll bet I have some of these in my (recent) code, for that matter.

On the other hand, if you accept type juggling, you have to expect the
other cases he has for == being a bit strange.

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Philip Olson — Wed, 18 Apr 2012 11:00:02 +0200

On Apr 18, 2012, at 1:34 AM, Hartmut Holzgraefe wrote:

> On 04/10/2012 06:20 PM, Adir Kuhn wrote:
>> Hi folks,
>>
>> today I read this post, I think that some points are valid, follow the link for
>> you guys
>
> as stuff like this comes up again and again (although not in as epic
> lenght as this one) i've been thinking whether it might make sense to
> have some
>
> "PHP Gotchas, how they came to be, and why we can't simply fix them"
>
> FAQ section in the manual or wiki?
>
> If nothing else it would at least help with dealing with this kind
> of rant (nothing new here, move along, your concerns were already
> covered in ### in great detail), but also might help that would
> indeed want to understand why some things are as they are.
>
> I'd rather proactively own this kind of discussions than just
> jump into them whenever they arise elsewhere …

Hello Hartmut,

Agreed, and I think it belongs in the manual. An example (not being
proposed as such, but is a rough idea):

Why are function naming schemes seemingly random?

PHP glues many different API's together, and sometimes this
gets messy. PHP leans towards the C variant which is why the
likes of strlen() vs str_replace() exists, and …

As opposed to our current approach, which is via mailing lists and
typically "RTFM." or "BC. Read archives." or the like. Ack!

And also include possible solutions/recommendations like this PHP FAQ
entry about haystack,needle ordering, which includes the following
text:

A simple rule of thumb is as follows: Array function parameters
are ordered as "needle, haystack" whereas String functions are the
opposite, so "haystack, needle".

And thankfully there are already a lot of sites to steal the questions
from, and often answers live within their user comments. :)

Regards,
Philip

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Hartmut Holzgraefe — Wed, 18 Apr 2012 10:50:02 +0200

On 04/11/2012 05:19 PM, Luke Scott wrote:

> The only thing that infuriates me is the ternary operator being left
> associative. I want that fixed - screw bc on that one! I have been
> programming for 10 years and that one still confuses me! Most people
> just add parentheses to "fix" the problem. I wish someone would write
> an RFC to change this to right associative like every other language!
> *hint hint*

i actually never noticed this until now as i keep it as a best practice
to never nest ternaries anyway, in any language. To me it's at least as
much a sign for a desseased mind as using multiple exclamation marks
!!!11eleven ;)

The problem i see though is that in code that really relies on this it
may become a real nightmare to track down what goes wrong if evaluation
order is changed if you're not aware of that change having happened.

An E_DEPRECATED may help here, but will also produce a lot of false
positives for those using parentheses? Or can we add enough parser
magic to only throw warnings for the unsafe uses? ...

--
hartmut

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Hartmut Holzgraefe — Wed, 18 Apr 2012 10:40:02 +0200

On 04/10/2012 06:20 PM, Adir Kuhn wrote:
> Hi folks,
>
> today I read this post, I think that some points are valid, follow the link for
> you guys

as stuff like this comes up again and again (although not in as epic
lenght as this one) i've been thinking whether it might make sense to
have some

"PHP Gotchas, how they came to be, and why we can't simply fix them"

FAQ section in the manual or wiki?

If nothing else it would at least help with dealing with this kind
of rant (nothing new here, move along, your concerns were already
covered in ### in great detail), but also might help that would
indeed want to understand why some things are as they are.

I'd rather proactively own this kind of discussions than just
jump into them whenever they arise elsewhere ...

--
hartmut

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Ralf Lang — Wed, 11 Apr 2012 23:20:02 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 10.04.2012 20:28, schrieb Kris Craig:
> On Tue, Apr 10, 2012 at 11:12 AM, Ralf Lang
> wrote:
>
>>>> It always amuses me when PERL developers go on their little
>>>> soapboxes about how "real" programmers all think PHP is
>>>> stupid lol.
>
> It always amuses me PHP people think perl is stupid and vice
> versa. Both languages have their use case, sometimes I even use
> them side by side in the same project. PHP daemons and forking is
> not exactly what I would depend on working reliably.
>
>
>> Umm at what point did I say PERL is "stupid?" PERL is like the
>> duct-tape of scripting languages; it can be used for just about
>> anything, though there's almost always a more specialized
>> solution. It serves a purpose.

I did not mean you personally told anything about perl. Of course perl
serves a purpose. That's why it's still around.

- --
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang@b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+F8x8ACgkQCs1dsHJ/X7AjMACfcGvNM7Nz6FBQ2yZDNtiw9L7M
AFsAoMjTbEtdQcicPuayb8GAtOTi5F0I
=wLGk
-----END PGP SIGNATURE-----

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Johannes Schlüter — Wed, 11 Apr 2012 23:10:03 +0200

On Wed, 2012-04-11 at 19:44 +0100, Lester Caine wrote:
> Anthony Ferrara wrote:
> > Even with PDO and older versions of MySQL, you could inject into
> > prepared statements quite easily (assuming charset settings):
> >
> > $var = '1' . chr(0xbf) . chr(0x27) . ' OR 1=1';
> >
> > $pdo = new PDO('mysql:...');
> > $pdo->query('SET NAMES GBK');
> > $stmt = $pdo->prepare('SELECT * FROM foo WHERE 2 = ?');
> > $stmt->bindParam(1, $var);
> > $stmt->execute();
> >
> > Without setting $pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, 0)
> > first, that will successfully inject into the query thanks to how PDO
> > emulates prepares.
> >
> > A problem that true prepared statements (MySQLi and if PDO has emulate
> > prepares off) is immune to...
>
> Try doing that with a real database ;)

If PDO decided to use emulation by default (which has benefits like
fewer roundtrips etc.) it's not necessarily the issue from the database.

And that this doesn't work is obvious with emulation - PDO doesn't parse
the SQL and has no understanding of "SET NAMES", neither does the MySQL
client lib used. The proper way to set the encoding is by using the
DSN's charset option.

johannes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Lester Caine — Wed, 11 Apr 2012 20:50:02 +0200

Anthony Ferrara wrote:
> Even with PDO and older versions of MySQL, you could inject into
> prepared statements quite easily (assuming charset settings):
>
> $var = '1' . chr(0xbf) . chr(0x27) . ' OR 1=1';
>
> $pdo = new PDO('mysql:...');
> $pdo->query('SET NAMES GBK');
> $stmt = $pdo->prepare('SELECT * FROM foo WHERE 2 = ?');
> $stmt->bindParam(1, $var);
> $stmt->execute();
>
> Without setting $pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, 0)
> first, that will successfully inject into the query thanks to how PDO
> emulates prepares.
>
> A problem that true prepared statements (MySQLi and if PDO has emulate
> prepares off) is immune to...

Try doing that with a real database ;)

Firebird is not susceptible to this sort of problem. And I have still to find
any use for PDO in real systems. It's just another layer that gets in the way of
processing data securely. Emulating things half cocked is simply another
security hole anyway.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Anthony Ferrara — Wed, 11 Apr 2012 19:30:02 +0200

Lester,

Even with PDO and older versions of MySQL, you could inject into
prepared statements quite easily (assuming charset settings):

$var = '1' . chr(0xbf) . chr(0x27) . ' OR 1=1';

$pdo = new PDO('mysql:...');
$pdo->query('SET NAMES GBK');
$stmt = $pdo->prepare('SELECT * FROM foo WHERE 2 = ?');
$stmt->bindParam(1, $var);
$stmt->execute();

Without setting $pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, 0)
first, that will successfully inject into the query thanks to how PDO
emulates prepares.

A problem that true prepared statements (MySQLi and if PDO has emulate
prepares off) is immune to...

Anthony

On Wed, Apr 11, 2012 at 12:06 PM, Lester Caine wrote:
> Ralph Schindler wrote:
>>
>> Hey Lester,
>>
>>
>>> That is almost archaic it's self ...
>>> It should be replaced with a pointer to using parameters ( no we do not
>>> need 'prepared statements', just parameters ). One of the first things I
>>> implement on any code that I'm porting. Does away with any agro over
>>> escaping strings and is totally save 'injection' wise.
>>
>>
>> While I generally agree, 'just parameters' does have it's limitations.
>> Sometimes
>> there are special character sequences that can be exploited to escape out
>> of a
>> quoted value in a SQL string.
>>
>> Offhand, this comes to mind about MySQL:
>> http://bugs.mysql.com/bug.php?id=8378
>
>
> Well if you must use a simple database ;)
>
> I've never used MySQL simply because it has yet to get to the same standard
> as Firebird ... But I'm talking about passing parameters direct to '?'
> entries in the SQL - something which if it CAN be broken then the database
> is also broken? The database handles the 'data' going into a single field at
> a time.
>
>
> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk//
> Firebird - http://www.firebirdsql.org/index.php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Lester Caine — Wed, 11 Apr 2012 18:10:02 +0200

Ralph Schindler wrote:
> Hey Lester,
>
>> That is almost archaic it's self ...
>> It should be replaced with a pointer to using parameters ( no we do not
>> need 'prepared statements', just parameters ). One of the first things I
>> implement on any code that I'm porting. Does away with any agro over
>> escaping strings and is totally save 'injection' wise.
>
> While I generally agree, 'just parameters' does have it's limitations. Sometimes
> there are special character sequences that can be exploited to escape out of a
> quoted value in a SQL string.
>
> Offhand, this comes to mind about MySQL:
> http://bugs.mysql.com/bug.php?id=8378

Well if you must use a simple database ;)

I've never used MySQL simply because it has yet to get to the same standard as
Firebird ... But I'm talking about passing parameters direct to '?' entries in
the SQL - something which if it CAN be broken then the database is also broken?
The database handles the 'data' going into a single field at a time.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Ralph Schindler — Wed, 11 Apr 2012 17:50:03 +0200

Hey Lester,

On 4/11/12 3:29 AM, Lester Caine wrote:

> That is almost archaic it's self ...
> It should be replaced with a pointer to using parameters ( no we do not
> need 'prepared statements', just parameters ). One of the first things I
> implement on any code that I'm porting. Does away with any agro over
> escaping strings and is totally save 'injection' wise.

While I generally agree, 'just parameters' does have it's limitations.
Sometimes there are special character sequences that can be exploited to
escape out of a quoted value in a SQL string.

Offhand, this comes to mind about MySQL:
http://bugs.mysql.com/bug.php?id=8378

-ralph

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Luke Scott — Wed, 11 Apr 2012 17:30:02 +0200

I do agree with a lot of what was being said. But what can you do?
These are mostly quirks of the language. You learn to live with them.
I don't make excuses for it. It is what it is.

The only thing that infuriates me is the ternary operator being left
associative. I want that fixed - screw bc on that one! I have been
programming for 10 years and that one still confuses me! Most people
just add parentheses to "fix" the problem. I wish someone would write
an RFC to change this to right associative like every other language!
*hint hint*

Luke Scott

On Apr 10, 2012, at 9:21 AM, Adir Kuhn wrote:

> Hi folks,
>
> today I read this post, I think that some points are valid, follow the link for
> you guys
>
> http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
>
> Adir Kuhn
> ZCE - Zend Certified Engineer **PHP 5.3 #ZEND004035
> PSMI - Professional Scrum Master I

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Lester Caine — Wed, 11 Apr 2012 10:40:03 +0200

Yasuo Ohgaki wrote:
> Anyway,
> http://www.php.net/manual/en/security.database.sql-injection.php
> I've never read this page. This page must be improved...

That is almost archaic it's self ...
It should be replaced with a pointer to using parameters ( no we do not need
'prepared statements', just parameters ). One of the first things I implement on
any code that I'm porting. Does away with any agro over escaping strings and is
totally save 'injection' wise.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Crocodile — Wed, 11 Apr 2012 10:20:02 +0200

Stopped reading after encountered "E_ACTUALLY_ALL", "for ($foo as &$bar)" -
these things required me to google or to refer to docs to ensure I was not
missing something. And, yes, I should have stopped after the words "don’t
tell me anything!". People who refuse to listen do not deserve to be heard.

2012/4/11 Yasuo Ohgaki

> Hi,
>
> It was fun to read. I understand he just don't like PHP.
> His article may be good for novice users to understand how PHP will behave.
>
> I guess he learned PHP a lot, but he lists framework feature as
> missing. I wander why. He seems to like Python, but Python's multibyte
> support was awful until recent.
>
> Anyway,
> http://www.php.net/manual/en/security.database.sql-injection.php
> I've never read this page. This page must be improved...
>
> I haven't read all, but there may be other places that may help.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [off] PHP: a fractal of bad design

Yasuo Ohgaki — Wed, 11 Apr 2012 09:40:02 +0200

Hi,

It was fun to read. I understand he just don't like PHP.
His article may be good for novice users to understand how PHP will behave.

I guess he learned PHP a lot, but he lists framework feature as
missing. I wander why. He seems to like Python, but Python's multibyte
support was awful until recent.

Anyway,
http://www.php.net/manual/en/security.database.sql-injection.php
I've never read this page. This page must be improved...

I haven't read all, but there may be other places that may help.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php