Looking for a reasonable explanation as to why $_REQUEST exists

On Mon, Jul 7, 2008 at 11:43 AM, Shawn McKenzie <nospam@mckenzies.net> wrote:
> They can be what? I was wrong, the S is $_SERVER not $_SESSION.

Sorry, Shawn. That message was meant for the OP, but I clipped
your message to send a response to you as well.

Disregard. The body is here, but the brain is still on the beach
in Florida.

--
</Daniel P. Brown>
Dedicated Servers - Intel 2.4GHz w/2TB bandwidth/mo. starting at just
$59.99/mo. with no contract!
Dedicated servers, VPS, and hosting from $2.50/mo.

Daniel Brown wrote:
> On Mon, Jul 7, 2008 at 11:43 AM, Shawn McKenzie <nospam@mckenzies.net> wrote:
>
>> They can be what? I was wrong, the S is $_SERVER not $_SESSION.
>>
>
> Sorry, Shawn. That message was meant for the OP, but I clipped
> your message to send a response to you as well.
>
> Disregard. The body is here, but the brain is still on the beach
> in Florida.
>
>
Cliff, is that you ? Cliff Clavin ?

On Mon, Jul 7, 2008 at 12:33 PM, metastable
<listpit@metastable-services.net> wrote:
>
> Cliff, is that you ? Cliff Clavin ?

Very astute of you, but I consider myself more of a Norm Peterson. ;-P

--
</Daniel P. Brown>
Dedicated Servers - Intel 2.4GHz w/2TB bandwidth/mo. starting at just
$59.99/mo. with no contract!
Dedicated servers, VPS, and hosting from $2.50/mo.

On 7/7/08, Eric Butera <eric.butera@gmail.com> wrote:

> Laziness/convenience.
>
> I always get my data from the exact source I want. If someone chooses
> to use REQUEST it shouldn't break their application. You say it is a
> security risk, but not really. As long as everything is
> filtered/escaped properly it should be fine because you force the data
> to play by your rules.

I'm not talking about escaping/filtering. I'm talking about variable overriding.

In the past, it was

$_GET['foo']
$foo

register_globals fixed that.

however, if your app is relying on

$_SESSION['username'] or $_COOKIE['username'] or something like that,
depending on the variables order, it can be overridden.

I don't see why if you -know- you need $_COOKIE['username'] someone
would be lazy and use $_REQUEST['username']

It winds up allowing the end user to override information themselves
(again, depending on the variables order) which depending on that and
how poor the code is (which to me if you're relying on $_REQUEST
you've probably got some bugs and exploitable holes in there) creates
a security risk.

and session vars are in $_REQUEST, I tried it to sanity check myself
before posting this :)

mike wrote:
> On 7/7/08, Eric Butera <eric.butera@gmail.com> wrote:
>
>> Laziness/convenience.
>>
>> I always get my data from the exact source I want. If someone chooses
>> to use REQUEST it shouldn't break their application. You say it is a
>> security risk, but not really. As long as everything is
>> filtered/escaped properly it should be fine because you force the data
>> to play by your rules.
>
> I'm not talking about escaping/filtering. I'm talking about variable overriding.
>
> In the past, it was
>
> $_GET['foo']
> $foo
>
> register_globals fixed that.
>
> however, if your app is relying on
>
> $_SESSION['username'] or $_COOKIE['username'] or something like that,
> depending on the variables order, it can be overridden.
>
> I don't see why if you -know- you need $_COOKIE['username'] someone
> would be lazy and use $_REQUEST['username']
>
> It winds up allowing the end user to override information themselves
> (again, depending on the variables order) which depending on that and
> how poor the code is (which to me if you're relying on $_REQUEST
> you've probably got some bugs and exploitable holes in there) creates
> a security risk.
>
> and session vars are in $_REQUEST, I tried it to sanity check myself
> before posting this :)

Well, either your sanity or your PHP is broken. Session vars are not in
$_REQUEST. The session ID may be because it might be in a cookie var
which is in $_REQUEST.

-Shawn

On Mon, Jul 7, 2008 at 2:47 PM, mike <mike503@gmail.com> wrote:
>
> I don't see why if you -know- you need $_COOKIE['username'] someone
> would be lazy and use $_REQUEST['username']

That's the point --- it's intended as a fallback where you *don't*
know the method that will be used, or if you want to be lackadaisical
with your code (which, as we all know, is HIGHLY unrecommended).

So if you are an application service provider (ASP) who, perhaps,
runs a simple word shuffling script, with no database, email, or other
externally-processed services, you may have a script like so:

<?php

$word = $_REQUEST['word'];

echo str_shuffle($word)."<br />\n";
?>

Because, in this case, it really doesn't matter if $word is
obtained via GET or POST, so you can allow external users to use your
service via an HTTP POST form or a plain URL.

Conversely, it can also be used as a login mechanism or other
secure system, if you know what you're doing with regard to EGPCS
(which I mentioned to the wrong poster before! :-\) and proper secure
coding techniques. It will go through a matter of precedence, which
can be useful in some (rare) circumstances.

--
</Daniel P. Brown>
Dedicated Servers - Intel 2.4GHz w/2TB bandwidth/mo. starting at just
$59.99/mo. with no contract!
Dedicated servers, VPS, and hosting from $2.50/mo.

On Mon, Jul 7, 2008 at 2:55 PM, Shawn McKenzie <nospam@mckenzies.net> wrote:

> mike wrote:
>
>> On 7/7/08, Eric Butera <eric.butera@gmail.com> wrote:
>>
>> Laziness/convenience.
>>>
>>> I always get my data from the exact source I want. If someone chooses
>>> to use REQUEST it shouldn't break their application. You say it is a
>>> security risk, but not really. As long as everything is
>>> filtered/escaped properly it should be fine because you force the data
>>> to play by your rules.
>>>
>>
>> I'm not talking about escaping/filtering. I'm talking about variable
>> overriding.
>>
>> In the past, it was
>>
>> $_GET['foo']
>> $foo
>>
>> register_globals fixed that.
>>
>> however, if your app is relying on
>>
>> $_SESSION['username'] or $_COOKIE['username'] or something like that,
>> depending on the variables order, it can be overridden.
>>
>> I don't see why if you -know- you need $_COOKIE['username'] someone
>> would be lazy and use $_REQUEST['username']
>>
>> It winds up allowing the end user to override information themselves
>> (again, depending on the variables order) which depending on that and
>> how poor the code is (which to me if you're relying on $_REQUEST
>> you've probably got some bugs and exploitable holes in there) creates
>> a security risk.
>>
>> and session vars are in $_REQUEST, I tried it to sanity check myself
>> before posting this :)
>>
>
> Well, either your sanity or your PHP is broken. Session vars are not in
> $_REQUEST. The session ID may be because it might be in a cookie var which
> is in $_REQUEST.
>
> -Shawn
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Where I see this used a lot is in searching/pagination type scenarios...for
the submission, the form is POSTED and then on subsequent pages, the data is
stored in the url and posted back to the same script. Using $_REQUEST means
that you won't really care about whether the data is POST or GET.

--

Bastien

Cat, the other other white meat

On 7/7/08, Daniel Brown <parasane@gmail.com> wrote:

> That's the point --- it's intended as a fallback where you *don't*
> know the method that will be used, or if you want to be lackadaisical
> with your code (which, as we all know, is HIGHLY unrecommended).

Then you should code for that, not fallback to a lazy overrideable option.

if(isset($_GET['foo'])) { $foo = $_GET['foo']; } etc ...

or

$foo = array_merge($_GET['foo'], $_POST['foo']) or something like that.

> Because, in this case, it really doesn't matter if $word is
> obtained via GET or POST, so you can allow external users to use your
> service via an HTTP POST form or a plain URL.

Then code for it :P I understand the idea, I don't see the need to
create a dedicated construct in PHP for it. Part of PHP's power to me
was finally getting away from the lazy ASP (VB-based)
Request.Value('foo') or whatever it was and not able to identify if it
was post, get, etc and making the coder define exactly what source of
data he's getting it from.

On Mon, Jul 7, 2008 at 3:08 PM, mike <mike503@gmail.com> wrote:
>
> Then code for it :P I understand the idea, I don't see the need to
> create a dedicated construct in PHP for it. Part of PHP's power to me
> was finally getting away from the lazy ASP (VB-based)
> Request.Value('foo') or whatever it was and not able to identify if it
> was post, get, etc and making the coder define exactly what source of
> data he's getting it from.

What your saying makes sense, Mike, and is the preferred method of
doing things.... however, that doesn't invalidate the reason $_REQUEST
exists. Your initial email asked why it was there, not why some
people consider themselves programmers and rely on cheats and hacks
like that. ;-P

--
</Daniel P. Brown>
Dedicated Servers - Intel 2.4GHz w/2TB bandwidth/mo. starting at just
$59.99/mo. with no contract!
Dedicated servers, VPS, and hosting from $2.50/mo.

mike wrote:
> On 7/7/08, Eric Butera <eric.butera@gmail.com> wrote:
>
>> Laziness/convenience.
>>
>> I always get my data from the exact source I want. If someone chooses
>> to use REQUEST it shouldn't break their application. You say it is a
>> security risk, but not really. As long as everything is
>> filtered/escaped properly it should be fine because you force the data
>> to play by your rules.
>
> I'm not talking about escaping/filtering. I'm talking about variable overriding.
>
> In the past, it was
>
> $_GET['foo']
> $foo
>
> register_globals fixed that.
>
> however, if your app is relying on
>
> $_SESSION['username'] or $_COOKIE['username'] or something like that,
> depending on the variables order, it can be overridden.
>
> I don't see why if you -know- you need $_COOKIE['username'] someone
> would be lazy and use $_REQUEST['username']
>
> It winds up allowing the end user to override information themselves
> (again, depending on the variables order) which depending on that and
> how poor the code is (which to me if you're relying on $_REQUEST
> you've probably got some bugs and exploitable holes in there) creates
> a security risk.
>
> and session vars are in $_REQUEST, I tried it to sanity check myself
> before posting this :)

I do agree with your distrust of $_REQUEST though. I doubt that it will
be removed as many applications probably use it. It comes down to
secure coding.

It is required to know where from you are getting data (post or get),
because it's not valid to perform an action (other than retrieval) based
upon a get request, hence the name GET. You should only perform actions
(insert, update, delete, whatever) with POST (or PUT, DELETE if available).

-Shawn