Проблема в том, что любой из них может содержать ошибку, которую можно использовать. Скрипты CGI должны быть написаны с той же осторожностью и вниманием, что и программы самого сервера, поскольку на самом деле они и есть маленькие серверы. К сожалению, для многих авторов программ в Web скрипты CGI являются первым опытом программирования в сетях. Скрипты CGI могут открывать лазейки двумя путями: Они могут, случайно или преднамеренно, предоставлять информацию о системе, которая может быть использована хакером. Скрипты, которые обрабатывают данные, вводимые удаленным пользователем через формы ввода, могут подвергаться атакам, при которых пользователь заставляет их выполнять произвольные команды. Скрипты 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.
Я нашел в Сети замечательный скрипт и хочу установить его у себя. Как мне убедиться в его безопасности?
Вы никогда не можете быть уверены, что скрипт безопасен. Лучшее, что вы можете сделать - внимательно изучить скрипт и понять, что и как он делает. Если вы не владеете языком, на котором написан скрипт, обратитесь к кому-нибуть, кто знает этот язык.
Вот вопросы, которые следует учитывать при изучении скрипта:
Насколько он сложен? Чем скрипт больше, тем вероятнее, что с ним могут возникнуть проблемы.
Выполняет ли он чтение или запись файлов на сервере? Программы, выполняющие чтение файлов, могут случайно нарушить ограничения доступа, установленные вами, или передать хакерам важную информацию о системе. Программы, пишущие в файлы, могут случайно повредить файлы документов, или, в худшем случае, запускать "троянских коней" в вашу систему.
Взаимодействует ли он с другими программами в вашей системе? Например, многие скрипты CGI посылают сообщения по электронной почте в ответ на запросы, введенные через формы ввода, и используют для этого программу sendmail. Безопасно ли выполняются такие действия?
Выполняется ли он с правами suid (set-user-id, установленный идентификатор пользователя)? В общем случае это очень опасно, и скрипт должен иметь веские основания для использования suid.
Использовал ли автор скрипта проверку данных, вводимых пользователем через формы ввода? Проверка вводимых данных служит показателем того, что автор скрипта заботился о его безопасности.
Указывал ли автор полный путь доступа к внешним программам, используемым в скрипте? Доверять переменным окружения PATH для нахождения файлов по неполному пути доступа является небезопасной практикой.
Какие скрипты CGI содержат известные лазейки в безопасности?
Заметное число свободно распространяемых скриптов CGI содержат известные лазейки в безопасности. Многие из тех лазеек, которые здесь указаны, были закрыты, но если вы используете старую версию, не имеющую исправления, то вы можете подвергаться опасности. В таком случае - обновите вашу версию. Если для скрипта нет исправлений, то лучше от него избавиться.
TextCounter от Matt Wright, версии 1.0-1.2 (Perl) и 1.0-1.3 (C++) (июнь 1998)
Ранние версии программы TextCounter, используемой для размещения счетчиков обращений на страницах, не удаляет метасимволы оболочки из содержимого запросов пользователя. Как результат, удаленный пользователь может запускать системные команды на сервере. Лазейка есть как в Perl, так и в C++ версиях скрипта. Обновите скрипт до версии 1.21 (Perl) или 1.31 (C++):
(Perl)
(C++)
Различные гостевые книги (июнь 1998)
Продолжают появляться сообщения о взломах различных скриптов гостевых книг. Впервые лазейка была найдена в Selena Sol guestbook, но обнаруживается и в других скриптах. Лазейки используют сохранение элементов в текстах, вводимых пользователем, и то, что многие программы сохраняют файлы в директриях, в которых разрешены вставки на сервере. Скрипт гостевой книги должен удалять HTML и пользовательских текстов, или заменять угловые скобки на > and <. Файлы, которые пишет скрипт, не должнынаходиться в директории, в котором разрешены вставки на сервере, active server pages, страницы PHP или другие системы темплат HTML. Подробное описание проблемы смотрите в архиве Selena Sol:
Excite Web Search Engine (EWS), версии 1.0-1.1 (January 1998)
Excite Web Search engine не проверяет содержимое текстовых строк, вводимых пользователем, перед передачей их для интерпритации оболочке операционной системы, что позволяет удаленным пользователям выполнять команды на сервере. Команды будут выполняться с правами доступа сервера Web. Ошибка затрагивает версии для Unix и для NT. См. для получения исправлений. Имейте в виду, что ошибка затрагивает ваш сервер только в том случае, когда скрипт установлен локально. Она не затрагивает узлы, содержащие ссылки на страницы поиска Excite.com и страницы, проиндексированные роботом Excite.
info2www, версии 1.0-1.1
info2www, конвертирующий файлы формата GNU info в документы Web, не выполняет проверки имен файлов, предоставленных пользователем, перед их открытием. В результате, этот скрипт может быть использован для доступа к системным файлам или выполнения системных команд, содержащих метасимволы коммандного процессора. Версия 1.2 и более поздние, как сообщается, не содержат этой ошибки, но, поскольку существует множество версий этого скрипта, лучше всего проверить исходный текст программы перед ее установкой. То же относится к скриптам info2html и infogate, которые являются производными от info2www.
Count.cgi, версии 1.0-2.3
Count.cgi, широко используемый для подсчета числа обращений к странице, содержит ошибку, приводящую к переполнению стека. Это дает возможность злоумышленнику выполнять произвольные команды на сервере, для чего необходимо послать для обработки специально подобранную строку запроса. Ошибка исправлена в версии 2.4. Эту версию можно найти здесь: .
webdist.cgi, часть IRIX Mindshare Out Box версии 1.0-1.2
Этот скрипт является частью системы, позволяющей пользователю получать и распространять программное обеспечение по сети. Из-за неправильной проверки параметров, передаваемых скрипту, удаленный пользователь имеет возможность выполнения на сервере системных команд с правами доступа демона сервера.
По состоянию на 12 июня 1997 года, эта ошибка не была исправлена . Обращайтесь в Mindshare за справками. До того, как ваша копия webdist.cgi будет исправлена, выключите ее, сняв с нее права доступа на выполнение.
php.cgi, многие версии
Скрипт php.cgi, реализующий язык программирования, включаемый в HTML, дающий массу замечательных возможностей, никогда не должен устанавливаться в директории скриптов (cgi-bin). Это позволяет кому угодно выполнять команды оболочки ОС на машине, на которой установлен сервер WWW. Кроме того, версии до 2.0b11 содержат известные лазейки в безопасности. Убедитесь в том, что вы используете самую последнюю версию, и периодически проверяйте узел PHP (см. адрес ниже) на предмет других новостей в части безопасности. Утверждается, что версия PHP - модуль для сервера Apache не содержит этой лазейки, поскольку не выполняется как скрипт CGI. Тем не менее, имеет смысл поддерживать вашу систему в соответствии последней версии.
http://php.iquest.net/
files.pl, часть Novell WebServer Examples Toolkit v.2
По причине отсутствия проверки вводимых данных, скрипт files.pl, распространяемый с Novell WebServer, позволяет пользователю просматривать любой файл или директорий на вашей машине, предоставляя тем самым доступ к конфиденциальным документам и возможность для хакеров получать информацию, необходимую для проникновения на вашу машину. Уберите этот скрипт, а также все другие (примеры и пр.) скрипты, которые вы не используете.
Microsoft FrontPage Extensions, версии 1.0-1.1
При определенных условиях пользователь может повреждать файлы, к которым у него нет прав доступа, переписывая или добавляя их содержимое. На серверах, использующих вставки на сервере (server-side includes), удаленный пользователь может использовать эту ошибку для выполнения системных команд на машине.
Это не столько лазейка, сколько ее возможность. Если на вашем сервере разрешено использование вставок на сервере в guestbook, и если этот скрипт позволяет вводить элементы HTML в поля текстового ввода, то удаленный пользователь может иметь возможность выполнения произвольных команд на вашем сервере. Полное объяснение и исправления можно найти по адресу:
nph-test-cgi, все версии
Этот скрипт, включенный во многие версии серверов NCSA и Apache, может быть использован для получения списка содержимого любого директория на сервере. Он должен быть уничтожен или выключен путем запрета выполнения.
nph-publish, версии 1.0-1.1
При определенных условиях пользователь может повреждать общедоступные для записи файлы на сервере.
Пользователь может выполнять системные команды на сервере.
http://www.uky.edu/~johnr/AnyForm2
FormMail, версия 1.0
Пользователь может выполнять системные команды на сервере.
http://alpha.pr1.k12.co.us/~mattw/scripts.html
скрипт "phf", телефонная книга, распространяемый с серверами NCSA httpd и Apache, все версии
Пользователь может выполнять системные команды на сервере.
http://hoohoo.ncsa.uiuc.edu/
К стыду, один из ошибочных скриптов, nph-publish, был написан автором этого документа. Скрипт предназначен для публикации на сервере Apache документов, редактируемых при помощи "публикующего" редактора, такого, например, как Netscape Navigator Gold. автор не проверял необходимым образом пути доступа к файлам, вводимые пользователем, потенциально давая возможность сохранять файлы там, где не положено. Это может создать серьезные проблемы в случае, если сервер запущен с большими привилегиями. Если вы используете этот скрипт, то обновите версию на 1.2 или более позднюю. Ошибка была обнаружена Randal Schwartz (merlyn@stonehenge.com).
Ошибки во второй паре скриптов в списке были обнаружены Paul Phillips (paulp@cerf.net), автором CGI security FAQ. Лазейка в PHF (телефонная книга) найдена Jennifer Myers (jmyers@marigold.eecs.nwu.edu), она представляет собой потенциальную лазейку, содержащуюся во всех скриптах CGI, использующих библиотеку NCSA util.c. Здесь можно найти информацию о том, как исправить лазейку в util.c.
периодически здесь будет добавляться информация о других скриптах, содержащих ошибки.
Добавим, что один из скриптов, приведенных как пример "хорошего программирования CGI" в книге "Build a Web Site" (Построение узла Web, net.Genesis и Devra Hall), содержит классическую ошибку, заключающуюся в передаче непроверенной пользовательской переменной оболочке операционной системы. Скрипт приведен в разделе 11.4, "Простой скрипт для поиска с использованием grep", страница 443. Другие скрипты в этой книге также могут содержать ошибки.
Этот список далек от полноты. Никакая организация не занимается отслеживанием распространяемых скриптов. CERT выпускает сообщения о скриптах с ошибками, когда узнает о них, и имеет смысл подписаться на их список рассылки, или иногда просматривать свежие архивы (смотри Библиография).
Безусловно, на вашей совести лежит проверка безопасности каждого используемого вами скрипта.
