register_global s on / off - I think I'm missing the point

[+mrcakey]

I understand that register_global s was turned off by default as, unless
you initialised it, it could be altered by a malicious coder.

What I don't understand is how the $_POST['foo'] form is any more
secure. Surely Mr Malicious Coder can still just send his own version
of $_POST['foo']?

Obviously I'm missing something, I just can't figure out what!

+mrcakey

[C. (http://symcbean.blogspot.com/)]

On 24 Oct, 11:57, +mrcakey <mrca...@nospam .nospamwrote:

I understand that register_global s was turned off by default as, unless
you initialised it, it could be altered by a malicious coder.

What I don't understand is how the $_POST['foo'] form is any more
secure. Surely Mr Malicious Coder can still just send his own version
of $_POST['foo']?

Obviously I'm missing something, I just can't figure out what!

+mrcakey

On its own, it probably isn't a big problem - its how it interacts
with the rest of the code e.g.:

<?php
require_once("a rray_of_admin_u sers.inc.php");
if (in_array($admi n_users, $_SESSION['user'])) {
$admin_user=tru e;
}

if ($admin_user) { ...

What happens when a non-admin users connects using
http://example.com/transfer_funds.php?admin_user=1 ?

See also http://pear.reversefold.com/dokuwiki...er_globals_bad

C.

[Steve]

"C. (http://symcbean.blogsp ot.com/)" <co************ @gmail.comwrote in
message news:11******** *************@e 9g2000prf.googl egroups.com...

On 24 Oct, 11:57, +mrcakey <mrca...@nospam .nospamwrote:

>I understand that register_global s was turned off by default as, unless
you initialised it, it could be altered by a malicious coder.

What I don't understand is how the $_POST['foo'] form is any more
secure. Surely Mr Malicious Coder can still just send his own version
of $_POST['foo']?

Obviously I'm missing something, I just can't figure out what!

+mrcakey

On its own, it probably isn't a big problem - its how it interacts
with the rest of the code e.g.:

<?php
require_once("a rray_of_admin_u sers.inc.php");
if (in_array($admi n_users, $_SESSION['user'])) {
$admin_user=tru e;
}

if ($admin_user) { ...

based on that code, nothing.

[AnrDaemon]

Greetings, +mrcakey.
In reply to Your message dated Wednesday, October 24, 2007, 14:57:09,

mI understand that register_global s was turned off by default as, unless
myou initialised it, it could be altered by a malicious coder.

mWhat I don't understand is how the $_POST['foo'] form is any more
msecure.

It is more secure, than $foo. For sure.

mSurely Mr Malicious Coder can still just send his own version
mof $_POST['foo']?

Yep, but You can't accidentally fetch it by using $foo somewhere in Your
script.
You should call $_POST['foo'] explicitly to deal with user input.

mObviously I'm missing something, I just can't figure out what!

Hope I've explained it enough to give You a point.
--
Sincerely Yours, AnrDaemon <an*******@free mail.ru>

[+mrcakey]

AnrDaemon wrote:

Greetings, +mrcakey.
In reply to Your message dated Wednesday, October 24, 2007, 14:57:09,

mI understand that register_global s was turned off by default as, unless
myou initialised it, it could be altered by a malicious coder.

mWhat I don't understand is how the $_POST['foo'] form is any more
msecure.

It is more secure, than $foo. For sure.

mSurely Mr Malicious Coder can still just send his own version
mof $_POST['foo']?

Yep, but You can't accidentally fetch it by using $foo somewhere in Your
script.
You should call $_POST['foo'] explicitly to deal with user input.

mObviously I'm missing something, I just can't figure out what!

Hope I've explained it enough to give You a point.

Essentially then register_global s exposes ALL your variables to attack
from outside rather than just those you're fetching explicitly from
$_GET, $_POST etc. I understand now. Thanks to all who replied.

+mrcakey

[larry]

On Oct 31, 9:36 am, +mrcakey <mrca...@nospam .nospamwrote:

Essentially then register_global s exposes ALL your variables to attack
from outside rather than just those you're fetching explicitly from
$_GET, $_POST etc. I understand now. Thanks to all who replied.

+mrcakey

Note: If you can't be sure your code is going to be always in a
globals off environment, it is recommended all variables used in the
script are initialized early on in the script (even the empty ones).
Also one gotcha with globals on is if you do $foo = $_POST['foo'];
don't initialize $foo until you've made sure $_POST['foo'] is empty.

[NC]

On Oct 24, 3:57 am, +mrcakey <mrca...@nospam .nospamwrote:

>
I understand that register_global s was turned off by default
as, unless you initialised it, it could be altered by a
malicious coder.

What I don't understand is how the $_POST['foo'] form is any
more secure. Surely Mr Malicious Coder can still just send
his own version of $_POST['foo']?

Obviously I'm missing something, I just can't figure out what!

What you are missing is a realization that with register_global s = On,
the malicious coder can initialize ANY variable, regardless of whether
the script expects to receive it via CGI.

Let's say, you have something like this:

// Tons of code here...
// The script processes incoming data and, depending on the
// program flow, may or may not initialize the $bar variable.
if (isset($bar)) {
$result = mysql_query("DE LETE FROM the_table WHERE bar='$bar'");
}
// Tons of code here too...

Now let's say that register_global s = On and malicious coder
submitted
$_REQUEST['bar'] = '%'. The server receives it and initializes $bar =
'%'. If $bar is not changed elsewhere, the script issues the
following MySQL query:

DELETE FROM the_table WHERE bar='%'

meaning, delete all records from the_table.

Granted, the above example is not a good coding practice, but with
register_global s = Off it is still safe (the malicious user cannot
initialize $bar and thus alter the program flow), while with
register_global s = On it is a security risk.

Cheers,
NC

[Gordon Burditt]

>DELETE FROM the_table WHERE bar='%'

>
meaning, delete all records from the_table.

No, that's not what it means.

DELETE FROM the_table WHERE bar LIKE '%'

means delete all records from the_table. The first query means delete
all records where bar is of length one and contains a single percent sign.

Lesson here: use = instead of LIKE unless you actually *need*
pattern-matching. Also, turn off register_global s.

[NC]

On Oct 31, 6:44 pm, gordonb.kw...@b urditt.org (Gordon Burditt) wrote:

>

DELETE FROM the_table WHERE bar='%'

meaning, delete all records from the_table.

No, that's not what it means.

DELETE FROM the_table WHERE bar LIKE '%'

means delete all records from the_table. The first query
means delete all records where bar is of length one and
contains a single percent sign.

You're right, of course. I just wanted a simple illustration, so I
misinterpreted the meaning of the SQL query to make a point. In the
real world, the attacker would use something like:

$_REQUEST['bar'] = "' OR bar LIKE '%"

Cheers,
NC