Perl и CGI

Протокол CGI (Common Gateway Interface - Интерфейс общих шлюзов) представляет со- бой мощный инструмент для интерактивного взаимодействия с сервером по ходу сеанса работы пользователя с вашим сайтом Web. Протокол CGI может обеспечивать работу сце- нариев Perl, сценариев оболочки и программ, написанных на таких языках, как C/C++.

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

Сценарии C/C++ работают быстрее сценариев Perl, поскольку представляют собой ком- пилированный двоичный код, а не текстовый список команд, исполняемый в режиме интерпретации. Однако сценарии C/C++ менее безопасны по сравнению со сценариями Perl. Поэтому вы должны изучить все риски, связанные с использованием C/C++, если вы остановите свой выбор на C/C++.

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

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

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

• Проверяйте информацию, вводимую в поля данных форм в документах HTML. С по- мощью сценариев Perl вы можете исключить из вводимых данных опасные сим- волы, или изолировать введенные данные определенного формата. Например, для поля, в которое пользователи должны вводить свой адрес электронной почты, вы можете создать сценарий, который будет проверять, что введенные данные содер- жат только буквы и/или цифры, точки, и символ «@». Вдобавок этот же сценарий может исключать из вводимых данных пробелы, точки с запятой (;), амперсанты (&) и так далее.

• Ограничьте размер данных, вводимых в текстовые поля, с помощью атрибута МАХ.

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

• Проверяйте корректность параметров команд перед передачей их в командный про- цессор. Если вы программируете на Perl, вы можете при запуске интерпретатора сценария использовать флаг - Т (от англ, слова «taint» - некорректность, ошибка), (#!/usr/bin/perl -Т) для автоматического контроля возможных ошибок в переменных перед их передачей системе на исполнение. Действие этого средства также распро- страняется на переменные, значения которых задаются пользователями, и автома- тически относящиеся к числу переменных, требующих проверки. Вы можете от- корректировать переменную, воспользовавшись шаблонными соответствиями сим- волов и регулярными выражениями. Флаг -Т также требует, чтобы вы определяли переменную окружения PATH, если планируете использовать в своих программах системные вызовы.

• Не помешайте какие-либо небезопасные программы в свой каталог cgi-bin, и огра- ничьте видимость каждого сценария, помещаемого в этот каталог. Например, используйте каталог /tmp для применяемых вами временных или блокированных файлов.

• Используйте во всех ссылках полные путевые имена.

• Установите для своих сценариев CGI разрешения доступа, гарантирующие невоз- можность их перезаписи посетителями сайта.

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

• Предупреждайте атаки крекеров. Просмотрите свою программу, и попытайтесь найти пути, которыми можно воспользоваться для взлома вашей системы.

• Сохраняйте сами файлы журналов доступа, если этого не делает ваш сервер, чтобы знать, как программа работала в любой момент времени. Не сбивалась ли программа? Где? Почему? Когда? Что происходило с системой во время сбоя?

• Выясните, какой метод доступа к системе безопасный, а какой нет, для используемо- го вами языка программирования.

• Если вы должны использовать параметры SUID (setuid) или QUID (getuid), изолируйте код, который получает доступ к системе в режиме SUID/GUID. Удостоверьтесь, что в этом режиме доступ минимален, и что код, исполняемый в этом режиме, не взаимо- действует напрямую с остальной частью кода в вашей программе.

• Отслеживайте в своих сценариях компоненты, потенциально уязвимые для атак отка- за в обслуживании, Может ли ваша программа зависнуть при обработке каких-то ресурсов? Может ли программа войти в бесконечный цикл в какой-то точке? Установите для своего сервера максимальное время ожидания каждого процесса, чтобы исключить ситуацию, когда процесс исполняется дольше некоторого разумного промежутка времени. Это гарантирует невозможность атак в обслуживании, использующих такую уязвимость.

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

Продолжение темы:

Полезная информация