Re: Looking for a reasonable explanation as to why $_REQUEST exists

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Jul 7, 2008, at 2:19 PM, Eric Butera wrote:

On Mon, Jul 7, 2008 at 2:47 PM, mike <mike503@xxxxxxxxx> wrote:
On 7/7/08, Eric Butera <eric.butera@xxxxxxxxx> 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 :)


Usually from what I've seen $_REQUEST is a lazy way to get an id from
either a post or a get.  Say you show a form and the url is
page.php?id=x and then you post said page it might include a hidden
form field called id so using request you don't have to worry about
how to load your record back based on get or post.  I'm not saying it
is right, but that is how a lot of people use it.  If your app is
written correctly it doesn't matter what is thrown at it, it should
always work.  Even if a variable gets overridden it should still be
forced to play with the rules of the app and work like a valid request
does.

I think that having a set of if statements that say something like the
following is silly.
if (isset($_POST['id'])) {
} else if (isset($_GET['id'])) {
}

Try the shorter if/else...

$id = isset ($_POST['id']) ? $_POST['id'] : $_GET['id'];

Or, if you wish for _GET to have precedence...

$id = isset ($_GET['id']) ? $_GET['id'] : $_POST['id'];

Happy coding.

~Philip

PS... Not a fan of _REQUEST because... well, it's longer to spell than _POST and _GET! =P



The id should always be a get parameter since it is part of the
request to build the state, not the state itself.  So on my stuff if I
need an id lookup, that is always going to be a GET.  My post action
will be save?id=x.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux