1.3.3.5. Атаки на серверы: cgi и http

Не вдаваясь в подробности функционирования механизма CGI (Common Gateway Interface — Интерфейс Единого Шлюза), скажем, что это набор про­грамм (исполняемых скриптов, интерпретаторов и т. п.), выполняемый на сервере по запросу клиента. Он предназначен обеспечивать динамическое (то есть более гибкое) взаимодействие между удаленным клиентом - браузером и Веб-сервером посредством запуска на серверной стороне при­ложений, выполняющих задания клиента.

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

Основные проблемы, связанные с работой CGI, сводятся к тому, что:

О разработчиком допущены ошибки при написании кода;

D в коде оставлены преднамеренные люки;

П злоумышленник получил возможность (права) модифицировать код ли­бо данные, используемые кодом на сервере;

О злоумышленник получил доступ к интерпретатору с правом исполнения команд.

Наиболее часто встречаются уязвимости, относящиеся к ошибкам на этапе разработки, причем в значительной степени это касается необходимости проверок данных, которые поступают от клиента на обработку программой. Этому вопросу был посвящен отдельный бюллетень CERT — CERT Advisory CA-1997-25 Sanitizing User-Supplied Data in CGI Scripts. В качестве примера возможности реализации атаки приведем CERT Advisory CA-1997-24 Buffer Overrun Vulnerability in Count.cgi cgi-bin Program. В документе говорится о программе count. cgi, которая ведет подсчет посещений Веб-вервера. По причине недостаточной проверки данных, вводимых клиентом, возможно произвести переполнение стека. В результате Count.cgi исполнит команды злоумышленника, наделив их при этом правами доступа, равными правам доступа сервиса httpd в данной системе.

В целом, специальным образом подобранные некорректные (в смысле ско­рее "неожидаемые разработчиком") наборы данных представляют собой уг­розу, характерную не только для CGI. Известны случаи, когда использова­ние специальных символов ("/", "." и ряда других) в URL при обращении к Веб-серверу приводило к совсем иным последствиям, чем это предполага­лось разработчиками и администраторами Веб-сервера — от отказа в обслу­живании до возможности исполнения зловредного кода с высокими приви­легиями. Не будем приводить весь список подобных атак — он довольно однообразен (сформированный особым образом URL — в ответ недокумен­тированная реакция сервера). Остановим внимание специалистов на том вопросе, что, обеспечивая защиту своих Веб-серверов, например, с помо­щью межсетевых экранов, необходимо уделять внимание не только пра­вильной адресации и обращению к службам, но и тому, какие данные полу­чает конкретное приложение. Другими словами, строя защиту, необходимо в анализе угроз подниматься от сетевого и транспортного уровня сетевой модели — вверх до прикладного.

1.3.3.6. Атаки на клиентов: ActiveX, Java и другие

При взаимодействии клиента и Веб-сервера возможен запуск кода и на кли­ентской стороне; наиболее популярные технологии на сегодняшний день, это Java Virtual Machine и ActiveX. Необходимо сразу осознать, что загружае­мый с удаленного сервера код — это набор команд, которые ваш хост (ком­пьютер) будет исполнять, возможно, не информируя вас о результатах. По­этому и относиться к такому коду следует соответственно. Возможно, мы загружаем этот код с доверенного сервера, но что мы можем, знать о его безопасности? Достаточно ли уверенности, что механизм электронно-цифровой подписи сообщил нам, что код не был модифицирован после то­го, как его разместил на сервере уполномоченный программист? Возможно, мы считаем, что настройка прав такова, что данный код не сможет получить большие привилегии?

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

П С какого компьютера (хоста) мы сейчас работаем? Это компьютер в Ин­тернет-кафе, обычная пользовательская рабочая станция или компью­тер, выполняющий важную роль в сети либо хранящий конфиденциаль­ную информацию?

П Что мы делаем? Либо это просто просмотр новых сайтов для удовольст­вия, либо поиск необходимой информации в Интернете, либо работа с функциональностью удаленного сервера?

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

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

Но должны быть соблюдены все необходимые меры по обеспечению безопасности:

С") идентификация и аутентификация и клиента и сервера;

П создание защищенного канала обмена информацией;

О проверка целостности и авторизованности загружаемого кода;

П обеспечение настройки прав, с которыми будет работать код;

D доступность данных для кода и т. п.