Оценка риска защиты Интернета, Часть 4: сетевые приложения

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

 Анализ сетевых приложений

            Из всех возможных служб Интернета DNS, e-mail и www наиболее популярны. Из них, Web службы - самые сложные и наиболее часто используемые злоумышленниками. Изначально являясь, простой текстовой информационной службой, Web постепенно развилась в очень функциональную диалоговую прикладную платформу, которая используется почти во всех приложениях, как в Интернете, так и во внутренних сетях. Главные продавцы признали силу Web и сделали существенные вклад в развитие ее платформ. Среди них:  Sun (Java), Microsoft, открытое общество (PHP) и другие, например, ColdFusion. На базе этих платформ обычному администратору очень легко развивать сложные приложения. Вследствие бурного развития Web все, как по мановению волшебной палочки, вдруг стали программистами. Web приложения часто развивались неквалифицированными и неопытными разработчиками. Даже самые опытные программисты  неосознанно делают ошибки, дающие потенциальным злоумышленникам точное направление, где искать уязвимое место, которое им нужно для проникновения в частную сеть. Что же говорить о программистах среднего уровня или даже ниже! Поскольку эти приложения создаются на стандартных платформах, они часто аналогичны и поэтому, как правило, имеют одинаково слабые места в защите.

            Как все более и более значимая технология в Интернете, распространенные сетевые приложения должны рассматриваться в каждой оценке безопасности. Хотя имеется проблема: мы знаем, что почти каждый, кто запускает DNS, автоматически запускает  BIND (Berkley Internet Name Domain). Таким образом, если  BIND имеет уязвимость, она затронет каждого. Уязвимость станет известной общественности, а ее подпись, в конечном счете, обнаружится сканерами уязвимости и попадет в базы данных уязвимостей.

            Мы можем проверить системы, используя такие сканеры и определить уязвимость, которая может нас затронуть. А как же поступать с уязвимостями, связанными с самодельным сайтом какого-нибудь клиента мелкой компании, типа Joe Soap Inc.. Обязательно ли включать их в наш сканер уязвимостей? Ответ: нет, потому что Web приложения так часто являются "самодельными", так что их уязвимости, вряд ли станут широко известными, так что каждое приложение нужно рассматривать индивидуально, пытаясь определить ошибки безопасности, возможно сделанные непрофессиональными программистами.

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

Проверка защиты сетевых приложений

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

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

•  HTML - Hyper Text Markup Language. Простой язык, использующийся для описания, того, как форматировать и показывать web-страницы. HTML использует команды, называющиеся "тэгами", чтобы объяснить браузеру, как web-страница должна выглядеть и как она должна вести себя. Например, тэг <A HREF> указывает, что последующий текст фактически является гиперсвязью с другой страницей; тэг <B>  указывает, что текст должен быть показан жирным шрифтом.
• HTTP - Hyper Text Transfer Protocol. Использует TCP-связь (обычно на 80 порту), чтобы перемещать данные между сервером сети и браузером. Протокол HTTP используется для того, чтобы транспортировать все файлы, используемые в HTML, включая текст, графику, звук, видео и активные элементы, типа Shockwave, Flash и Java Script.
• Формы – это специальные типы HTML элементов, которые позволяют пользователю отправлять данные обратно на web-сайт. Форма может состоять из любого числа полей различных типов. В невидимом поле содержится значение, которое не показывается браузером (более подробно мы расскажем об этом в пятой статье) и иногда используется программистами для контроля над  информацией, о чем пользователь может и не знать. В нормальное входное поле формы пользователь может вводить данные,  которые передаются обратно на web-сайт, извлекаются и обрабатываются приложением сервера, обычно CGI.
• CGI - Common Gateway Interface. Описывает для Web серверов стандартный способ передачи информации программам и отправления полученных данных  обратно браузеру для демонстрации. Имея CGI, Web разработчик более не ограничен использованием только статических страниц. Вместо этого, можно принять данные от пользователя, отправить их в работающую программу, а затем отослать результаты браузеру для демонстрации. Интерфейс CGI – очень старая технология, но, реально, она лишь недавно стала такой, какой является сейчас. Другие технологии типа Microsoft ASP (Active Server Pages) выполняют аналогичную функцию.
• Вебсайты, желающие сохранять информацию о своих посетителях, часто используют, так называемые, куки (cookies).  Куки – это небольшие объекты, содержащие данные (обычно в виде файла), посланные браузеру, который сохранит их для дальнейшего использования. При следующем посещении сайта пользователем, куки автоматически загружают сайт, в соответствии с информацией, записанной там. Вы, конечно, видели этот механизм в действии: сайт запоминает ваши предпочтения в предыдущее посещение. На самом деле, ваш  браузер использует куки, чтобы напомнить сайту о вас.
• Script - маленькая программа, которая не компилируется в exe-формат, пока не запустится. Вместо этого, каждая строчка читается, компилируется и исполняется транслятором при каждом запуске программы. Скрипты весьма сильны, потому что они - маленькие, их легко написать и можно запустить на многих платформах без изменения. Увеличивается количество приложений, написанных на скриптовых языках, таких, как ASP, PHP, PERL и Java.
• SSL - Secure Sockets Layer - протокол, который запускается «поверх» TCP и использует комбинацию из публичного кода и технологии симметричного шифрования, чтобы гарантировать конфиденциальность, целостность и подлинность для HTTP. Когда вы выбираете web-сайт, адрес которого начинается с букв "HTTPS://", вы направляете ваш браузер к туннелю связи с HTTP  по SSL. SSL - очень мощный механизм, но наиболее часто используется только для того, чтобы подтвердить подлинность сервера и засекретить связь между браузером и сервером.
• ODBC - Open Data Base Connectivity протокол - стандартный способ связи приложений с базами данных, без необходимости понимания особенностей специфического выполнения базы данных. ODBC обычно используется для связи web-сервера с базами данных. Архитектура приведена на рис. 1.
• Приложения для развития окружающей среды - используются для того, чтобы развивать сложные Web приложения легче и быстрее. Обычно они содержат множество элементов, включая: скриптовый (scripting) язык, оптимизированный для Web, компоненты многоразового использования, образцы и скрипты, генерацию кодов сеансов, связь с базой данных, и т.п.

                  Независимо от используемой платформы, основное большинство приложений имеет подобную основную архитектуру, как изображено ниже:

Рис. 1: Типичная архитектура Web  приложения.

                  На этом рисунке изображена популярная сетевая архитектура для Web  приложений. Web-сервер располагается в особо защищенной зоне сети, называемой демилитаризированной Зоной (DMZ). Используются два файрволла: один - чтобы защитить демилитаризованную зону от Интернета, а другой - чтобы защитить внутреннюю сеть от демилитаризованной зоны. Эта архитектура - хорошо продумана системой безопасности и создана для минимизации последствий в случае, когда Web сервер будет взломан. Однако два канала должны быть всегда рабочими в этой архитектуре. Пользователь всегда должен иметь возможность соединиться с web-сервером из Интернета, а web-сервер должен иметь возможность соединиться с сервером базы данных. Эти же два канала использует и нападающий, чтобы получить доступ к внутренней сети.

Сетевые приложения: основные вопросы

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

Вопрос 1: Кто эти люди?

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

Общий: С какой группой мы имеем дело? Какой у них основной бизнес? Каков их стиль и культура?

Частный: Кто разработал и развивал рассматриваемое приложение? Какие они имеют знания, квалификацию, каков их стиль?

Ответы на эти вопросы дадут нам понимание того, как приложение будет построено и где оно может содержать ошибки.

Вопрос 2: Как приложение работает?

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

1.Может ли приложение работать в диалоговом режиме? Если да, то где расположены диалоговые элементы? Не каждый сайт является диалоговым. Кроме того, некоторые сайты более диалоговые, чем другие. Вы должны найти диалоговые элементы сайта и определить, насколько они диалоговые в действительности.

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

3.Откуда приложение получает данные? Диалоговое приложение должно получать информацию из каких-то источников. Поскольку сетевые приложения не имеют "гражданства", необходимо найти место хранения данных пользователей. Определение места расположения конечного источника данных многое даст нам в понимании принципа работы приложения и того, как его можно взломать.

4.Как приложения получают данные? Итак, сайт получает данные из какого-то дополнительного источника. Возможно даже с отдаленного сервера. Каким образом? Имеется много вариантов, включая запросы HTTP,  XML, обычный вход в файл и вечно популярный ODBC. Каждый из этих подходов опять имеет сильные и слабые стороны, которые нужно определить.

5.Как они узнают меня? Многие сайты позволяют работать анонимно, то есть без установления личности, но некоторые сайты предпочитают познакомиться с вами, прежде, чем предоставить вам доступ. Если это так, вам нужно понимать, как происходит установление вашей личности. Какими методами (например, Basic Authentication), и где хранятся данные пользователей (например, в  NT SAM).

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

Вопрос 3: Почему они выбрали именно этот способ?

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

• Лень.  Часто выбирается более дешевая и легкая архитектура. Ленивый проект – самый опасный проект.
• Политика.  Часто технические люди вынуждены придерживаться некоторых технологий из-за стратегических или политических решений высокого уровня в данной организации. Например, часто можно встретить организации, чьи стратегии придерживаются  компании Microsoft или, реже, открытых источников. В этом случае архитектура, как правило, стандартна и хорошо известна.
• Неопытность.  Мы уже говорили о том, что многие разработчики Web приложений неопытны и неквалифицированны. Такие разработчики имеют тенденцию "заимствовать" и копировать программы с сайтов и других общественных источников, и склонны допускать глупые, любительские ошибки.
• Сверхопытность.  В нашей индустрии специалисты высочайшего класса в своей узкой области, часто пытаются переносить свой опыт на другие области. Определение  специфического "конька" разработчика подскажет вам, где можно даже не искать уязвимости, а в каких новых для разработчика областях уязвимости могут находиться.

Вопрос 4: Каковы типичные ошибки данной архитектуры?

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