Posted by gbbulldog on 08/30/06 07:41

WhatsPHP wrote:
> Thanks for all your input on security guys i will certainly keep it in
> mind, but this is an inhouse intranet application and the users who use
> the system barely know how to use it, let alone hack it.. That is the
> reason we had register_globals on. This system maybe internal and on
> the intranet but it has around 20 people using it full time (so it is
> not small)..
>
> We have register_globals on.. What is still bugging me is the totally
> random occurence of this error.. has anyone experienced IE behaving
> weird by not posting all the form variables, both hidden and non-hidden
> as it should?

If the JavaScript fails at any time and you're relying on using an
"onSubmit" check to validate the data, the data won't be validated at
all! Validation is not just a question of security - it's good practice
to stop your scripts from failing, esp. when working with databases.

Again, the inherant problems with having register_globals on aren't all
security related, either. When it's turned on, $_POST['name'] would be
the same as $_GET['name'], which is the same as $name - all sorts of
bother!

Another problem with having register_globals on is session
over-writing. Say you authenticate a user and store the user's id in
the session variable $_SESSION['id']. If you then assign the variable
$id with a value anywhere else on a page which the user visits,
$_SESSION['id'] will be over-written with $id!

I know it's a pain to alter your scripts and change over to a system
which doesn't rely on register_globals being on, but in the long run
it's much better if you learn to use the super-globals.

[Back to original message]