How to get $_GET variables in PHP - php

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.

Related

"Do not Access Superglobal $_REQUEST Array Directly." Netbeans 8.0 PHP

This questions is being asked after having read a few others.
Do not access superglobal $_GET array directly
“Do not Access Superglobal $_SERVER Array Directly” on Netbeans 7.4 for PHP
Why is filter_input() incomplete?
I have loaded up the latest version Netbeans 8.0 and I have seen a warning
Do not Access Superglobal $_REQUEST Array Directly.
Great, I am happy to be shown when I am doing something which can be improved upon, so I look at the hints.
The suggestion is quite simple.
Use some filtering functions instead (e.g. filter_input(), conditions
with is_*() functions, etc.).
So I start looking into fliter_input() however it is not yet implemented for $_REQUEST. This seems like a little bit of a dead end.
Then I read something which was quite helpful from (#bobince) "At the start of your script when you're filtering, you don't know where your input is going to end up, so you don't know how to escape it."
It reminded me, I know exactly where my input is going to end up, and exactly what it will be used for. So, I wanted to ask everyone if the approach I am going to take is essentially safe.
I am designing a REST-ish API and I am using $_SERVER['REQUEST_METHOD']; to determine the resource which needs to be returned. I am also using $_REQUEST['resource']; which should contain everything on the URI after /api/ following the .htaccess rewrite.
The questions I have about my approach are:
If I always validate $_SERVER['REQUEST_METHOD']; to be within the required GET PUT POST DELETE (which i will need to do anyway), is there really a problem not filteing the input?
Should I be accessing the $_REQUEST['resource']; by using filter_input (INPUT_GET, 'resource');? When this will only be used to determine a resource, and where the resource can not be determined (say someone attempts to add malicious code) we will simply not find a resource and return a 404 Not Found status.
Are there any other considerations I need to take into account and have I missed anything critical in my understanding?
I realise, this may seem like a lot of concern for what is only considered a warning however, in my experience, fixing just the errors will give you working code, but fixing the warnings will help you understand why the code works.
So I start looking into fliter_input() however it is not yet implemented for $_REQUEST. This seems like a little bit of a dead end.
I'd say it is not a dead end but on purpose. filter_input() requires you to clearly specify the input type. $_REQUEST is not clear about it, it contains input from various sources, allowing one source overwriting another.
Next to that this is also not what the warning precisely wants to tell you. Swapping a superglobal like $_GET with an equally superglobal function like filter_input(INPUT_GET, ...) shows the same design flaw. But Netbeans can't warn you as easily about it.
And getting rid of superglobals is already a good idea.
Instead, inject input data to your application at a low-level place, e.g. bootstrapping the request information and do not use any superglobals nor the filter_input function in the rest of your code.
That will allow you to easily simulate any request method without even having an actual request.

PHP $_GET not declared

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?

Why does WordPress still use addslashes(), register_globals() and magic_quotes?

In order to gain more experience in Wordpress I delved into its code base to study its inner working and its workflow, and I was quite astonished when I saw that:
They implement register_globals (an excerpt from wp-includes/class-wp.php):
// The query_vars property will be extracted to the GLOBALS. So care should
// be taken when naming global variables that might interfere with the
// WordPress environment.
function register_globals() {
global $wp_query;
// Extract updated query vars back into global namespace.
foreach ( (array) $wp_query->query_vars as $key => $value) {
$GLOBALS[$key] = $value;
}
They rely on magic quotes (exerpt from wp-includes/functions.php. magic_quotes_gpc is turned off at bootstrapping, before calling this function):
function add_magic_quotes( $array ) {
foreach ( (array) $array as $k => $v ) {
if ( is_array( $v ) ) {
$array[$k] = add_magic_quotes( $v );
} else {
$array[$k] = addslashes( $v );
}
They rely on addslashes (but since 2.8.0 they introduced also mysql_real_escape_string, but the _weak_escape() function that uses addslashes() still exists in the wpdb class)
UPDATE: I see they emulate prepared statements by using sprintf() and custom placedholders, so queries should be safe I think. Still I'm puzzled on why they don't provide at least mysqli, after all the detection of Mysql and PHP version happens early in the bootstrapping sequence.
Now, from the year-long frequentation of SO I learned a lot of things, especially that the above three function are "deprecated" and show security issues, and are watched in horror by many.
But WP must have a reason to use them. I'd like to know from more experienced programmers if there are really security issues, or if sometimes their usage is just too clouded in rumors and false convinctions. I know that magic_quotes is an heritage from the past, and the same could be said for addslashes (at least when used for databases), but while googling before asking this I found many websites talking about using addslashes() over mysql_real_escape_string().
I'm interested in knowing a clear, detailed reason on why those badly depicted functions are used; Wordpress had had many improvements over the years, addressing different aspects, and yet these functions are still used; I'm looking, therefore, to a concrete explanation over the positive aspects that somehow override the negative ones and justify the usage of those functions.
I'm not looking for opinions (I perfectly know they're offtopic here), nor I am ranting about Wordpress, I hope this is clear. I'd just like to know why many php programmers consider these functions "bad", and yet a worldwide giant like Wordpress, who's at the 3rd version now, still uses them.
Is this for compatibility with different servers and php versions? (they check very earl for those, though).Is there something I miss about this functions, how important they can be in an environment like wordpress (or in general)? I'm quite confused, to be honest.
(Wordpress Open Tickets over Time)
Don't rely on the Wordpress codebase to do assumptions about good practice or current standards in PHP coding. I'm saying this as someone who has fiddled with wordpress development over a longer period of time.
Wordpress codebase is about 10 years old, it's full of legacy code[1]. The program can not evolve on the code-level much because of that, so you find a lot of workarounds for problems that are already solved nowadays much better.
Just take this story: PHP had magic quotes. Wordpress developers thought it was useful. So for those hosts that did not have it configured, they added it. Ending up whith code that expects slashed input data often and at various places. The simple thing is, now they just can't change it to proper input processing and sanitization easily because of the usage of (super)globals introducing static global state nearly everywhere.
You can not easily refactor such code.
Same for the database class. It has a long history, originally based on an early version of ezSQL. At that time there was not mysql_real_escape_string and when it was introduced, the WP devs had the problem that not all installation bases support it.
So don't wonder about the coding practice you find inside the Wordpress code. You'll learn how things could have been done years ago and with more or less outdated PHP versions. It's not that long ago that Wordpress switched to PHP 5 for example.
Backwards compatibility.
Target a large amount of (technically more or less outdated) hosts.
Don't break what works with defects.
This might not be your list of priorities (hopefully), projects differ here a lot. But having a legacy code-base alone is a burden regardless how project priorities are set. Wordpress is only one example.
[1] see Milestones of WordPress: Early Project Timeline (ca. 2000 to 2005))
In complement to #tom answer.
Magic Quotes
Automatically parsing the whole entries and adding magic quotes is both creating bugs and useless.
Useless as you cannot rely on magic quotes to secure your input (multy-bytes encoding bugs for SQL injections is an example). So you need to apply a real filter before saving your data to a database
Creating bugs: If you need to really escape your data before a save in database you have to check that it's not already escaped (and the simple fact this settings exists and may be enforced by the hosting environment makes that you have to check this setting was set or not).
Creating bugs: All the data sent by the user is not always dedicated to a database storage. Escaping it may break the content, think about a json content for example, or even file content with the dangerous magic_quote_runtime
Creating bugs: All database storage are not escaping quotes the same way...
So Why?, why do we see such function in a CMS?
see that here it's an add_magic_quotes function, that can be used on a dedicated array, maybe not on _GET or _POST. But effectively the fact this function is just using addslashes and not a database dedicated function makes it quite bad.
The fact the hosting provider may enforce an automatic magic quotes is a nightmare for a CMS developper. Either you detect it and tell the user you refuse to run, or you have to manage the fact the content may or may have not be magically-addslahed... and to put everyone in the same state, you run the non-addslashed content in this function so that at least everyone is in the same (bad) state.
From what I can see on Wordpress, before the save a stripslahes_deep is performed in the wp_insert_post. And add_magic_quotes is usually performed on data pulled from Db before this data is send to the wp_insert_post. This may me think the problem is effectively to add slashes before removing them... maybe because sanitize filters which happen before the save expect content with slashes, or maybe because no one remember why the code is running in this way :-)
register_globals
Seems that this is the way to implement a Registry pattern in wordpress... They wanted to make the code simple to understand, and to allow a simple way to access importants objects like the query or the post. And an object oriented Registry class was not in the simple PHP way, where the $_GLOBALS array is already an existing registry.
Having a Registry is a perfectly valid thing in an application. a register_global thing is dangerous only if you allow some user input to override your valid secure input. And of course only if this secure input is taken from $_GLOBALS elsewhere (or with global keyword).
The dangerous part in the function here is the part of the function you have extracted, the loop on $query->query_vars. You will have to track the calls to see if user injected keys could run throught wp_parse_args and end in that function. But the next part of this function is fixing $_GLOBALS content for several objects:
$GLOBALS['query_string'] = $this->query_string;
$GLOBALS['posts'] = & $wp_query->posts;
$GLOBALS['post'] = (isset($wp_query->post)) ? $wp_query->post : null;
$GLOBALS['request'] = $wp_query->request;
So at least theses globals cannot be overwritten by user input and are safe.
So, theses functions are bad. But you can use them if you understand what they do and what you need to do to prevent the bad effects. And when you want to implement a simple framework for developpers, available on a very wide environments you sometimes have to use them.
But for sure it's a bad practice, you can certainly find bad wordpress plugins using $_GLOBALS in the wrong way or misusing the add_magic_quotes to data pulled from db wordpress concept. But there will be years before a Zend Framework CMS gained such a big number of contributions.
Magic Quotes
The following text is taken from PHP.net
http://www.php.net/manual/en/security.magicquotes.why.php
There is no reason to use magic quotes because they are no longer a supported part of PHP. However, they did exist and did help a few beginners blissfully and unknowingly write better (more secure) code. But, when dealing with code that relies upon this behavior it's better to update the code instead of turning magic quotes on. So why did this feature exist? Simple, to help prevent SQL Injection. Today developers are better aware of security and end up using database specific escaping mechanisms and/or prepared statements instead of relying upon features like magical quotes.
addslashes() vs mysql_real_escape_string()
The reason why you should use mysql_real_escape_string() is because it's a "MySQL function" and is created especially for escaping user input before it's executed in a mysql query, while addslashes() is a "PHP function". That probably sounded a little weird, but there's one important difference between the two and it has to do with the use of single- and multi-byte characters. You can still inject databases protected by the addslashes function, but injecting databases protected by mysql_real_escape_string is far more difficult. You can read more about it HERE
Register Globals
The reason why you should NOT use register_globals is because variables become accessible to everyone, which means that in the following example you would be able to set $access to true if it hasn't been initialized before
<?php
if (isAuthenticated()) { $access = true; }
if ($access == true) {
include(controlpanel.php);
}
?>
The above code would give you sh#! loads of problems, but if we initialize the variable first by adding the following to the top of the page
$access = false;
...we should be fine even if we have register_globals ON
So, if the Wordpress team have initialized all variables (which they probably have) then you don't have to worry about the use of globals.
Conclusion
It's definitely bad practice using any of those 3 functions/features and I would never do it myself. Are you sure you're working with the latest version of Wordpress? Like someone commented, if you are using the latest version it's because of laziness or worse it's still in there. I'ld never use Wordpress for anything other than blogs that doesn't require much security..
Wordpress. I've spent a lot of sleepless nights trying to answer the only one question: "Why??"
Since I've faced with its source code I hate it. It is awful. And let my post(and reputation as well) will be minused but it's true.
It doesn't have core. There is a rubbish of code instead of core. It reminds php3. Huge heap of unrelated and unlogical functions are used in it. "Copy and Paste" - the only one design pattern is used in wordpress.
Yes, the have emulated using of prepared statements. But why they don't use PDO, or mysqli? They have copypasted almost all PDO functions but haven't use it instead. Using of mysqli instead of mysql requires even less efforts.
They use myql_real_escape_string. But there is still something like protect_string_strongly, protect_string_weakly. There is no only only one function - do_not_protect_string_i_believe_my_users.
Global variables - is the philosophy of wordpress. "If we don't know how to change this var we'll mark it as global var and everybody will be happy." - here is what wordpress developers thought when they developed hellpress.
Every new version contains a lot of new in design, they add new default themes, they change background color in admin area from #ccc to #cdcdcd, they use dropdown menu in admin area instead of accordeon. And it awesome. But they do not improve its code.
Did you read comments in WP "core"? No? And I did. They are "awesome". Something like "What this function is called for? Let's it leave just in case." or "Do not hardcode this in new version." and so on.
The only one answer to the question "Why?" I got is: "Because it works. And if it does work do not touch it!!!"
wordpress.org is one most visited sites in the world. Why? Because nobody able to understand wordpress's logic. Everybody every time needs to ask something on the forum or read in the codex.
I hope you understand my point of view.
There is no better way to answer why they are bad than referring to the PHP documentation on magic_quotes:
Why did we use Magic Quotes?
Why to not use Magic Quotes
Also note:
This feature has been DEPRECATED as of PHP 5.3.0. Relying on this feature is highly discouraged.
So why does Wordpress still use Magic Quotes?
Wordpress minimum requirements uses PHP 4.3. Yes, it is absolutely a backwards compatibility reason.
What about the other functions?
I am honestly not sure. Relying on super globals is a very bad idea. This is simply laziness of the Wordpress development team. Perhaps they have more important issues to work on.
They did this for one reason:
To make sure Wordpress is compatible with most Web Hosting providers.
This is wrong place to ask such a question.
It is always a bad idea to ask some third party person of the reasons someone else had somewhere else.
It is obvious that you can't get an answer here unless you will lure some authorized wordpress developer here with such a bounty.
Yet your question is too broad. However, it is possible to answer it's abstract part:
I'd like to know from more experienced programmers if there are really security issues, or if sometimes their usage is just too clouded in rumors and false convinctions.
Does hands washing really prevents a disease?
What if I won't wash my hands - will I surely sick?
Most of time - no.
As a general habit - yes.
These features (although indeed, as any other feature of our unlucky language, too clouded in rumors) are merely a hygiene everyone have to follow as a basic instinct.
Although most of time...
addslashes won't do any harm as long as your encoding is either utf-8 or any single-byte one;
register globals won't do any harm if you initialize all your variables;
magic quotes won't do any harm as long as you have all your variables quoted for the SQL and slashes stripped for any other use;
...any exception from these circumstances can make you sick with high probability.
One of the main differences between mysql_real_escape_string() and addslashes is that mysql_real_escape_string() works in conjunction with the character set so it knows how to properly escape data based on the character set.
Generally I think the best approach is to use a request class and do all your stuff there.
That way there is only one place where you deal with GET,POST,COOKIE, SERVER etc which makes it far easier to manage in contrast to having a bunch of random functions doing different things. That's just a recipe for disaster.

Own SuperGlobal Variable 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

Convert big php project from register_globals to _GET["param"]

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.

Categories