Why not write a routine to bypass register globals off?

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

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

[Ian.H [dS]]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Whilst lounging around on 12 Aug 2003 00:29:28 -0700,
pa*************@hotmail.com (Paul Liversidge) amazingly managed to
produce the following with their Etch-A-Sketch:

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.

Heh.. doesn't that just completely defeat the object of having
register_globals disabled!?

People should just learn to use the language _correctly_ and stop
trying to code like M$ and this problem would then go away. But
sadly, as M$ have just proved, people don't wan't to do things
properly, but more lazilly, thus causing loads of security problems.

What I don't understand, is what's so hard about using $_GET, $_POST,
$_SERVER arrays etc? Surely this also helps when reading and
maintaining the code too as you can see at a glance what data is for
what.

Regards,

Ian

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBPzjHQ2fqtj251CDhEQL1VACdGSkviE5pCdddJyt1hLlbTk D+YecAnRrS
NmWIKFiVtgCNZdAPY442mIv0
=wRBS
-----END PGP SIGNATURE-----

--
Ian.H [Design & Development]
digiServ Network - Web solutions
www.digiserv.net | irc.digiserv.net | forum.digiserv.net
Programming, Web design, development & hosting.

[Bruce Lewis]

pa*************@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.

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

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

[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

[Phil Roberts]

With total disregard for any kind of safety measures
pa*************@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.....

[Paul Liversidge]

Phil Roberts <ph*****@HOLYflatnetSHIT.net> wrote in message news:<Xn*************************@216.196.97.132>. ..

With total disregard for any kind of safety measures
pa*************@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