Перед тем как использовать полученные данные, надо произвести разбор строки параметров. В языке Perl предусмотрены мощные средства работы со строками. Этот факт стал одной из причин популярности Perl среди разработчиков CGI-сценариев.

Если на Web-узле присутствуют CGI-сценарии, любой пользователь, работающий с Web-броузером, имеет возможность запустить на стороне сервера программу. Это может стать источником проблем, связанных с безопасностью системы. Определенную опасность для системы представляет любой сервер, но при использовании на Web-узле CGI- сценариев шансы злоумышленников на успех существенно возрастают. Ни об одном достаточно сложном CGI-сценарии нельзя с уверенностью сказать, что он безупречен с точки зрения защиты. Разработчики серверов прилагают большие усилия для того, чтобы устранить возможность проникновения с его помощью в систему, но несмотря на это, время от времени в серверах обнаруживаются ошибки. В отличие от серверов, CGI-сценарии в основном создаются системными администраторами, которые часто не имеют большого опыта программирования. В результате сценарии получаются уязвимыми для атак извне.

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

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

Чтобы уменьшить опасность для системы, можно использовать готовые сценарии, поставляемые в составе библиотек. Такой подход, с одной стороны, упростит процедуру создания Web-узла, а с другой стороны, позволит избежать грубых ошибок в сценарии. Библиотеки сценариев размещены на различных Web-узлах, например, вы можете обратиться по адресу

.

Чтобы злоумышленник, получивший контроль над Web-сервером, не смог нанести существенный вред компьютерам вашей сети, надо принять дополнительные меры. Например, желательно отключить ненужные серверы и ограничить доступ с компьютера, на котором выполняется Web-сервер, к другим компьютерам сети. Действия, направленные на повышение уровня защиты системы, рассматриваются в части IV.

При использовании сценариев часто осуществляется шифрование передаваемых данных. Действия по кодированию и декодированию информации при обмене между Web-сервером и Web-броузером определяется протоколом SSL (Secure Sockets Layer — уровень защищенного гнезда). Протокол SSL часто используется на узлах электронной коммерции для защиты важных данных. Для поддержки SSL-кодирования при работе Apache требуется дополнительное программное обеспечение, например,

() или программы, разработанные в рамках проекта Apache-SSL (). Для поддержки SSL можно также использовать продукты,

распространяемые на коммерческой основе.

SSL — это технология кодирования, подобная той, которая используется при обеспечении работы протокола удаленной регистрации SSH. (Строго говоря, эти протоколы применяют одни и те же средства шифрования, так как работа популярного пакета OpenSSH основана на использовании пакета OpenSSL, который также применяется некоторыми реализациями Apache, поддерживающими SSL.) SSL позволяет решить следующие две проблемы, возникающие при обмене между Web-клиентом и Web-сервером.

• Шифрование. SSL позволяет обеим взаимодействующим сторонам выполнять шифрование данных, обеспечивая тем самым их сохранность. Это необходимо в тех случаях, когда Web-клиент должен обмениваться с Web-сервером важной информацией, например передавать номера платежных карточек и банковских счетов. Для кодирования применяется технология открытого ключа, согласно которой каждая из взаимодействующих сторон использует два ключа. Шифрование осуществляется с помощью открытого, или общего, ключа, предоставляемого другой взаимодействующей стороной, а для расшифровки применяется собственной закрытый, или личный, ключ. Таким образом, передавая данные, участник сетевого взаимодействия уверен, что расшифровать их сможет только тот, для кого они предназначены.

• Аутентификация. Даже при использовании шифрования передача важных данных по Internet связана с определенным риском. Может оказаться, что принимающий узел — не тот, за кого он себя выдает. Например, если вы ввели в поле адреса броузера URL

, можете ли вы быть уверены, что ваш запрос попадет на тот узел, на который вы его отправляете? Не исключено, что злоумышленнику удалось изменить настройку сервера DNS или маршрутизатора и перенаправить запрос на свой компьютер. SSL предоставляет средства аутентификации участников взаимодействия. Идентификация осуществляется посредством сертификатов, предоставляемых организацией, специализирующейся на этом. Сертификат, полученный от сертифицирующей организации (CA — certificate authority), представляет собой цифровой код, используемый для создания общего ключа. Если один участник взаимодействия передал свой сертификат, полученный от CA, то другой участник может быть уверен, что его партнер по обмену данными — именно тот, за кого он себя выдает. (В последнее время стало ясно, что даже сертификаты не позволяют гарантированно идентифицировать участников взаимодействия. Так, в 2001 г. сертификаты Microsoft были по ошибке выданы организациям, не имеющим к корпорации никакого отношения.)

На заметку

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

http://www.apache-ssl.org/#Digital_Certificates

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