В чем проблемы со скриптами CGI?

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

Скрипты CGI могут открывать лазейки двумя путями:

  1. Они могут, случайно или преднамеренно, предоставлять информацию о системе, которая может быть использована хакером.
  2. Скрипты, которые обрабатывают данные, вводимые удаленным пользователем через формы ввода, могут подвергаться атакам, при которых пользователь заставляет их выполнять произвольные команды.

Скрипты CGI являются потенциальными лазейками даже в том случае, если вы запускаете сервер с правами пользователя "nobody". Взломаный скрипт, работая с правами nobody, тем не менее пользуется правами, достаточными для отсылки по электронной почте файла паролей, получения карт локальной сети или инициирования входа в систему через порт с большим номером (для выполнения этого необходимо всего лишь выполнить несколько команд на языке Perl). Даже если ваш сервер запущен в среде chroot, ошибочный скрипт может выдать информацию, достаточную для взлома системы.


Что безопаснее - хранить скрипты в директории cgi-bin, или хранить их где-нибудь в директориях документов, присваивая им расширение .cgi?

Хотя особой опасности в хранении скриптов вместе с документами нет, но лучше хранить их в отдельном директории. Гораздо легче контролировать доступ к скриптам CGI, могущим представлять собой лазейки в безопасности, тогда, когда они хранятся отдельно, чем если они разбросаны по разным директориям. Особенно актуально это в ситуации, когда на сервере работает много авторов документов Web. Автор очень легко может написать скрипт, содержащий случайную ошибку, и поместить его среди документов. Ограничивая область размещения скриптов директорием cgi-bin с правами доступа, разрешающими установку новых скриптов только системному администратору, вы избегаете хаоса на сервере.

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


Являются ли компилируемые языки, такие как C, более безопасными, чем интерпетируемые, подобные Perl или языкам оболочек операционных систем?

Да, но с множеством оговорок.

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

Рассмотрим следующий сценарий. Из соображений удобства, вы настроили сервер на распознавание скриптов CGI по расширению имени файла .cgi. Затем вам понадобилось отредактировать интерпретируемый скрипт CGI. Вы открываете его с помощью текстового редактора Emacs и изменяете нужным образом. Увы, редактор оставляет резервную копию файла с исходным текстом программы в дереве документов. И хотя удаленный пользователь не может получить исходный текст при обращении к самому скрипту, он имеет возможность получить резервную копию файла попросту выбрав адрес URL:

        http://ваш-узел/путь/к/ваш_скрипт.cgi~

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

Конечно, во многих случаях исходные тексты скриптов на C свободно распространяются по Сети, и у хакеров не возникнет проблем с доступом к ним.

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

Третий фактор - возможность использовать языки, на которых пишут скрипты, для передачи данных системным командам и получение результатов их выполнения. Как будет описано далее, выполнение системных команд при работе скрипта - один из основных источников лазеек в безопасности. В C выполнить системную команду сложнее, и менее вероятно, что программист будет использоватьб эту возможность. Наоборот, написать скрипт любой степени сложности на языке оболочки операционной системы, полностью избегая использования опасных инструкций, очень сложно. Языки оболочек ОС - плохой выбор при разработке хоть сколько-нибудь сложных скриптов CGI.

Прочтя все это, пожалуйста поймите, что нет гарантии того, что программа на C будет безопасной. Программы на C могут содержать множество опасных ошибок, как показывает пример программ NCSA httpd 1.3 и sendmail. В свою очередь, программы на интерпретируемых языках как правило имеют меньший объем текста и легче могут быть поняты лицами, не участвовавшими в разработке, с целью контроля. Далее, язык Perl содержит ряд встроенных функций, предназначенных для перехвата возможных лазеек в безопасности. Например, "проверки на чистоту" (taint checks, см. далее) перехватывают многие обычные недостатки в текстах программ и делают скрипты Perl в некотором отношении более безопасными, чем аналогичные программы на C.

Информация взята с сайта wertas.da.ru


© журнал принадлежит Web Creation
по всем вопросам обращаться А. Кузьмин