Reporte de Errores
Sorry the last php code I submitted was formatted nice but I changed some things for readability and didn't implement it across the board. Here is the correct code:
<?php
if (ini_get(register_globals)) {
$rg = array_keys($_REQUEST);
foreach($rg as $var)
{
if ($_REQUEST[$var] === $$var)
{
unset($$var);
}
}
}
?>
Uso de Register Globals
Warning
This feature is DEPRECATED and REMOVED as of PHP 6.0.0. Relying on this feature is highly discouraged.
Quizás el cambio más controversial en la historia de PHP se ha dado cuando la directiva register_globals pasó de tener como valor por defecto ON al valor OFF en PHP » 4.2.0. La dependencia sobre esta directiva era bastante común y muchas personas nisiquiera estaban enteradas de que existía y asumían que ese era el modo en que PHP trabajaba. Esta página explicará cómo puede llegar a escribirse código inseguro con esta directiva pero tenga en mente que no es la directiva misma la que es insegura sino el uso inapropiado de ella.
Cuando se encuentra activa, la directiva register_globals inyectará sus scripts con todo tipo de variables, como variables de peticiones provenientes de formularios HTML. Esto junto con el hecho de que PHP no requiere la inicialización de variables significa que es muy fácil escribir código inseguro. Fue una decisión difícil, pero la comunidad de PHP decidió desahibilar esta directiva por defecto. Cuando está habilitada, las personas usan variables sin saber con seguridad de dónde provienen y solo queda asumir. Las variables internas que son definidas en el script mismo son mezcladas con los datos enviados por los usuarios y al deshabilitar register_globals se modifica este comportamiento. Demostremos este caso con un ejemplo del uso incorrecto de register_globals:
Example#1 Ejemplo del uso inapropiado de register_globals = on
<?php
// definir $autorizado = true solo si el usuario ha sido autenticado
if (usuario_autenticado()) {
$autorizado = true;
}
// Ya que no inicializamos $autorizado como false, ésta podría estar
// definida a través de register_globals, como en el caso de GET
// auth.php?autorizado=1
// ¡De modo que cualquier persona podría verse como autenticada!
if ($autorizado) {
include "/datos/muy/importantes.php";
}
?>
Cuando register_globals = on, nuestra lógica anterior podría verse comprometida. Cuando la directiva está deshabilitada, $autorizado no puede definirse a través de peticiones, así que no habrá ningún problema, aunque es cierto que siempre es una buena práctica de programación inicializar las variables primero. Por ejemplo, en nuestro ejemplo anterior pudimos haber realizado primero algo como $authorized = false. Hacer esto representa que el código anterior podría funcionar con register_globals establecido a on u off ya que los usuarios no serían autorizados por omisión.
Otro ejemplo es aquel de las sesiones. Cuando register_globals = on, podríamos usar también $nombre_usuario en nuestro siguiente ejemplo, pero nuevamente usted debe notar que $nombre_usuario puede provenir de otros medios, como GET (a través de la URL).
Example#2 Ejemplo del uso de sesiones con register_globals on u off
<?php
// No sabríamos de dónde proviene $nombre_usuario, pero sabemos que
// $_SESSION es para datos de sesión
if (isset($_SESSION['nombre_usuario'])) {
echo "Hola <b>{$_SESSION['nombre_usuario']}</b>";
} else {
echo "Hola <b>Invitado</b><br />";
echo "¿Quisiera iniciar su sesión?";
}
?>
Incluso es posible tomar medidas preventivas para advertir cuando se intente falsificar la información. Si usted sabe previamente con exactitud el lugar de donde debería provenir una variable, usted puede chequear si los datos enviados provienen de una fuente inadecuada. Aunque esto no garantiza que la información no haya sido falsificada, esto requiere que un atacante adivine el medio apropiado para falsificar la información. Si no le importa de dónde proviene la información, puede usar $_REQUEST ya que allí se incluye una mezcla de variables que provienen de datos GET, POST y COOKIE. Consulte también la sección del manual sobre el uso de variables desde fuera de PHP.
Example#3 Detección de envenenamiento simple de variables
<?php
if (isset($_COOKIE['COOKIE_MAGICA'])) {
// COOKIE_MAGICA proviene de una cookie.
// ¡Asegúrese de validar los datos de la cookie!
} elseif (isset($_GET['COOKIE_MAGICA']) || isset($_POST['COOKIE_MAGICA'])) {
mail("admin@example.com", "Posible intento de intromisión",
$_SERVER['REMOTE_ADDR']);
echo "Violación de seguridad, el administrador ha sido alertado.";
exit;
} else {
// COOKIE_MAGICA no fue definida en este REQUEST
}
?>
Por supuesto, deshabilitar register_globals no quiere decir que su código vaya a ser seguro. Por cada trozo de datos que sea enviado por el usuario, éste debe ser chequeado en otras formas. ¡Siempre valide los datos de los usuarios e inicialice sus variables! Para chequear por variables no inicializadas, usted puede usar error_reporting() para mostrar errores del nivel E_NOTICE.
Para más información sobre la emulación del valor On u Off de register_globals, consulte este FAQ.
Note: Superglobals: Nota de disponibilidad Desde 4.1.0, están disponibles algunas matrices superglobales tales como $_GET, $_POST, y $_SERVER, etc. Para más información puede consultar la sección superglobals
add a note
User Contributed NotesUso de Register Globals
Mike Willbanks
05-Sep-2007 06:40
05-Sep-2007 06:40
Mike Willbanks
29-Aug-2007 09:15
29-Aug-2007 09:15
Alans code may get rid of globals but it is slow since it is doing regular expressions on each of the input items. Then to add on more time the code is being passed through eval.
Besides the slower performance, his code is not checking to see if the variable may have been changed at any state before this code is being done.
There might be auto_prepended files or include files that might need to run before it. He is also going through get and post and lastly request which is a little silly seeing as request will contain the get, post and cookie so he has run get and post twice.
Here is a more effective fix that will take all the keys in request which become variable names and checks to make sure that the variables match then unsets the element.
<?php
if (ini_get(register_globals)) {
$rg = array_keys($_REQUEST);
foreach($rg as $var)
{
if ($_REQUEST[$v] === $$v)
{
unset($$v);
}
}
}
?>
alan hogan
20-Jul-2007 06:08
20-Jul-2007 06:08
Useful for shared hosting or scripts that you are sharing with other people.
<?php
// Effectively turn off dangerous register_globals without having to edit php.ini
if (ini_get(register_globals)) // If register_globals is enabled
{ // Unset $_GET keys
foreach ($_GET as $get_key => $get_value) {
if (ereg('^([a-zA-Z]|_){1}([a-zA-Z0-9]|_)*$', $get_key)) eval("unset(\${$get_key});");
} // Unset $_POST keys
foreach ($_POST as $post_key => $post_value) {
if (ereg('^([a-zA-Z]|_){1}([a-zA-Z0-9]|_)*$', $post_key)) eval("unset(\${$post_key});");
} // Unset $_REQUEST keys
foreach ($_REQUEST as $request_key => $request_value) {
if (ereg('^([a-zA-Z]|_){1}([a-zA-Z0-9]|_)*$', $request_key)) eval("unset(\${$request_key});");
}
}
?>
Timbo
14-Jul-2007 06:25
14-Jul-2007 06:25
In response to the above post by Caliwebman at yahoo dot com, a.k.a. "Gentle Warrior" who complained about the lack of documentation on register_globals:
I think this code snippet will address the *main* source of his confusion:
<?
function readyToBeAProgrammer()
{
$stuff=$_URINALYSIS['test'];
if($stuff == THC)
{
return false;
}
else
{
return true;
}
// register_globals is all about knowing where your variables are really coming from
// what if a malicious user tried to pass off
// $stuff=$_GET['someone_elses_drop']; // as $stuff ?
// preventing this kind of substitution is the whole point
// of disabling register_globals
}
if(!readyToBeAProgrammer())
{
die("Switch to coffee, man!");
}
?>
P.S., let's give it up in appreciation for the moderators who must sit though and clean up these boards, facetious posts like mine included...
caliwebman at yahoo dot com
10-Jul-2007 01:29
10-Jul-2007 01:29
U know what I find incredibly insane? The fact that no where on the first pages <<<PLURAL does anyone even suggest where to find this code. And IF it exists in a file called "register_globals-etc..." than I have no clue why none of my sites have this file. It amazes me that we here on this side have made things so incredibly difficult on ourselves and the newer coders. Why? I thought that was what Microsoft was doing but quite honestly follks, we here on this side have MS beat when it comes to making things MUCH more of a challenge than they need be.
PLEASE, please dumb things down. And if you can't? ASK someone who is NOT in your bubble of code to review what you are writing in your dirstructions.... directions.... ask someoen like your MOM or DAD who know nothing of the code.
We sure would get going mch more quickly if we all paid attenttion to this simple rule.... and lastly, the front end designers are finally getting it together..... thank you, but again, remember, THE 3 CLICK RULE!!!
Peace,
Gentle Warrior
Scott
29-Jun-2007 08:19
29-Jun-2007 08:19
I couldn't get any of the suggested ways to disable register_globals to work in what I believe to be an Apache environment, where even phpinfo() is disabled. I finally had to resort to
foreach(array_keys($_REQUEST) as $field)
{
unset(${$field});
}
to get the $_REQUEST array without auto-setting all the request variables. I'm somewhat new to the whole PHP thing and wonder if there is a downside to this that I don't see.
someone at example dot com
17-Apr-2007 10:14
17-Apr-2007 10:14
In reply to yyalcinkaya at ku edu tr you could just do this with $_REQUEST:
foreach($_REQUEST as $k => $v)
{
${$k} = $v;
}
...though doing something like this is asking for a world of trouble IMHO.
yyalcinkaya at ku edu tr
28-Mar-2007 12:37
28-Mar-2007 12:37
if you want to keep register_globals off you can use this codes instead.
foreach($_POST AS $key => $value) {
${$key} = $value;
}
foreach($_GET AS $key => $value) {
${$key} = $value;
}
alan at xensource dot com
15-Nov-2005 07:00
15-Nov-2005 07:00
From the PHP Manual page on Using register_globals:
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.
Dexter at dexpark dot com
06-Nov-2005 04:59
06-Nov-2005 04:59
For Apache users or webhosters, you can set the
php_flag register_globals on/off in a VirtualHost context.
dyer85 at gmail dot com
05-Nov-2005 08:10
05-Nov-2005 08:10
I'd suggest taking a look at php.net's source code for these user notes, if you want to get ideas on some nice ways to collect and validate user data.
http://php.net/source.php?url=/manual/add-note.php
hbinduni at gmail dot com
30-Oct-2005 11:06
30-Oct-2005 11:06
[quote]
If you're under an Apache environment that has this option enabled, but you're on shared hosting so have no access to php.ini, you can unset this value for your own site by placing the following in an .htaccess file in the root:
php_flag register_globals 0
[/quote]
adding php_flag in .htaccess under apache 2 will cause internal server error. according to apache 2 manual, php_flag should goes to <virtual> or <directory> section.
ramosa (0) gmail dotty com
24-Sep-2005 07:24
24-Sep-2005 07:24
Here's a one liner that works both with register globals on or off, and is even secure enough when it's on, as you make sure you init the var.
Using the ?: operator
$variable = isset($_GET["variable"]) ? $_GET["variable"] : "";
kcinick at ciudad dot com dot ar
19-May-2005 01:12
19-May-2005 01:12
if you plan to use php_admin_value register_globals [0-1] inside <VirtualHost> in apache, forget it, it don't show any error messages in the configuration, but at the time of running, it enable and disables register_globals at random request, if you need to customize this param to multiple virtual host, put it in a <Directory> directives, it works fine there...
PD: same for safe_mode, etc...
ryanwray at gmail dot com
24-Nov-2004 05:03
24-Nov-2004 05:03
In reply to ben at nullcreations dot net:
This is true of the super-global $_SESSION, as it will always be processed last (it is not considered in variables_order directive)
However, it is possible to over-write other data, namely GET, POST, COOKIE, ENVIROMENT and SERVER.
Of course, what you can overwrite will depend on the directive variables_order - by default, you could overwrite GET and POST data via COOKIE (because cookie data is processed last out of the three which should not really be of great concern.
My below code is irrelevant unless extract or another method which does the same thing (ie. I have seen variable variables used before to reach the same affect) is used.
ben at nullcreations dot net
23-Nov-2004 02:53
23-Nov-2004 02:53
Just a note to all the people who think $_SESSION can be poisoned by register_globals - it can't.
Consider the fact that GET/POST/COOKIE is Processed *before* sessions are. This means that even if you have register_globals on, and they write to $_SESSION, $_SESSION will just get reset again with the appropriate values.
Some people take to using extract() as a means to simulate register_globals in scripts where they're not sure what the server environment will be - this is when you should worry about such things. The reason is because extract() can concievably occur after GET/POST/COOKIE and SESSION processing.
snarkles <anything at $myname dot net>
19-May-2004 10:06
19-May-2004 10:06
If you're under an Apache environment that has this option enabled, but you're on shared hosting so have no access to php.ini, you can unset this value for your own site by placing the following in an .htaccess file in the root:
php_flag register_globals 0
The ini_set() function actually accomplishes nothing here, since the variables will have already been created by the time the script processes the ini file change.
And since this is the security chapter, just as a side note, another thing that's helpful to put into your .htaccess is:
<Files ".ht*">
deny from all
</Files>
That way no one can load .htaccess in their browser and have a peek at its contents.
Sorry, not aware of a similar workaround for IIS. :\
dav at thedevelopersalliance dot com
18-Dec-2003 08:38
18-Dec-2003 08:38
import_request_variables() has a good solution to part of this problem - add a prefix to all imported variables, thus almost eliminating the factor of overriding internal variables through requests. you should still check data, but adding a prefix to imports is a start.