Register globals как включить

Register globals как включить

Здравствуйте уважаемые веб-мастера, статья повествует о том, почему опасно оставлять опцию register_globals включенной. Вы, возможно, слышали, что использование её может привести к небезопасной работе вашей программы (скрипта). Но давайте разберемся, как эту опцию могут использовать в противоправных целях и как от этого защититься.

Что представляет собой register_globals ?
Это опция в php.ini, которая указывает на необходимость регистрации переменных полученные методом POST или GET в глобальный массив $GLOBALS.

Для ясности приведу пример при register_globals=on .
Есть файл «index.php» с содержимом:

В адресной строке напишем: index.php?asd=123

Как мы видим, создались 2 переменные: одна локальная (+ ссылка в $GLOBALS), другая в массиве $_GET. Многие не используют массив $_GET вообще, они продолжают обрабатывать переменную «$asd» после получения ее извне.
Но давайте вдумаемся, зачем нам «загрязнять» массив $GLOBALS? Для этого у нас есть специальные массивы, хранящие данные, переданные методами GET (массив $_GET) и POST (массив $_POST).

Тот же самый пример, но при register_globals=off :

Т.о. не была создана локальная переменная и для манипулирования с «$asd» мы должны использовать массив $_GET.

Возможно, уже сейчас вы изменили свое мнение о register_globals.
Вероятно, вам придется что-то переписать в своих программах, но оно того стоит.

А теперь я расскажу вам, как взломщик может воспользоваться этой опцией в своих целях, т.е. при register_globals=on
Начну от простого к сложному.

Часто мы видим предупреждения:

Что это значит? Это значит, что переменная «$asd» не была определена явно.
Например, некоторые люди балуются подобным:

Т.е. не определив переменную, сразу начинают ее использовать. Приведенный код по идее не страшен, но задумайтесь, а вдруг эта самая переменная «$asd», в последствие записывается в файл? Например, напишем следующее в строке адреса: «index.php?asd=LUSER+» и получим: «LUSER 0123456789». Ну, разве приятно будет увидеть такое? Не думаю.

Предположим мы пишем систему аутентификации пользователя:

Привел я заведомо дырявую систему, стоит нам только написать в адресной строке «index.php?val >

Читайте также:  800 Пикселей в сантиметрах

Этого бы не случилось, если бы мы написали так:

Т.е. сами определили переменную $valid_user, как FALSE в случае неудачи.

Продолжим далее…
Теперь использование функции IsSet() становится небезопасно, т.к. любой может подменить переменную на угодную ему.

Приведу пример с sql-инъекцией:

В адресной строке напишем: «index.php?where= >

И взломщик получает ваши явки и пароли:(

Как вы видите все примеры, имеют дыры в защите, которые можно эксплуатировать через включенный register_globals.

Справиться с подобным можно, если всегда определять переменную вне зависимости от условий. Или же использовать инкапсуляцию переменных в функциях, т.е. когда вы определяете функцию, то переменные, что внутри нее будут закрыты извне, например:

Теперь, если мы напишем в адресной строке: «index.php?where=123»
Даст: «$where не существует»
Но это при условии, что вы не устанавливаете переменную $where как глобальную, т.е. «global $where»

Я могу придумать еще очень много примеров, но думаю, что приведенных мною вам будет достаточно для понимания.
Хочу сказать, что все эти проблемы канут в лета, когда вы установите опцию register_globals=off и попробуете заново все приведенные выше примеры.

Это можно сделать как в php.ini, но большинство хостинг провайдеров вам это не позволят, потому придется воспользоваться файлом «.htaccess»

Создаем файл с названием: .htaccess
Запишем в него:

И все, теперь некоторые вопросы безопасности решены:)

Немного о причине написания мной этой статьи:
Лично я никогда не использовал register_globals = on, т.к. мне казалось это нелогичным. Так же я знал, что это еще один «+» к защите. Но в полной мере я не осознавал насколько это может быть опасно. Случилось это когда я решил написать GSMgen – Google SiteMap generator, который должен был работать безопасно и при включенном register_globals. Когда же я начал его тестировать, у меня был шок…так как мне нравится использовать функцию IsSet() я нашел в ней непосредственную уязвимость, и в процессе мне пришлось от этого отказаться:( Что поделаешь…

Читайте также:  Sony smartwatch 3 подключение

Я очень надеюсь, что эта статья изменит ваше мнение относительно register_globals. Думаю, что со временем все хостинг провайдеры будут ставить register_globals = off по умолчанию. Но пока этого нет, вы знаете, как с этим бороться;-)[/HTML]

Данная возможность была объявлена УСТАРЕВШЕЙ, начиная с PHP 5.3.0 и была УДАЛЕНА в PHP 5.4.0.

Пример #1 Пример опасного кода с register_globals = on

// устанавливаем переменную $authorized = true только для пользователей, прошедших авторизацию
if ( authenticated_user ()) <
$authorized = true ;
>

// Поскольку в случае неудачи при проверке авторизации переменная $authorized
// не установлена, она может быть установлена автоматически благодаря register_globals,
// например, при GET-запросе auth.php?authorized=1.
// Таким образом, любой может пройти эту проверку!
if ( $authorized ) <
include "/highly/sensitive/data.php" ;
>
?>

В случае register_globals = on логика работы скрипта может быть нарушена. В случае, если установленное значение off, переменная $authorized не может быть установлена из внешних данных запроса, и скрипт будет работать корректно. Но все же инициализация переменных — один из признаков хорошего тона в программировании. Например, в приведенном выше участке кода мы могли поместить $authorized = false в качестве первой строки. Такой код работал бы как со значением on, так и off опции register_globals, и подразумевая, что по умолчанию пользователь не проходил авторизацию.

Приведем еще один пример, использующий сессии. В случае, если register_globals = on, мы можем использовать переменную $username в приведенном ниже примере, но тогда у нас не будет уверенности в достоверности ее значения (к примеру, $username могла быть передана в GET-запросе через URL ).

Пример #2 Пример использования сессий со значением register_globals on или off

// Мы не знаем, откуда получена переменная $username, но точно знаем, что
// переменная $_SESSION хранит в себе данные сессии
if (isset( $_SESSION [ ‘username’ ])) <

Читайте также:  Tcl s960 idol x

echo "Привет, гость
" ;
echo "Вы хотите войти?" ;

Также существует возможность реализации превентивных мер в случае попытки подмены переменных. Так как во время разработки приложения мы знаем ожидаемое значение переменной, а также знаем ее достоверное значение, мы можем их сопоставить. Это не защитит код от подмены переменных, но усложнит перебор возможных вариантов. Если вы не хотите знать, как именно были получены внешние данные, используйте переменную $_REQUEST , которая является смесью из данных GET- и POST-запросов, а также данных COOKIE. Также, информацию об этом можно найти в разделе внешние данные в PHP.

Пример #3 Обнаружение попытки подмены переменных

if (isset( $_COOKIE [ ‘MAGIC_COOKIE’ ])) <

// MAGIC_COOKIE получена из достоверного источника.
// Для полной уверенности необходимо проверить ее значение.

> elseif (isset( $_GET [ ‘MAGIC_COOKIE’ ]) || isset( $_POST [ ‘MAGIC_COOKIE’ ])) <

mail ( "admin@example.com" , "Обнаружена попытка взлома" , $_SERVER [ ‘REMOTE_ADDR’ ]);
echo "Обнаружено нарушение безопасности, администратор уведомлен." ;
exit;

// MAGIC_COOKIE в данных запроса не присутствует

Следует понимать, что установка register_globals в off не сделает ваш код безопасным. Каждую полученную от пользователя переменную следует проверять на соответствие ожидаемому значению. Всегда проверяйте ввод пользователя и инициализируйте все используемые переменные! Для проверки на наличие неинициализированных переменных можно включить в опцию error_reporting() отображение ошибок категории E_NOTICE .

О том, как эмулировать включенное или отключенное состояние register_globals, смотрите этот FAQ.

Некоторые скрипты (обычно написанные для ранних версий PHP) требуют включения данной директивы. Для этого в папке скрипта или в папке домена создайте файл .htaccess и поместите в него следующую директиву:

Если файл .htaccess в нужной папке уже существует, то просто добавьте эту строку в конец. Действие этой директивы распространяется и на все подпапки.

Ссылка на основную публикацию
Adblock detector