Why not write a routine to bypass register globals off?

I'd like your opinions as to why I don't use something like this...

A function that iterates through $_GET, $_POST, $_COOKIES and
$_SESSION arrays and turn them back into conventional variables. I
already have chunks of code at the top of some pages, particularly
large forms that look something like this...

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

....one line after another pulling the variable back from the array and
back into a more manageable variable name.

I know this could be done with a foreach loop and using eval
statements so why don't I. Is this being lazy? Or are there security
holes or other issues?

If you processed them in the order of GET, POST, COOKIES, SESSION then
you'd overwrite any hacked attempts to use GET in preference to a
cookie but I'm just struggling to see the sense in not doing it.

Opinions please.

Paul

paul_liversidge@hotmail.com (Paul Liversidge) writes:

> If you processed them in the order of GET, POST, COOKIES, SESSION then
> you'd overwrite any hacked attempts to use GET in preference to a
> cookie but I'm just struggling to see the sense in not doing it.

If those are the only variables you reference in your page, maybe so. I
don't know the workings of PHP well enough to say what happens if the
user does something like <input name="_SESSION[]">.

It still feels rather dangerous if you don't explicitly specify which
GET/POST inputs you're looking for...something analagous to BRL's
(define-input id ...)

--
"Notwithstanding fervent argument that patent protection is essential
for the growth of the software industry, commentators have noted
that `this industry is growing by leaps and bounds without it.'"
-- US Supreme Court Justice John Paul Stevens, March 3, 1981.

Working with those superglobal arrays is recommanded, that way you know
exacltly where your data is from. But if you really don't like it, or
need a quick fix, you might want to look over extract(), which turn
array elements into variables.

André Næss wrote:
> Paul Liversidge:
>
>
>>I'd like your opinions as to why I don't use something like this...
>>
>>A function that iterates through $_GET, $_POST, $_COOKIES and
>>$_SESSION arrays and turn them back into conventional variables. I
>>already have chunks of code at the top of some pages, particularly
>>large forms that look something like this...
>>
>>$id = isset ($_GET['id']) ? $_GET['id'] : "";
>>
>>...one line after another pulling the variable back from the array and
>>back into a more manageable variable name.
>
>
> EEEEK
>
> But what the heck, here it is: http://www.php.net/extract
>
>
>>I know this could be done with a foreach loop and using eval
>>statements so why don't I. Is this being lazy? Or are there security
>>holes or other issues?
>
>
> Might there possibly be a reason why everyone is recommending you to not use
> register globals. Hm. I wonder. ;)
>
> IMO you should stick to accessing _GET and friends directly because it makes
> it *very* obvious to yourself and others reading your code that *this data
> ain't safe!*
>
> André Næss

Paul Liversidge:

> I'd like your opinions as to why I don't use something like this...
>
> A function that iterates through $_GET, $_POST, $_COOKIES and
> $_SESSION arrays and turn them back into conventional variables. I
> already have chunks of code at the top of some pages, particularly
> large forms that look something like this...
>
> $id = isset ($_GET['id']) ? $_GET['id'] : "";
>
> ...one line after another pulling the variable back from the array and
> back into a more manageable variable name.

EEEEK

But what the heck, here it is: http://www.php.net/extract

> I know this could be done with a foreach loop and using eval
> statements so why don't I. Is this being lazy? Or are there security
> holes or other issues?

Might there possibly be a reason why everyone is recommending you to not use
register globals. Hm. I wonder. ;)

IMO you should stick to accessing _GET and friends directly because it makes
it *very* obvious to yourself and others reading your code that *this data
ain't safe!*

André Næss

Louis-Philippe Huberdeau:

> Working with those superglobal arrays is recommanded, that way you know
> exacltly where your data is from. But if you really don't like it, or
> need a quick fix, you might want to look over extract(), which turn
> array elements into variables.

Eh. Why do you reply to my posting by repeating precisely what I wrote?

André Næss

With total disregard for any kind of safety measures
paul_liversidge@hotmail.com (Paul Liversidge) leapt forth and
uttered:

> I don't read directly from the arrays as it makes the code look
> ugly, {$_GET['id']} doesn't look as concise as $id. Also the
> origin of a passed variable isn't significant.

It's of the UTMOST importance!!! You should ALWAYS know EXACTLY
where your inputted data is coming from, and always check
everything that a user enters into a script. Your kind of attitude
is exactly what leads to the major security flaws in popular
software products.


--
There is no signature.....

Phil Roberts <philrob@HOLYflatnetSHIT.net> wrote in message news:<Xns93D5EB1BF2546philroberts@216.196.97.132>. ..
> With total disregard for any kind of safety measures
> paul_liversidge@hotmail.com (Paul Liversidge) leapt forth and
> uttered:
>
> > I don't read directly from the arrays as it makes the code look
> > ugly, {$_GET['id']} doesn't look as concise as $id. Also the
> > origin of a passed variable isn't significant.
>
> It's of the UTMOST importance!!! You should ALWAYS know EXACTLY
> where your inputted data is coming from, and always check
> everything that a user enters into a script. Your kind of attitude
> is exactly what leads to the major security flaws in popular
> software products.

If you read the whole thread you'd realise that I move the global
variables into more aesthetically pleasing variable names. I like
readable code, $id is readable, {$_SESSION['id']} isn't, IMO.

The attitude that causes security flaws in software are conceited
programmers that can't think outside the box. I've been programming
for 23 years from multiple assembly languages up to and including most
high level languages. I also started my programming career as a hacker
so I'm more aware than most of how to exploit a system. Where my input
comes from doesn't effect the security design of my applications at
all as $_SESSION is the only source I trust but even then there is the
weakness of hijacking those sessions if your session handling routine
isn't good enough.

Paul