Проблема употребления CGI-сценариев заключается в том, что они выполняются с правами Web-сервера, а не создавшего их пользователя. Представьте, что хостинг-провайдер предоставляет Web-пространство клиентам.

     Корпоративный пользователь (какая-то компания) помещает свой Web-сайт на сервере. Он тоже записал CGI-сценарий, позволяющий пользователям его компании править свое расписание. Изменения в расписании записываются в текстовый файл, созданный CGI-сценарием. Владельцем данного файла представляется пользователь, от имени которого работает Web-сервер - обычно http, www или nobody.

     Пользователь Иванов, как часто такое бывает, «обиделся» на свою компанию (к примеру, ему не повысили зарплату, хотят уволить или уже уволили). Он регистрируется в системе, создает свой собственный CGI-сценарий, удаляющий какой угодно файл, который передан ему в качестве параметра. Потому что этот вредоносный сценарий запускается от имени того же, пользователя, который создал файл с расписанием, ничто ему не мешает удалить его.

     Конечно, показанный пример немного утрирован, но все же он показывает главную проблему CGI-сценариев, которые запускаются от имени одного и того же пользователя.

     Решение данной проблемы заключается в применении программы CGIWarp - программы «обертки», позволяющей запускать сценарии от имени создавших их пользователей. Но не успели мы решить одну проблему, так синхронно же возникает остальная. Теперь тот же самый сценарий удаления файлов позволяет удалять и даже изменять файлы пользователя-владельца... Однако осознание того, что в результате неответственных действий самого же пользователя могут пострадать его же собственные данные, делает пользователей более дисциплинированными.

     Проблема вредоносного ввода остается и при употреблении оставшихся скриптинговых языков, к примеру PHP. PHP тоже позволяет применять регулярные выражения, и, хотя они не такие мощные, как регулярные выражения в Perl, их употребление позволяет проверить введенные пользователем данные.

     Интересно, что РНР делает досягаемыми CGI-переменные. В Perl поначалу можно прочитать строку запроса, затем разбить ее на отдельные части - переменные и их значения, а потом извлечь из этих частей значения и записать их в должные переменные (правда, задачу намного облегчает модуль CGI.pm). PHP предлагает автоматическое создание необходимых переменных - если передать сценарию параметр name=Piter, РНР автоматически создаст переменную $name со значением «Piter».

     Рассмотрим пример. Пользователь ввел следующие URL:

http://example.com/feedback.php?name=piter&email=pit@example.com&message=great%20site

     Если директива register_globals включена в файле конфигурации php.ini, то РНР автоматически создаст переменные $name, $email и $message. Так как крекер может добавить свои данные в строку запроса, он может вставить свои собственные переменные в сценарий. Следующий пример демонстрирует всю опасность этой ситуации:

if ($password eq "letmein") { $authenticated = "yes" }

if (^authenticated eq "yes") {// вывести информацию, доступную только администратору }

     Это пример кода, выводящего панель управления администратора. Прежде проверяется строка, содержащаяся в переменной $password - если она совпадает со значением letmein, значит, пользователь прошел аутентификацию - $authenticated - yes. Затем проверяется значение переменной $authenticated. Если значение равно yes, то сценарий вводит панель управления. Крекер может передать сценарию следующие параметры:

password=anything&authenticated=yes

     PHP автоматически создаст переменные $password и $authenticated. Значение последней переменной равно yes, поэтому сценарий выведет панель управления.

     Учитывая всю опасность директивы register_globals, разработчики РНР, начиная с версии РНР 4.2.0, отключили эту директиву по умолчанию. Отключение этой директивы может привести к тому, что некоторые (если не все) сценарии надо будет переписать, используя остальные способы получения значений переданных параметров.

     Из соображений безопасности рекомендуется отключить директиву register_globals. Это надо сделать в файле конфигурации php.ini, который обычно находится в каталоге /etc или /etc/apache.