tags:

views:

79

answers:

4

HI all

Running PHP Version 5.2.11 and we've been given a site which we're told was running on an earlier version (4 possibly).

We've an odd problem where several pages which have a bunch of forms which update the MySql are not working. The problem is where the variables used in the update script are not being defined anywhere in the php before hand. eg.

UPDATE users SET FirstName='$form_firstname'WHERE UserID='$id'"

Now if we change it to..

$form_firstname = $_POST['form_firstname'];
UPDATE users SET FirstName='$form_firstname'WHERE UserID='$id'"

then the update works. We could do this for every single variable defined in every update statement but I'm thinking that seen as this must have worked previously we're looking at some deprecated code somewhere that forms these variables. I've looked for any

import_request_variables

statements but nada.

Can anyone think of anything that would be turned off by default in a new server that would cause this or does this variable have to be declared somewhere?

Cheers muchly

+8  A: 

This is register_globals. DO NOT use this; it is a gaping security hole.

Ignacio Vazquez-Abrams
I adhere to this comment. Check it out: http://php.net/manual/en/security.globals.php
ign
Ah gotcha, so we need to manually chuck the $_POST's in then?
amjags
@Stu, not only that, you need to 1) escape them; or 2) use prepared statements.
chelmertz
Yes, it is always best to access `$_POST` and `$_GET` explicitly.
Ignacio Vazquez-Abrams
Cheers folks, great help.
amjags
http://xkcd.com/327/
fire
A: 

I think you need set resister_global=on in php.ini

Unnamed123321
Don't do this, it's outright dangerous!
middus
Yes - this is dumb.
symcbean
...and misspelt
symcbean
A: 

i hope you don't use that for something serious. That code is open to all kinds of intrusions, injections and hacks. I have two answers for you. Quick & dirty: turn register_globals on. Alternative: find someone to rewrite your app from scratch or find a better one.

stereofrog
Nothing serious and we're escaping the requests. The code's stripped down for example only. Cheers though.
amjags
A: 

As stated elsewhere, its because the original code was register_globals enabled - which is very bad practice.

As a quick hack you could add some code at the top of each page (in global scope):

extract($_GET); extract($_POST);

...which has much the same effect but on a script-by-script basis. But ONLY to keep the site running while you re-implement the code properly. Note that this is not the only problem with the code - splicing unchecked user input into SQL statements is a recipe for DISASTER.

You should be rewriting the code as....

$form_firstname = mysql_real_escape_string($_POST['form_firstname'], $db_handle);
$id = mysql_real_escape_string($_POST['id'], $db_handle);
$qry="UPDATE users SET FirstName='$form_firstname'WHERE UserID='$id'";

C.

symcbean
Cheers symcbean, yeah we noted the insertion risk on the code was just curious as to the register_globals issue. TBH looks like they need to get a lot of stuff redone. Thanks.
amjags