I'm trying to set up a simple conditional, something like this:
If my_variable is NT equal to (black or white)
echo "wrong color"
else
echo "right color"
Here is what I have tried:
if ($_REQUEST['id'] != ("black" or "white")) {
echo "wrong color";
} else (
echo "right color";
)
However, no matter what I enter, I always get response "right color".
I should add that if I change the if statement to:
if ($_REQUEST['id'] != ("black"))
then I get "right color" when I enter "black" and "wrong color" for
everything else.
Would you please point out what's the trivial thing I'm missing here
jd

Let me rephrase it. Your color should be black or white to be the right
colour. Is this correct?

In that case you should change it to

if ($_REQUEST['id'] != "black" AND $_REQUEST['id'] != "white") {

echo "wrong color";

} else (

echo "right color";

}

Message
From: "JD" <jd_borozo (AT) borozo (DOT) com>
To: <php-general (AT) lists (DOT) php.net>
Sent: Friday, September 08, 2006 5:03 PM
Subject: [PHP] if statement with or comparison (newbie)

I'm trying to set up a simple conditional, something like this:

If my_variable is NT equal to (black or white)
echo "wrong color"
else
echo "right color"

Here is what I have tried:

if ($_REQUEST['id'] != ("black" or "white")) {

echo "wrong color";

} else (

echo "right color";

)

However, no matter what I enter, I always get response "right color".

I should add that if I change the if statement to:

if ($_REQUEST['id'] != ("black"))

then I get "right color" when I enter "black" and "wrong color" for
everything else.

Would you please point out what's the trivial thing I'm missing here

jd

Shouldn't that be this instead:
if (($_REQUEST['id'] != "black") R ($_REQUEST['id'] !=
"white")) {
echo "wrong color";
} else {
echo "right color";
}

I think the R should be an AND

If $_REQUEST['id'] = "black" then the second test will be true and it
will output "wrong color." If the color is "white" then the same thing
will happen 'cause it meets the first criteria.
-- Mitch

Kevin Murphy wrote:
Shouldn't that be this instead:

if (($_REQUEST['id'] != "black") R ($_REQUEST['id'] != "white")) {

echo "wrong color";

} else {

echo "right color";

}

Message
From: "JD" <jd_borozo (AT) borozo (DOT) com>
To: <php-general (AT) lists (DOT) php.net>
Sent: Friday, September 08, 2006 11:03 PM
Subject: [PHP] if statement with or comparison (newbie)

I'm trying to set up a simple conditional, something like this:

If my_variable is NT equal to (black or white)
echo "wrong color"
else
echo "right color"

Here is what I have tried:

if ($_REQUEST['id'] != ("black" or "white")) {

What PHP (and any parser, for that matter) will try to do is first solve the
innermost parenthesis. ("black" or "white"). Many typed languages would
give an error at this point, but PHP tries to convert anything it gets to
whatever is more useful at the moment. Since both "black" and "white" are
not null or empty strings, they are evaluated as true for the logical
comparison and true or true is always true. Now, $_REQUEST['id'] might be
whatever it is, but dealing with booleans as we are this far, anything but
missing or empty string will be true as well, which will give you the second
option.

Now, first of all, avoid negative comparissons, negative booleans are
horrible. Try first to straighten them up or you might get thoroughly
confussed:

if ($_REQUEST['id] == 'black' or $_REQUEST['id'] == 'white') {
echo 'right color';
} else {
echo 'wrong color'';
}

And so as you know why it is good to straighten negative booleans, this
would be the twisted way

if ($_REQUEST['id] != 'black' and $_REQUEST['id'] != 'white') {
echo 'wrong color'';
} else {
echo 'right color';
}

Notice that not only the comparisson changed but now they are joined by an
AND instead of an R and the then and else parts are swapped.

Satyam

echo "wrong color";

} else (

echo "right color";

)

However, no matter what I enter, I always get response "right color".

I should add that if I change the if statement to:

if ($_REQUEST['id'] != ("black"))

then I get "right color" when I enter "black" and "wrong color" for
everything else.

Would you please point out what's the trivial thing I'm missing here

jd

Message
From: "JD" <jd_borozo (AT) borozo (DOT) com>
To: <php-general (AT) lists (DOT) php.net>
Sent: Friday, September 08, 2006 11:03 PM
Subject: [PHP] if statement with or comparison (newbie)

I'm trying to set up a simple conditional, something like this:

If my_variable is NT equal to (black or white)
echo "wrong color"
else
echo "right color"

Here is what I have tried:

if ($_REQUEST['id'] != ("black" or "white")) {

What PHP (and any parser, for that matter) will try to do is first solve the
innermost parenthesis. ("black" or "white"). Many typed languages would
give an error at this point, but PHP tries to convert anything it gets to
whatever is more useful at the moment. Since both "black" and "white" are
not null or empty strings, they are evaluated as true for the logical
comparison and true or true is always true. Now, $_REQUEST['id'] might be
whatever it is, but dealing with booleans as we are this far, anything but
missing or empty string will be true as well, which will give you the second
option.

Now, first of all, avoid negative comparissons, negative booleans are
horrible. Try first to straighten them up or you might get thoroughly
confussed:

if ($_REQUEST['id] == 'black' or $_REQUEST['id'] == 'white') {
echo 'right color';
} else {
echo 'wrong color'';
}

And so as you know why it is good to straighten negative booleans, this
would be the twisted way

if ($_REQUEST['id] != 'black' and $_REQUEST['id'] != 'white') {
echo 'wrong color'';
} else {
echo 'right color';
}

Notice that not only the comparisson changed but now they are joined by an
AND instead of an R and the then and else parts are swapped.

Satyam

echo "wrong color";

} else (

echo "right color";

)

However, no matter what I enter, I always get response "right color".

I should add that if I change the if statement to:

if ($_REQUEST['id'] != ("black"))

then I get "right color" when I enter "black" and "wrong color" for
everything else.

Would you please point out what's the trivial thing I'm missing here

jd

At 05:30 PM 9/8/2006, you wrote:

Message From: "JD" <jd_borozo (AT) borozo (DOT) com>
>To: <php-general (AT) lists (DOT) php.net>
>Sent: Friday, September 08, 2006 11:03 PM
>Subject: [PHP] if statement with or comparison (newbie)
>
>
>>I'm trying to set up a simple conditional, something like this:
>>
>>If my_variable is NT equal to (black or white)
>echo "wrong color"
>>else
>echo "right color"
>>
>>Here is what I have tried:
>>
>if ($_REQUEST['id'] != ("black" or "white")) {
>
>What PHP (and any parser, for that matter) will try to do is first solve
>the innermost parenthesis. ("black" or "white"). Many typed languages
>would give an error at this point, but PHP tries to convert anything it
>gets to whatever is more useful at the moment. Since both "black" and
>"white" are not null or empty strings, they are evaluated as true for the
>logical comparison and true or true is always true. Now, $_REQUEST['id']
>might be whatever it is, but dealing with booleans as we are this far,
>anything but missing or empty string will be true as well, which will give
>you the second option.
>
>
>Now, first of all, avoid negative comparissons, negative booleans are
>horrible. Try first to straighten them up or you might get thoroughly
>confussed:
>
>
>if ($_REQUEST['id] == 'black' or $_REQUEST['id'] == 'white') {
echo 'right color';
>} else {
>echo 'wrong color'';
>}
>
>And so as you know why it is good to straighten negative booleans, this
>would be the twisted way
>
>if ($_REQUEST['id] != 'black' and $_REQUEST['id'] != 'white') {
>echo 'wrong color'';
>} else {
echo 'right color';
>}
>
>Notice that not only the comparisson changed but now they are joined by an
>AND instead of an R and the then and else parts are swapped.
>
>Satyam

Thank you all!

jd

At 5:03 PM -0400 9/8/06, JD wrote:
>I'm trying to set up a simple conditional, something like this:
>
>Here is what I have tried:
>
if ($_REQUEST['id'] != ("black" or "white")) {

In all of the answers given thus far, no one mentioned that the use
of $_REQUEST has a security issue with regard to where the $_REQUEST
originated.

$_REQUEST is an array consisting of $_GET, $_PST and $_CKIE values
and as such, you don't know where the data came from and that might
be important.

So, wouldn't it be better to recommend that the poster use $_GET,
$_PST, or $_CKIE instead of $_REQUEST?

Just an idea -- comments?

tedd

Fri, 2006-09-08 at 18:38 -0400, tedd wrote:
At 5:03 PM -0400 9/8/06, JD wrote:
>I'm trying to set up a simple conditional, something like this:
>
>Here is what I have tried:
>
if ($_REQUEST['id'] != ("black" or "white")) {

In all of the answers given thus far, no one mentioned that the use
of $_REQUEST has a security issue with regard to where the $_REQUEST
originated.

$_REQUEST is an array consisting of $_GET, $_PST and $_CKIE values
and as such, you don't know where the data came from and that might
be important.

So, wouldn't it be better to recommend that the poster use $_GET,
$_PST, or $_CKIE instead of $_REQUEST?

Nope, not inherently less secure. If you are properly cleaning and
validating your data (as every good program should) then it doesn't
matter whether you pull from $_GET, $_PST, or $_REQUEST. The only time
it's bad is if you make assumptions about the value received -- AND YU
SHULD NEVER ASSUME YU HAVE CLEAN DATA FRM AN UTSIDE SURCE!!

Cheers,
Rob.

No, just try it. Since the returned value cannot have to values at once,
whatever it comes it will succeed either one or both and being joined by an
or, any single one that succeeds make the whole succeed. Just try it:

Returned value result
red true or true =true
black false or true =true
white true or false =true

That is why in my e-mail I insisted that the best thing you can do with
complex booleans is try to straighten the logic and avoid too many
negations, which tend to turn the logic upside down.

Satyam

Message
From: "Kevin Murphy" <php (AT) stubborndonkey (DOT) com>
To: "php" <php-general (AT) lists (DOT) php.net>
Cc: "JD" <jd_borozo (AT) borozo (DOT) com>
Sent: Friday, September 08, 2006 11:25 PM
Subject: Re: [PHP] if statement with or comparison (newbie)

Shouldn't that be this instead:
--
if (($_REQUEST['id'] != "black") R ($_REQUEST['id'] !=
"white")) {

echo "wrong color";

} else {

echo "right color";

}
--

No, just try it. Since the returned value cannot have to values at once,
whatever it comes it will succeed either one or both and being joined by an
or, any single one that succeeds make the whole succeed. Just try it:

Returned value result
red true or true =true
black false or true =true
white true or false =true

That is why in my e-mail I insisted that the best thing you can do with
complex booleans is try to straighten the logic and avoid too many
negations, which tend to turn the logic upside down.

Satyam

Message
From: "Kevin Murphy" <php (AT) stubborndonkey (DOT) com>
To: "php" <php-general (AT) lists (DOT) php.net>
Cc: "JD" <jd_borozo (AT) borozo (DOT) com>
Sent: Friday, September 08, 2006 11:25 PM
Subject: Re: [PHP] if statement with or comparison (newbie)

Shouldn't that be this instead:
--
if (($_REQUEST['id'] != "black") R ($_REQUEST['id'] !=
"white")) {

echo "wrong color";

} else {

echo "right color";

}
--

Robert Cummings wrote:
Fri, 2006-09-08 at 18:38 -0400, tedd wrote:

>At 5:03 PM -0400 9/8/06, JD wrote:
>
>In all of the answers given thus far, no one mentioned that the use
>of $_REQUEST has a security issue with regard to where the $_REQUEST
>originated.
>>
>$_REQUEST is an array consisting of $_GET, $_PST and $_CKIE values
>and as such, you don't know where the data came from and that might
>be important.
>>
>So, wouldn't it be better to recommend that the poster use $_GET,
>$_PST, or $_CKIE instead of $_REQUEST?
>
>
Nope, not inherently less secure. If you are properly cleaning and
validating your data (as every good program should) then it doesn't
matter whether you pull from $_GET, $_PST, or $_REQUEST. The only time
it's bad is if you make assumptions about the value received -- AND YU
SHULD NEVER ASSUME YU HAVE CLEAN DATA FRM AN UTSIDE SURCE!!

However, looking at it from a 'knowing early the data is tainted'
perspective, not from a 'validating and cleaning perspective', if you
have coded that (for instance) a variable is set via CKIE, then only
looking for that variable set via CKIE will eliminate its being
tainted by being set via GET or REQUEST. It doesn't eliminate any need
for validation or cleaning, but reduces (naive) attempts to set via
incorrect means. That is not possible via REQUEST. Personally, I like to
toss out possibilities of bad data via simple means as early in the
chain as possible.

Mark Charette wrote:
However, looking at it from a 'knowing early the data is tainted'
perspective, not from a 'validating and cleaning perspective', if you
have coded that (for instance) a variable is set via CKIE, then only
looking for that variable set via CKIE will eliminate its being
tainted by being set via GET or REQUEST. It doesn't eliminate any need
for validation or cleaning, but reduces (naive) attempts to set via
incorrect means. That is not possible via REQUEST. Personally, I like to
toss out possibilities of bad data via simple means as early in the
chain as possible.

If I understood that right it's a shocking naive statement for any
developer to make. While I agree with what you're saying, you're
implying a bad attitude to handling data from untrusted sources.

It shouldn't matter how difficult it is for the user to send you dodgy
data if its source is outside your control you need to handle it
accordingly no matter how unlikely you think it is that it will be
changed between you setting it and getting it back.

Data from any of the superglobals should be treated the same - trust
none of them!!
-Stut

Sat, 2006-09-09 at 10:21 -0400, Mark Charette wrote:
Robert Cummings wrote:
Fri, 2006-09-08 at 18:38 -0400, tedd wrote:

>At 5:03 PM -0400 9/8/06, JD wrote:
>
>In all of the answers given thus far, no one mentioned that the use
>of $_REQUEST has a security issue with regard to where the $_REQUEST
>originated.
>>
>$_REQUEST is an array consisting of $_GET, $_PST and $_CKIE values
>and as such, you don't know where the data came from and that might
>be important.
>>
>So, wouldn't it be better to recommend that the poster use $_GET,
>$_PST, or $_CKIE instead of $_REQUEST?
>
>
Nope, not inherently less secure. If you are properly cleaning and
validating your data (as every good program should) then it doesn't
matter whether you pull from $_GET, $_PST, or $_REQUEST. The only time
it's bad is if you make assumptions about the value received -- AND YU
SHULD NEVER ASSUME YU HAVE CLEAN DATA FRM AN UTSIDE SURCE!!

However, looking at it from a 'knowing early the data is tainted'
perspective, not from a 'validating and cleaning perspective', if you
have coded that (for instance) a variable is set via CKIE, then only
looking for that variable set via CKIE will eliminate its being
tainted by being set via GET or REQUEST. It doesn't eliminate any need
for validation or cleaning, but reduces (naive) attempts to set via
incorrect means. That is not possible via REQUEST. Personally, I like to
toss out possibilities of bad data via simple means as early in the
chain as possible.

Any malevolently intentioned hacker will have little properly screwing
around with cookie data. I'm pretty sure browsers allow editing the
cookie values via the cookie browser. And if not, a quick PHP script is
just as simple to create that mucks with cookie data.

Cheers,
Rob.

Stut wrote:
Mark Charette wrote:
>However, looking at it from a 'knowing early the data is tainted'
>perspective, not from a 'validating and cleaning perspective', if you
>have coded that (for instance) a variable is set via CKIE, then
>only looking for that variable set via CKIE will eliminate its
>being tainted by being set via GET or REQUEST. It doesn't eliminate
>any need for validation or cleaning, but reduces (naive) attempts to
>set via incorrect means. That is not possible via REQUEST.
>Personally, I like to toss out possibilities of bad data via simple
>means as early in the chain as possible.
>
If I understood that right it's a shocking naive statement for any
developer to make. While I agree with what you're saying, you're
implying a bad attitude to handling data from untrusted sources.
I am being neither shocking or naive. Why is early discarding of data
because it comes in the wrong area shocking? If I were looking for a
variable set via a CKIE, why would I look for the variable set via
GET? As I so explicitly said above "It doesn't eliminate any need for
validation or cleaning, but reduces (naive) attempts to set via
incorrect means." My CPU resources are valuable; writing code that
checks whether a variable is set via the correct method is no harder
($_CKIE vs. $_REQUEST) and throws out trivially spurious data. No
more, no less. The same checks still need apply after that, but my CPU
won't be burdened by the script kiddies. No more, no less. The data just
won't appear.

Sat, 2006-09-09 at 11:30 -0400, Mark Charette wrote:
Stut wrote:
Mark Charette wrote:
>However, looking at it from a 'knowing early the data is tainted'
>perspective, not from a 'validating and cleaning perspective', if you
>have coded that (for instance) a variable is set via CKIE, then
>only looking for that variable set via CKIE will eliminate its
>being tainted by being set via GET or REQUEST. It doesn't eliminate
>any need for validation or cleaning, but reduces (naive) attempts to
>set via incorrect means. That is not possible via REQUEST.
>Personally, I like to toss out possibilities of bad data via simple
>means as early in the chain as possible.
>
If I understood that right it's a shocking naive statement for any
developer to make. While I agree with what you're saying, you're
implying a bad attitude to handling data from untrusted sources.

I am being neither shocking or naive. Why is early discarding of data
because it comes in the wrong area shocking?

That's your last line, I think he's commenting on the rest of your
comment. Questionable data is questionable data, it doesn't matter from
whence you clean it. If you haven't cleaned it your still going to get
screwed no matter how much you rely on it being difficult to manipulate
by a site visitor.

Cheers,
Rob.

Robert Cummings wrote:
Sat, 2006-09-09 at 11:30 -0400, Mark Charette wrote:

>Stut wrote:
>
Mark Charette wrote:

However, looking at it from a 'knowing early the data is tainted'
perspective, not from a 'validating and cleaning perspective', if you
have coded that (for instance) a variable is set via CKIE, then
only looking for that variable set via CKIE will eliminate its
being tainted by being set via GET or REQUEST. It doesn't eliminate
any need for validation or cleaning, but reduces (naive) attempts to
set via incorrect means. That is not possible via REQUEST.
Personally, I like to toss out possibilities of bad data via simple
means as early in the chain as possible.

If I understood that right it's a shocking naive statement for any
developer to make. While I agree with what you're saying, you're
implying a bad attitude to handling data from untrusted sources.


>I am being neither shocking or naive. Why is early discarding of data
>because it comes in the wrong area shocking?
>
>
That's your last line, I think he's commenting on the rest of your
comment. Questionable data is questionable data, it doesn't matter from
whence you clean it. If you haven't cleaned it your still going to get
screwed no matter how much you rely on it being difficult to manipulate
by a site visitor.

Where am I being unclear, then? "reduces (naive) attempts to set via
incorrect means." doesn't say 'eliminate serious attempts'. I would
think my statement "It doesn't eliminate any need for validation or
cleaning, " covers the remaining scenarios. Indeed, determining the
source of data is one of the essential steps in validation. The one of
the rules is 'discard even valid data if it comes from an untrusted
source" - and data coming from an _incorrect_ source is, by definition,
untrusted even if if you wish to expend the effort to prove it valid.

And I'll wager a brew no one here has ever done a formal, mathematically
rigorous proof of a validation routine except as a class project. As a
senior member of the software QC department in a major industrial
company, I generally find more errors and omissions in validation
routines during code reviews and ethical hacks than anywhere else.

Mark Charette wrote:
And I'll wager a brew no one here has ever done a formal, mathematically
rigorous proof of a validation routine except as a class project. As a
senior member of the software QC department in a major industrial
company, I generally find more errors and omissions in validation
routines during code reviews and ethical hacks than anywhere else.

, let's not turn this into a pissing contest. I admit I misread the
initial email and read more into it than it said. However, since this is
a mailing list with a lot of beginners on it we usually make a point to
be very clear on issues like validation and it was worth reiterating the
point that no data that comes from the user should not be trusted no
matter how hard it is for the user to change.

Your point is valid, but in the great scheme of things it's more
important to enforce the importance of validation than performance. I
felt your post was confusing so I'm sure others did too.

'Nuff pissing.
-Stut

Sat, 2006-09-09 at 12:12 -0400, Mark Charette wrote:

As a senior member of the software QC department in a major industrial
company, I generally find more errors and omissions in validation
routines during code reviews and ethical hacks than anywhere else.

Where's Tedd, he's got the latin to go with the above link >:)

Cheers,
Rob.

Sat, 2006-09-09 at 17:27 +0100, Stut wrote:
Mark Charette wrote:
And I'll wager a brew no one here has ever done a formal, mathematically
rigorous proof of a validation routine except as a class project. As a
senior member of the software QC department in a major industrial
company, I generally find more errors and omissions in validation
routines during code reviews and ethical hacks than anywhere else.

, let's not turn this into a pissing contest. I admit I misread the
initial email and read more into it than it said. However, since this is
a mailing list with a lot of beginners on it we usually make a point to
be very clear on issues like validation and it was worth reiterating the
point that no data that comes from the user should not be trusted no
matter how hard it is for the user to change.

Your point is valid, but in the great scheme of things it's more
important to enforce the importance of validation than performance. I
felt your post was confusing so I'm sure others did too.

'Nuff pissing.

Awwww, what about this bonfire I was putting out? Admittedly there's a
strong odour hanging in the air now, but we don't want forest fires do
we? *heheh*

Cheers,
Rob.

At 12:29 PM -0400 9/9/06, Robert Cummings wrote:
Sat, 2006-09-09 at 12:12 -0400, Mark Charette wrote:
>>
>As a senior member of the software QC department in a major industrial
>company, I generally find more errors and omissions in validation
>routines during code reviews and ethical hacks than anywhere else.
>
>
>
>Where's Tedd, he's got the latin to go with the above link >:)
>
>Cheers,
>Rob.

Rob:

Don't throw me in that briar patch. I know the
saying "Locus ab auctoritate est infirmissimus"
may appear to fit, but I think in this case "se
de l'eau qui dort" is better.

Besides:

A) I was the one that started this fire storm.

B) Mark came in and backed me up.

C) Stu, who respect greatly, surprisingly waded in on the other side.

Now, I stand cowardly between two opinions not
wanting to offend either, nor embarrass myself
publicly, which I do often enough anyway.

However with that said, my original question/statement still stands.

I realize (AS WE ALL D), that *all* data coming
from outside *must* be sanitized -- BUT -- using
$_REQUEST still does not provide as much
information as to where the data came from as the
use of $_GET, $_PST, and $_CKIE -- that's an
unarguable fact, is it not?

This thread was like an old-west circled wagon
train with everyone inside expounding about the
obvious dangers of an Indian attack* but failing
to listen to some who are saying "They're
attacking from the West", while arguing it's not
important to know which way the attack comes. I
think some just misread the point of the post.

tedd (as he scurries around to the east side of a rock while dodging arrows)

*In keeping with current Political correctness,
it was an US "Indian" attack -- also note the
attack was from the West and not from the East.
:-)