if statement with or comparison (newbie)

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

----- Original Message -----
From: "Kevin Murphy" <php@stubborndonkey.com>
To: "php" <php-general@lists.php.net>
Cc: "JD" <jd_borozo@borozo.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") OR ($_REQUEST['id'] !=
> "white")) {
>
> echo "wrong color";
>
> } else {
>
> echo "right color";
>
> }
>
>
> --
> Kevin Murphy
> Webmaster: Information and Marketing Services
> Western Nevada Community College
> www.wncc.edu
> 775-445-3326
>
>
> On Sep 8, 2006, at 2:28 PM, Prathaban Mookiah wrote:
>
>> 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";
>>
>> }
>>
>> ----- Original Message -----
>> From: "JD" <jd_borozo@borozo.com>
>> To: <php-general@lists.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 NOT 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
>>>
>>> --
>>> PHP General Mailing List (http://www.php.net/)
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>

Robert Cummings wrote:
> On 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, $_POST and $_COOKIE 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,
>> $_POST, or $_COOKIE 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, $_POST, or $_REQUEST. The only time
> it's bad is if you make assumptions about the value received -- AND YOU
> SHOULD NEVER ASSUME YOU HAVE CLEAN DATA FROM AN OUTSIDE SOURCE!!
>
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 COOKIE, then only
looking for that variable set via COOKIE 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 COOKIE, then only
> looking for that variable set via COOKIE 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

On Sat, 2006-09-09 at 10:21 -0400, Mark Charette wrote:
> Robert Cummings wrote:
> > On 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, $_POST and $_COOKIE 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,
> >> $_POST, or $_COOKIE 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, $_POST, or $_REQUEST. The only time
> > it's bad is if you make assumptions about the value received -- AND YOU
> > SHOULD NEVER ASSUME YOU HAVE CLEAN DATA FROM AN OUTSIDE SOURCE!!
> >
> 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 COOKIE, then only
> looking for that variable set via COOKIE 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.
--
..------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'

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 COOKIE, then
>> only looking for that variable set via COOKIE 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 COOKIE, 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
($_COOKIE 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.

On 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 COOKIE, then
> >> only looking for that variable set via COOKIE 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.
--
..------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'

Robert Cummings wrote:
> On 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 COOKIE, then
>>>> only looking for that variable set via COOKIE 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.

Ok, 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

On 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.

http://en.wikipedia.org/wiki/Appeal_to_authority

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

Cheers,
Rob.
--
..------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'

On 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.
>
> Ok, 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.
--
..------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'