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!
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;
> 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.:
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.
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.
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:
