|
 |
Глава 29. Использование глобальных переменных (Register_Globals)
Наверное, наиболее спорным моментом в разработке PHP стала замена
значения по умолчанию для опции
register_globals с ON на OFF в версии 4.2.0.
Большинство пользователей доверились разработчикам, даже не зная, что это за
опция и как она влияет на работу PHP. Эта страница документации призвана
показать, как эта настройка сочетается с вопросами безопасности при
разработке приложений. Следует понимать, что сама по себе эта опция
никак не влияет на безопасность, ургозу представляет некорректное
использование предоставляемых ею возможностей.
В случае, если значение параметра register_globals ON, перед выполнением
вашего кода будут инициализированы различные переменные, например,
переменные, переданные при отправке формы. Также, учитывая тот факт,
что PHP не требует инициализации переменных, написать потенциально опасный
код очень легко. Это было очень спорным решением, но общество разработчиков
PHP решило изменить значение по умолчанию этой директивы на OFF. В
противном случае при написании кода разработчики не могли бы с уверенностью
сказать, откуда пришла та или иная переменная и насколько она достоверна.
До такого нововведения переменные, определяемые разработчиком внутри скрипта,
и передаваемые пользователем внешние данные могли перемешиваться.
Приведем простой пример злоупотребления конфигурационной опцией register_globals:
Пример 29-1. Пример опасного кода с register_globals = on
<?php
if (authenticated_user()) {
$authorized = true;
}
if ($authorized) {
include "/highly/sensitive/data.php";
}
?>
|
|
В случае register_globals = on логика работы скрипта может быть нарушена.
В случае, если установленное значение off, переменная $authorized не
может быть установлена из внешних данных запроса, и скрипт будет работать
корректно. Но все же инициализация переменных - один из признаков хорошего
тона в программировании. Например, в приведенном выше участке кода
мы могли поместить $authorized = false в качестве
первой строки. Такой код работал бы как со значением on, так и off опции
register_globals, и подразумевая, что по умолчанию пользователь не проходил
авторизацию.
Приведем еще один пример, использующий сессии.
В случае, если register_globals = on, мы можем использовать переменную
$username в приведенном ниже примере, но тогда у нас
не будет уверенности в достоверности ее значения (к примеру, она могла быть передана в GET-запросе).
Пример 29-2. Пример использования сессий со значением register_globals on или off
<?php
if (isset($_SESSION['username'])) {
echo "Hello <b>{$_SESSION['username']}</b>";
} else {
echo "Hello <b>Guest</b><br />";
echo "Would you like to login?";
}
?>
|
|
Также существует возможность реализации оперативного реагирования
в случае попытки подмены переменных. Так как во время разработки приложения
мы знаем ожидаемое значение переменной, а также знаем ее достоверное
значение, мы можем их сопоставить. Это не защитит код от подмены переменных,
но усложнит перебор возможных вариантов. Если вы не хотите знать, как именно
были получены внешние данные, используйте переменную $_REQUEST,
которая состоит из данных GET и POST запросов, а также данных COOKIE.
Также, информацию об этом можно найти в разделе
внешние данные в PHP.
Пример 29-3. Обнаружение попытки подмены переменных
<?php
if (isset($_COOKIE['MAGIC_COOKIE'])) {
} elseif (isset($_GET['MAGIC_COOKIE']) || isset($_POST['MAGIC_COOKIE'])) {
mail("admin@example.com", "Обнаружена попытка взлома", $_SERVER['REMOTE_ADDR']);
echo "Обнаружено нарушение безопасности, администратор уведомлен.";
exit;
} else {
}
?>
|
|
Следует понимать, что установка register_globals в off не сделает ваш код
безопасным. Каждую полученную от пользователя переменную следует проверять
на соответствие ожидаемому значению. Всегда проверяйте ввод пользователя и
инициализируйте все используемые переменные. Для проверки на наличие
неинициализированных переменных можно включить в опцию error_reporting()
отображение ошибок категории E_NOTICE.
Суперглобальные переменные:
замечание о доступности: Начиная с PHP 4.1.0, стали доступными
суперглобальные массивы, такие как $_GET,
$_POST, $_SERVER и т.д. Дополнительную
информацию смотрите в разделе руководства superglobals
Использование глобальных переменных (Register_Globals)
andrei dot neculau (0) gmail dot com
19-May-2006 09:54
If you have a webhost with register_globals On by default, and running PHP as CGI (not as an Apache module, when there might be some solutions) use the code bellow.
Explanation: it will first take all global variables, and unset everything that shouldn’t be there. Do not worry about your code still being accesible for changes (i.e. info.php?_ENV[OS]=NewOS ). The PHP queue works like this: first it registers variables from GET, etc. and then it fills in the global variables _GET, _POST, etc. (I wonder why they are not READ ONLY!) Therefore you will have the correct associative arrays, without any injected modification.
<?php
if (ini_get('register_globals'))
{
foreach($GLOBALS as $s_variable_name => $m_variable_value)
{
if (!in_array($s_variable_name, array('GLOBALS', 'argv', 'argc', '_FILES', '_COOKIE', '_POST', '_GET', '_SERVER', '_ENV', '_SESSION', 's_variable_name', 'm_variable_value')))
{
unset($GLOBALS[$s_variable_name]);
}
}
unset($GLOBALS['s_variable_name']);
unset($GLOBLAS['m_variable_value']);
}
?>
Full article here: http://andreineculau.wordpress.com/?s=register_globals
* the above code is not mine. I found it on the Internet, while I was looking for a solution.
alan at xensource dot com
15-Nov-2005 09: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 06:59
For Apache users or webhosters, you can set the
php_flag register_globals on/off in a VirtualHost context.
hbinduni at gmail dot com
30-Oct-2005 01: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 09: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"] : "";
argentus at ukr dot net
14-Aug-2005 02:04
I have found out a method which seems to me the best. I've written my own version of extract. It works as follows:
<?php
safe_extract($_POST, "post", array("param1", "param2"));
echo "param1 is <b>$post_param1_html</b><br />";
mysql_query("SELECT * FROM sometable WHERE something = '$post_param2_slashes'");
if($post_param1_unsafe != $post_param2_unsafe)
?>
I think it to be more convenient than using the required functions manually and more safe than that, and surely much more safe than register_globals = On.
The code is very simple. You can write your own version, of course, but I'll also show mine:
<?php
function make_variables($key, $value, $prefix)
{
$GLOBALS["{$prefix}_{$key}_unsafe"] = $value;
$GLOBALS["{$prefix}_{$key}_slashes"] = addslashes($value);
$GLOBALS["{$prefix}_{$key}_url"] = urlencode($value);
$GLOBALS["{$prefix}_{$key}_html"] = htmlspecialchars($value);
$GLOBALS["{$prefix}_{$key}_url_html"] = htmlspecialchars(urlencode($value));
}
function safe_extract($array, $prefix, $keys)
{
if(count(array_diff(array_values($keys), array_keys($array))) != 0)
return false;
foreach($keys as $key)
make_variables($key, $array[$key], $prefix);
return true;
}
?>
kcinick at ciudad dot com dot ar
18-May-2005 03: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 07: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
22-Nov-2004 04: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 12: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
17-Dec-2003 10: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.
| |