register_globals on / off - I think I'm missing the point

I understand that register_globals 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 24 Oct, 11:57, +mrcakey <mrca...@nospam.nospam> wrote:
> I understand that register_globals 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("array_of_admin_users.inc.php");
if (in_array($admin_users, $_SESSION['user'])) {
$admin_user=true;
}

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.

"C. (http://symcbean.blogspot.com/)" <colin.mckinnon@gmail.com> wrote in
message news:1193224500.133773.53850@e9g2000prf.googlegrou ps.com...
> On 24 Oct, 11:57, +mrcakey <mrca...@nospam.nospam> wrote:
>> I understand that register_globals 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("array_of_admin_users.inc.php");
> if (in_array($admin_users, $_SESSION['user'])) {
> $admin_user=true;
> }
>
> if ($admin_user) { ...

based on that code, nothing.

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

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

m> What I don't understand is how the $_POST['foo'] form is any more
m> secure.

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

m> Surely Mr Malicious Coder can still just send his own version
m> of $_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.

m> Obviously 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 <anrdaemon@freemail.ru>

AnrDaemon wrote:
> Greetings, +mrcakey.
> In reply to Your message dated Wednesday, October 24, 2007, 14:57:09,
>
> m> I understand that register_globals was turned off by default as, unless
> m> you initialised it, it could be altered by a malicious coder.
>
> m> What I don't understand is how the $_POST['foo'] form is any more
> m> secure.
>
> It is more secure, than $foo. For sure.
>
> m> Surely Mr Malicious Coder can still just send his own version
> m> of $_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.
>
> m> Obviously 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_globals 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

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

> Essentially then register_globals 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.

On Oct 24, 3:57 am, +mrcakey <mrca...@nospam.nospam> wrote:
>
> I understand that register_globals 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_globals = 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("DELETE FROM the_table WHERE bar='$bar'");
}
// Tons of code here too...

Now let's say that register_globals = 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_globals = Off it is still safe (the malicious user cannot
initialize $bar and thus alter the program flow), while with
register_globals = On it is a security risk.

Cheers,
NC

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

On Oct 31, 6:44 pm, gordonb.kw...@burditt.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