Моделирование угроз для веб-приложений на основе веб-служб



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

Ключевые слова: анализ угроз, веб-сервисы, веб-приложения.

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

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

‒ Некоторые протоколы транспортного уровня, обычно HTTP.

‒ Протокол уровня обмена сообщениями на основе XML, обычно SOAP [9]

‒ Протокол уровня описания сервиса, обычно WSDL [10]

‒ Протокол уровня обнаружения сервисов, обычно UDDI [11]

В этой статье предполагаемой моделью связи веб-служб является SOAP через HTTP. Основные взаимодействия SOAP являются асинхронными и однонаправленными, но могут быть объединены для реализации процессов запроса/ответа или даже более сложных взаимодействий.

Сообщения SOAP — это сообщения на основе XML для обмена структурированной и типизированной информацией. SOAP может использоваться для реализации RPC, но фокус смещается на документооборот на основе информации в последней разработке веб-службы.

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

Рис. 1. Поток процесса SOAP-сообщения

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

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

Общая архитектура веб-приложений представлена в [1]. В рамках этой архитектуры для веб-приложений технология веб-служб может использоваться для различных целей. Некоторые примеры включают:

1. Упаковка устаревших приложений: включение функциональности устаревших приложений в веб-приложение часто выполняется путем предоставления устаревшему приложению фасада веб-службы, который может использоваться сервером приложений.
2. Разделение веб-сервера и сервера приложений: Если веб-сервер взаимодействует с сервером приложений по протоколу SOAP/HTTP вместо RPC, брандмауэру между DMZ (содержащим веб-сервер) и средним уровнем достаточно открыть порт 80.
3. Богатые клиенты: браузер может загружать компоненты клиентских приложений (например, Java-апплеты или сборки.NET) с веб-сервера. Эти компоненты могут взаимодействовать с веб-сервером с помощью веб-служб.
4. Интеграция служб “building block”: повторно используемые службы приложений, такие как проверка подлинности или хранение, могут быть доступны в виде веб-служб и использоваться в различных веб-приложениях.
5. Многоступенчатая обработка: веб-службы поддерживают асинхронную модель обмена сообщениями. Один запрос может пройти через несколько посредников до достижения конечного пункта назначения. Например, сервер проверки подлинности в качестве посредника может проверить подлинность сообщения SOAP до его прибытия на сервер приложений.
6. Виртуальные организации: веб-сервисы могут использоваться для интеграции бизнеса в бизнес, создания полезных федераций автономных субъектов.

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

Для того, чтобы сохранить список выявленных угроз в разумном размере, мы представляем только наиболее актуальные угрозы в этом разделе. Что касается этих угроз, то здесь дается лишь краткий обзор. Более подробно об этом можно прочитать в [14]. Для выявления наиболее значимых угроз мы делаем два предположения. Во-первых, мы предполагаем, что сетевые компании и серверы защищены в соответствии с передовой практикой. Мы учитываем, что внутренний злоумышленник может получить доступ к сети компании, но без каких-либо привилегий на любой из серверных систем. Во-вторых, мы предполагаем, что атаки будут направлены на сервер. Мы не рассматриваем атаки на клиента. Это объясняется тем, что разработчик/архитектор веб-приложений обычно занимается защитой ресурсов сервера и в любом случае не имеет большого контроля над клиентским программным обеспечением.

Учитывая возможные экземпляры веб-служб в веб-приложении, наиболее актуальным считается сценарий, в котором клиент маскируется при взаимодействии с веб-сервером. Слабая аутентификация клиента или ее отсутствие может привести к несанкционированному доступу к веб-службе. Если веб-служба пересекает границу доверия, могут возникнуть две другие соответствующие угрозы подмены. Если DMZ не может быть доверенным, может быть подмены угрозы между веб-сервером и сервером приложений. Если сервер приложений взаимодействует с удаленным сервером приложений, существует значительная угроза подмены в обоих направлениях (см. [12] для получения дополнительной информации).

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

‒ Заменяется SOAP-сообщение, что приводит к непреднамеренному дублированию действия сервера или несогласованности на сервере.

‒ Сообщение SOAP подделано или злонамеренно построено, что приводит к целому ряду проблем на стороне сервера, таких как раскрытие информации из-за брошенных исключений или нарушений из-за злонамеренного ввода (например, атаки SQL-инъекции в базу данных).

‒ WSDL-файл, отправляемый клиенту, содержащий важную контактную информацию (например, URL-адреса). Изменение этой информации может ввести клиента в заблуждение.

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

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

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

‒ Сообщения SOAP раскрываются, возможно, утечка конкретной информации приложения, такой как номера кредитных карт.

‒ Файлы WSDL без необходимости раскрываются, предоставляя злоумышленнику информацию о структуре приложения.

‒ Реализация веб-службы приводит к утечке информации о внутренних компонентах приложения, например, путем отправки сведений трассировки стека об ошибках.

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

Рассмотрим краткое описание технологий противодействия. Более подробно см. [14].

‒ “Не отказ”: “не отказ” противодействует угрозе подмены. Это можно сделать только на уровне приложения. Возможные технологии включают подписи XML и аудит на уровне приложений.

‒ Sandboxing: Sandboxing противодействует угрозам привилегии и могут быть предоставлены операционной системой (разделение процессов) или безопасности доступа кода.NET.

‒ Безопасное кодирование: безопасное кодирование противодействует всем видам угроз. Дополнительную информацию смотрите в [13].

‒ Обнаружение вторжений/мошенничества: обнаружение вторжений или мошенничества противодействует всем видам угроз. Как разработчик, процесс обнаружения вторжений или мошенничества можно упростить, предоставив хорошие данные аудита на уровне приложений.

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

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

Литература:

1. L. Desmet, B. Jacobs, F. Piessens, and W. Joosen. A generic architecture for web applications to support threat analysis of infrastructural components, Eighth IFIP TC-6 TC-11 Conference on Communications and Multimedia Security (CMS 2004), September 2004,UK,ppl55–160
2. Д. Де Кок, К. Вутерс, Д. Шеллекенс, Д. Сингли, и В. Пренил. Моделирование угроз для безопасности в веб-приложениях, восьмая конференция IFIP TC-6 TC-11 по Коммуникационной и Мультимедийной Безопасности (CMS 2004), сентябрь 2004 г., Великобритания, стр. 213–223
3. Р. Гримм и Х. Эйхштадт Моделирование Ошибок ASP.NET — Разработка Безопасных Приложений, восьмая конференция IFIP TC-6 TC-11 по Коммуникационной и Мультимедийной Безопасности (CMS 2004), сентябрь 2004, Великобритания, стр. 175–187
4. Е. Бертино, Д. Бруски, С. Франзони, И. Най-Фовино, С. Валтолина. Моделирование угроз для SQL, восьмая конференция IFIP TC-6 TC-11 по Коммуникационной и Мультимедийной Безопасности (CMS 2004), сентябрь 2004 г., Великобритания, стр. 189–201
5. В. Д. Чедвик. Моделирование угроз для Active Directory. Восьмая конференция IFIP TC-6 TC-11 по Коммуникационной и Мультимедийной Безопасности (CMS 2004), сентябрь 2004 г., Великобритания, стр. 203–212
6. Примечание W3C, SOAP: Протокол Доступа к Простым Объектам 1.1, май 2000 г., http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
7. Примечание W3C, язык описания веб-служб (WSDL) 1.1, 15 марта 2001 года, http://www.w3.org/TR/200 I/NOTE-wsdl-20010315/
8. Хартман, Флинн, Безносов, Кавамото. Освоение безопасности веб-сервисов. Издание Wiley 2003.
9. Говард, Леблан. Написание защищенного кода 2-ое издание, Microsoft Press, 2003.
10. Разработка проекта безопасного применения (DeSecA), заключительный доклад, май 2004 года.