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?
Related
I have a settings.php page in my application which uses $GLOBALS to store configurations used in the web app.
As an example, he is a sample setting variable I use:
$GLOBALS["new_login_page"] = 1;
$GLOBALS["secret_cross_check_token"] = 3243242342423;
I then call those globals on other pages (hence why I use $GLOBALS), to perform tasks, such as give a user a new feature if they have that global toggled to 1.
The Question:
This works really well for me and i do not wish to use a database to store them, however recently I came to think, are $GLOBALS secure? Can a user read or manipulate them? If yes, what is the solution???
I understand it is server side but i just had doubts as to whether the user can somehow access the $GLOBALS
A globals variables can only be accessed server side, you can use them safely.
If an user can access your globals variables it's because he has gained access to execute code in your server, so, in this case, he can do a lot of more things than read your globals variables.
If an user can execute code in your server, he will be able to copy all your files and all your database easily, so the access to global variables would not be the major problem.
$GLOBALS is totally secure global variable.
http://php.net/manual/en/reserved.variables.globals.php
users have no access to it.
the "security" was about register_globals directive.
but its removed from php.
http://php.net/manual/en/security.globals.php
the point there was that, for example, i forgot to define some $includeFile as 'inc.php', and i was doing include $includeFile;, someone could just go http://mysite.ru/script.php?includeFile=http://hackersite.ru/script.php and include his own file.
not very good example but something "near".
But it is not about $GLOBALS, so u should not worry about security there.
sorry for english.
(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;
I have a rather big php site, which was written for php4 and register_globals enabled. It is old custom CMS. Now I want to run it on the php5 hosting without register_globals. Is it possible to change parameters parsing from $id to $_GET["id"] automatically, with some script?
I can get parameters names from wget -r on this site.
It have dozens of php scripts, and it is not very easy to do this change manually.
PS: UPDATE: I want to convert only GET variables. The additional line is $var_name = $_GET["var_name"] for each parameter. This line should be inserted very high in the script, e.g. by adding a new <? ?> section at very top.
Running such tool would introduce great risk of introducing errors in code.
I'd suggest running extract() on superglobals, so that you force register_globals and aplication will work properly.
http://php.net/manual/pl/function.extract.php
Next, when everything will be ok, write an OO wrapper for input parameters, pack it into nice DI Container and start manually transitioning whole script to the new style.
I don't know of any tools that help you in the conversion, but you have several options:
Simulate register globals by doing the same thing that register_globals did: At the beginning of the script, put all variables from GET and POST into the global variable namespace (i.e. via extract). While this is fastest and the most easy solution, it will lead to the security problems that register_globals was known for, and it doesn't help with the performance of your application
Determine the variables that are used and load them only via the init script into $GLOBALS only. Still not nice
Determine the variables that are used and replace the GLOBALS usage with REQUEST
Walk through it manually. This way, you can be sure everything is correct and will have the least trouble afterwards.
From your description, solution 1 or 2 might be the best for you since the cms doesn't seem to be updated anyway (which is a shame).
Although the actual finding/replacing might take more time, doing this manually will most likely result in less bugs / weird behaviour.
If are not the original author of the application, then this manual finding/replacing is also an opportunity for you to become much more familiar with the codebase than some automatic method.
Automatic: fast, almost definitely will result in some horrible bugs
Manual: slower (likely), almost definitely will result in better understanding, less bugs - and any bugs that are introduced will be easier to fix because of your better understanding.
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