2.4 Обоснование разработки

Применение лишь пакетной фильтрации и контроля доступа из hosts.allow/hosts.deny не достаточно. Новые дыры обнаруживаются каждый день. Учитывая, что основным источником атак является Интернет, а сервер с размещённым на нём сайтом является не только рекламным лицом компании, но и поддерживает электронную систему оформления заказов и продаж, задача по его защите представляется одной из самых важных в деле обеспечения безопасности сети.

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

Другой рекомендацией по результатам анализа сети стало то, что в организации необходимо регулярно, лучше всего автоматически, проводить обновление программного обеспечения и установку «заплат» безопасности.

3 Проектирование программы

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

3.1 Система проверки уязвимостей.

Разрабатываемый программный продукт является системой поиска уязвимостей на этапе эксплуатации и функционирует на сетевом уровне. На основании результатов работы сканера портов можно приблизительно сказать, какие уязвимости возможны в данной системе [6]. Например, если открыт 21 порт, на котором функционирует фтп-сервер, то возможна атака DoS (отказ в обслуживании), если выяснится, что сервер или демон (для *nix систем) давно не обновлялся, т.е. стоит старая версия. Далее после определения операционной системы, можно с большей вероятностью сказать, каким атакам она может быть подвержена. Проверяя последовательно по известной базе уязвимостей удаленную систему, мы формируем отчет, который в конечном итоге увидит пользователь.

3.2 CGI-сканер.

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

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

3.2.1 Общие сведения

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

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

Рисунок 3.1 - Схема взаимодействия клиента и сервера

Пользователь заполняет экранную форму и нажимает на кнопку "Submit". Возможен также запрос при непосредственном использовании адреса CGI приложения - указывая его в строке Location браузера, в тэге <img> с помощью средств включения сервера (SSI) и т.д.

На основе информации из формы браузер формирует HTTP запрос и отправляет его серверу. Информация приводится к виду param1=value1&param2=value2...&paramN=valueN. Если указано, что при передаче должен использоваться метод GET, эта строка передается непосредственно в URL (например, http://www.somehost.com/cgi bin/script.cgi?param1=value1& param2=value2). При использовании метода POST через заголовок передается информация о типе содержимого запроса (для форм это, как правило, application/x-www-form-urlencoded), а также длина строки. Сама строка в этом случае передается непосредственно в теле запроса (примеры приведены чуть ниже). В заголовках запроса также передается значительное количество вспомогательной информации: тип браузера, адрес страницы, с которой был произведен запрос, и т. д.

Сервер вызывает CGI-приложение, и в зависимости от метода запроса передает информацию из формы через переменную окружения QUERY_STRING (в случае GET) либо через стандартный ввод (в случае POST). Также формируются другие переменные окружения, такие как HTTP_USER_AGENT, REMOTE_HOST и др.

CGI-приложение считывает строку с переданной информацией со стандартного ввода (stdin) или из переменной окружения QUERY_STRING. Обработав информацию, программа, как правило, либо переадресует браузер на некоторый существующий документ с помощью http заголовка Location, либо формирует виртуальный документ, посылая информацию на стандартный вывод (stdout). Телу документа предшествуют HTTP заголовки, описывающие тип возвращаемых данных, управляющие кэшированием, работой с cookies и т. д. Все это передается серверу.

Сервер пересылает ответ CGI-приложения браузеру.

Браузер, основываясь на заголовках HTTP, интерпретирует ответ CGI-приложения и выводит его для просмотра пользователем.

Реализовать CGI-приложение можно на любом языке, способном генерировать код для серверной платформы или для которого доступен интерпретатор. Так, простейшее CGI-приложение может быть реализовано на языке пакетных файлов DOS, на Delphi, С/С++, Tcl, Visual Basic, AppleScript, FoxPro и т. д. Широкое распространение в качестве языка для CGI-приложений получил Perl. Синтаксис Perl унаследован в первую очередь от С, в него добавлены расширенные средства для работы со строками, регулярными выражениями, ассоциативными массивами и т.д. Это интерпретируемый язык, изначально созданный для Unix систем, сейчас его интерпретаторы доступны для большинства популярных архитектур, что делает особенно легким перенос приложений.

CGI-приложения были первым средством "оживления" статичных Web страниц. Их главная особенность в том, что они выполняются на сервере. Java, JavaScript, ActiveX появились позднее и, в отличие от cgi, предназначались преимущественно для создания приложений на клиентской стороне. Но даже такая тривиальная задача, как установка счетчика посещений страницы, уже требует серверного решения. О плюсах серверных решений можно говорить долго, но нас сейчас интересует совсем другой вопрос - некорректно написанное CGI-приложение может стать источником весьма серьезных проблем.

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