(I apologize for a stupid question. This must be a simple setting, but an hour of Google hasn't revealed it.)
We have a LAMP web server. When we send data through post, the $_POST variable is set as expected. But we also get a global variable for every entry in $_POST.
For instance, if $_POST['Research'] is "Yes", we also get a global $Research set to "Yes".
How do we turn this off?
you have the dangerous and deprecated
register globals on
basic details:
http://php.net/manual/en/faq.using.php#faq.register-globals
to turn off:
http://php.net/manual/en/ini.core.php#ini.register-globals
if your php version is so old that it came with this on by default you should upgrade
Your description sounds like you are using register globals?
If so I am surprised you are still able to as they are deprecated.
You should update your php or at least disable it in your php.ini conf - register_globals=0;
Related
At my workplace, we have used a piece of code stored a remote server to do our Clickbank searches. Now my boss has decided to move everything over to our servers and has given lucky (heh) me the job to do it.
Now, I always thought that an $_GET variable needs to be declared within the local scope: $var = $_GET['var']; but in this code, it seems that the original programmer has just inserted the line right in, he's using $var in the code without declaring it... how is that possible?
It sounds like register globals is turned on. Register globals scopes all request variables locally, so that would be possible. It's also a very insecure feature that has been deprecated in PHP since version 5.3.
I would strongly recommend turning register_globals off and declaring locally scoped variables manually so you can properly deal with sanitizing and filtering of incoming data.
More on register_globals and why it is a bad idea at the official PHP documentation: http://php.net/manual/en/security.globals.php
It's probably because the php setting register_globals is set.
This means, a $_GET['foo'] is automatically available as $foo in your code.
See more about it here:
http://www.php.net/manual/en/ini.core.php#ini.register-globals
Basically this is a very big security hole and should be avoided.
Additionally it's deprecated since 5.3 and will be removed in 5.4.
You can find your answer in this link + a short and sweet definition about register_globals.
What are register_globals in PHP?
I was reading something about SuplerGlobals like $_SERVER or (see more detail PHP Manual Superglobals) the other day, now, I'm asking me:
Is it possible to implement own SuperGlobals?
Beside of Constants...
So for example user A writes something in the Variable which, if User B is calling it can see.
Something like a server wide Session Variable or something.
Please don't be to hard, if its a silly question :)
I know there are couple of ways outside, like SQL, Xml and Stuff, but maybe...
Your whole idea of PHP superglobals it wrong.
These variables are always available in terms of just one script runtime, no the whole site.
PHP doesn't have context which can be shared between users. You should some replacement like SQL server or file. You may also check some extensions like memcache which might help you achieve your goal.
I was reading something about SuplerGlobals like $_SERVER or (see more detail PHP Manual Superglobals) the other day, now, I'm asking me:
Is it possible to implement own SuperGlobals? Beside of Constants...
Yes it is possible if you've got the PHP runkit extension.
So for example user A writes something in the Variable which, if User B is calling it can see
That's not what superglobals do - they are variables which exist in global scope (i.e. for the duration of an instance of a script).
If you want to share data between different invocations then you need to send it to your storage tier or (in the case of data for a single client) out to the browser.
Since what you are describing here is effectively a shared session, then the sensible place to implement this would be in the session handler.
This is not possible, you can only see your own session data.
To achieve this you would need to store the data somewhere else. in text files or in a MySQL database would be the most common.
i suppose you can use (asterix)export yourvar="something"(asterix) and to receive it using getenv
sry, dont know how to embed asterix=`, but it is better to avoid it...
If you use apache following could be used:
http://php.net/manual/en/function.apache-setenv.php
same idea, enveroinment variable
I'm working on application built years ago, that has recently stopped working correctly. Old programmer said, that he might be accessing $_GET or $_POST variables without reading them from $_GET[] array, but through the register_globals
I want to ask: What are different ways to access $_GET variables without using $_GET[] array (e.g. direct ways?) and, if known, how can I check if this application uses any of them?
Thank you in advance
EDIT: The other ways I remembered was register_globals, not magic_quotes. Also, I do not wish to use it, but rather detect if it was used and in latest server update deprecated (what could explain why app stopped working correctly)
EDIT: My english is horrible today. As I explained in one of answers: I need to check, whether original programmer used some obscure and/or deprecated method of getting variables from query string to PHP, so the values application now works with are wrong/not initialized
IMPORTANT EDIT: import_request_variables is off the table, it isn't used. All $_ arrays are off the table too, because latest update wouldn't broke them (=>they still work). How can I detect what variables are initialized with register_globals?
YET ANOTHER EDIT: I found this:
foreach ($_POST as $k => $v) {
eval("\$".$k." = '".$v."';");
}
foreach ($_GET as $k => $v) {
eval("\$".$k." = '".$v."';");
}
Could it have been broken by one of latest updates (max. 1 week ago)?
You mean through Register Globals and not Magic Quotes... BTW Register Globals is pure evil never use them (and they are deprecated as of PHP 5.3.0)!
Edit: If you want to check if the application used Register Globals, try to search for $_GET values as variables. For example for index.php?id=123 try to look for $id in the PHP code. If you find it this does not mean that the script uses Register Globals but if $id comes from nowhere and is never initialized/setted it's a good (bad!) sign that the app uses Register Globals...
$_SERVER["QUERY_STRING"] will give you the raw GET string.
That said, this sounds like a problem that should be fixed at its root, not by using a different variable.
If magic quotes are an issue, do a check for whether they are enabled, and deal with the incoming data accordingly.
The Disabling Magic Quotes page in the PHP manual shows a way to "fix" the incoming data depending on whether the functionality is activated or not. It's not very efficient for huge amounts of data, but should do in an everyday task.
You also have $_REQUEST, magic_quotes (deprecated) would only influence the content of the variables, not the means of capturing them.
Also see import_request_variables, the original coder may have used it to grab the contents of a GET variable and insert it into another variable which is then subsequently being referenced.
Register Globals is a horrible feature that older PHP programs often rely on.
With register globals switched on, PHP will look at the GET and POST variables and "promote" them to normal variable names - eg $_GET['myvar'] would be accessible in the code as $myvar.
Among other issues, this makes the program very easy for hackers to break simply by guessing what other variable names the programmer may have used. The register globals feature has therefore been turned off by default for a long time, is now officially deprecated, and will be removed entirely in a future version.
Because the variables used this way are referenced in a way that is indistinguishable from normal variables, it means that trying to update old code that uses register globals can be very difficult. It does depend a lot on how well written the code is.
The problem is probably PHP's register_globals. This option makes $_GET['some_var'] or their equivalent $_POST version available as $some_var automatically. This is deprecated and you should definitely not use it, but the other programmer might have used them in that application.
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
This is register_globals. DO NOT use this; it is a gaping security hole.
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.
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.
I think you need set resister_global=on in php.ini
I have an admin site that I have copied over to a new server to test for bugs and put live, along with some other sites.
The admin appears to have REGISTER GLOBALS on and is using it for most of the 300 php files.
Based on the fact that you have to login to this system anyway is it worth the weeks of work to re code all the variables?
Or be happy that I would fix each page as I add any new feature to it in the future?
Does Register Globals leave problems in code that has been cleaned, if we don't fix all at once?
I'm guessing it could as $user_id can be set by any global.
This app could be littered with many other shoddy programming practices as well. (How large is the app to warrant 300 php files?). If that's the case, it might be a good idea to leave the app as it is and code a new version from scratch on top of a decent framework if maintenance has already become too troublesome.
I would disable register_globals from the php.ini, and put a code block at the top of each script that extracts the variables from the $_REQUEST, $_GET or $_POST, something like:
$nVars = extract($_GET, EXTR_SKIP);
The above code will register variables by the same name as the key in the passed array. It is useful for quickly refactoring old REGISTER_GLOBALS enabled code, but you must be careful. Read the following excerpt from the PHP extract() documentation:
Do not use extract() on untrusted
data, like user-input ($_GET, ...). If
you do, for example, if you want to
run old code that relies on
register_globals temporarily, make
sure you use one of the
non-overwriting extract_type values
such as EXTR_SKIP and be aware that
you should extract in the same order
that's defined in variables_order
within the php.ini.
Register_Globals is insecure and shouldn't be used. If I were you I would rewrite the code, or the application itself from scratch. However if this is an admin system, and no one knows its URL and therefore only the admin himself can access it, then you should be fine with not changing it (just make sure its URL remains a secret)
It can lead to some very serious security issues, it kinda depends on how it's coded.
For example:
<?php
// $loggedin comes from $_SESSION['loggedin']
if($loggedin)
{
echo 'Loggedin!';
}
else
{
echo 'Please login';
}
?>
The main problem here is, is that the script doesn't check where $loggedin comes from. So if I would do script.php?loggedin=1, I would be logged in. Seeing as there are ~300 PHP files, it would be hard to check everything.
So keeping it is a (very) bad idea. Even it you'd use .htaccess to block access, it would probably lead to problems in the future (IE web hoster setting REGISTER_GLOBALS off) and confusion.
Don't re-write the entire system. If the system works and you'll casually upgrade as you go you don't need to start from scratch.
I would weigh the importance of addressing the Register Globals based on the sensitivity of the information.
If it's a well built system you should be able to see what variables are used throughout the site and simply make them available at the top of the pages. Be wary of any functions that pull in their data through global $this, $that;
My vote, if the data is important to protect, is to do the work.
This depends on your quite a lo t of things. Just to name a few:
Company's security policy
Cost to rewrite
Importance of the application
Impact on other parts of the application.
etc