Поделиться через


Стратегия безопасности WPF — безопасность платформы

Хотя Windows Presentation Foundation (WPF) предоставляет множество служб безопасности, он также использует функции безопасности от базовой платформы, включающую операционную систему, CLR и Internet Explorer. Эти слои объединены для предоставления WPF надежной, глубоко-защищенной модели безопасности, которая пытается избежать любой точки сбоя, как показано на следующем рисунке:

Иллюстрация безопасности WPF

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

В этом разделе содержатся следующие подразделы.

  • Безопасность операционной системы
  • Безопасность среды CLR
  • Безопасность Microsoft Internet Explorer
  • Связанные разделы

Безопасность операционной системы

Минимальным уровнем операционной системы, требуемой WPF является Windows XP SP2. Ядро Windows XP SP2 предоставляет несколько функций безопасности, которые формируют основу безопасности для всех приложений Windows, включая приложения, созданные с помощью WPF. В Windows Vista используются те же функции безопасности, что и в WPF, а также новые возможности. В этом разделе рассматривается широкий спектр этих средств безопасности, которые важны WPF также, как WPF интегрируется с ними для предоставления дальнейшей глубинной защиты.

Пакет обновления 2 (SP2) для Microsoft Windows XP

В дополнение к общему обзору и усилению Windows, существуют три ключевых возможности из Windows XP SP2, которые мы рассмотрим в данном разделе:

  • /GS компиляция

  • Microsoft Windows Update.

/GS Компиляция

Windows XP SP2 обеспечивает защиту путем перекомпиляции многих системных библиотек ядра, включая все зависимости WPF, такие как CLR, чтобы помочь уменьшить возможность переполнения буфера. Это достигается путем использовании параметра /GS с командной строки компилятора С/С++. Несмотря на то, что следует избегать переполнений буфера, /GS компиляция представляет пример глубинной защиты от возможных уязвимостей, которые случайно или преднамеренно создаются переполнениями буфера.

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

На высоком уровне, флаг компилятора /GS защищает против некоторых возможных переполнений буфера путем добавления особого объекта безопасности cookie для защиты возвращаемого адреса функции, которая содержит буферы локальных строк. После того, как функция возвращает значение, объект безопасности cookie сравнивается со своим предыдущим значением. Если значение было изменено, возможно произошло переполнение буфера и процесс будет остановлен с состоянием ошибки. Остановка процесса предотвращает выполнение потенциально вредоносного кода. Дополнительные сведения см. на веб-странице Параметр /GS (проверка безопасности буфера).

WPF компилируется с флагом /GS, чтобы добавить еще один уровень защиты в WPF приложения.

Улучшения в механизме обновлений Microsoft Windows

Microsoft Windows Update также было улучшено в Windows XP SP2 для упрощения процесса для загрузки и установки обновлений. Эти изменения значительно улучшили безопасность для пользователей WPF, помогая убедиться, что их система имеет последнюю версию, особенно в отношении обновлений безопасности.

Windows Vista

Пользователи WPF в Windows Vista получат дополнительные расширения безопасности операционной системы, включая "Least-Privilege User Access", проверку целостности кода, и изоляцию прав.

Управление учетными записями пользователей (UAC)

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

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

Одним из способов защититься от этой угрозы безопасности, это запускать приложения с использованием минимального объема необходимых прав. Это известно как принцип наименьших прав и является возможностью ядра операционной системы Windows Vista. Эта возможность называется управление учетными записями пользователей (UAC) и используется Windows Vista UAC в двух случаях:

  • Для запуска большинства приложений с правами UAC по умолчанию, даже если пользователь является администратором; только приложения, требующие права администратора будут запускаться с правами администратора. Для запуска с правами администратора, приложения должны быть явно отмечены либо в своем манифесте приложения, либо в качестве записи в политике безопасности.

  • Для обеспечения решений совместимости, таких как виртуализация. Например, многие приложения пытаются писать в запрещенные места, такие как C:\Program Files. Для приложений, выполняющихся под UAC, существует альтернативное расположение для каждого пользователя, которое не требует прав администратора для записи в него. Для приложений, запускаемых под UAC, UAC делает виртуальным C:\Program Files, поэтому приложения, которые считают, что они пишут в него, на самом деле осуществляют запись в альтернативное, индивидуальное для каждого пользователя, место. Этот тип работы совместимости позволяет операционной системе запускать многие приложения, которые ранее не запускались в UAC.

Проверка целостности кода

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

Процесс с ограниченными правами для приложений обозревателей

Приложения, размещенные в обозревателе WPF выполняются внутри изолированной зоны Интернета. Интеграция WPF с Microsoft Internet Explorer улучшает защиту за счет дополнительной поддержки.

Пакет обновления (SP2) для обозревателя Internet Explorer 6 и Internet Explorer 7 для XP

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

Internet Explorer 7 для Vista

В Windows Internet Explorer 7, WPF приложения выполняются в защищенном режиме. В частности, XAML browser applications (XBAPs) выполняется со средне-уровневой целостностью.

Слой глубинной защиты

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

См. раздел Использование учетной записи с минимальными привилегиями.

Безопасность среды CLR

common language runtime (CLR) предлагает ряд ключевых преимуществ безопасности, включая проверку достоверности и верификацию, Code Access Security (CAS) и Методологию Критической Безопасности.

Проверка достоверности и верификация

Для обеспечения изоляции и целостности сборки в CLR используется процесс проверки. Проверка CLR гарантирует, что сборки при проверке их формата файла Portable Executable (PE) для адресов, которые указывают на данные за пределами сборки, изолируются. При проверке CLR также обеспечивается целостность метаданных, встроенных в сборку.

Чтобы обеспечить безопасность типов, помочь предотвратить общие проблемы безопасности (например, переполнение буфера) и включить выполнение в изолированной среде путем изоляции подпроцесса, безопасность CLR использует концепцию проверки.

Управляемые приложения компилируются в Microsoft Intermediate Language (MSIL). Когда методы в управляемом приложении выполняются, его MSIL компилируется в машинный код через компиляцию Just-In-Time (JIT). JIT-компиляция включает процесс верификации, который применяет много безопасных и надежных правил, гарантирующих, что код не:

  • Нарушает соглашения о типе

  • Вызывает переполнение буфера

  • Осуществляет беспорядочный доступ к памяти.

Управляемый код, который не удовлетворяет правилам верификации, не допускается для выполнения, кроме случая, когда он считается надежным кодом.

Преимущества проверяемого кода являются главной причиной, почему WPF строится на .NET Framework. В пределах использования проверяемого кода, вероятность использования возможных уязвимостей значительно ниже.

Управление доступом для кода

Клиентский компьютер предоставляет множество ресурсов, к которым управляемое приложение может получить доступ, включая файловую систему, Реестр, службы печати, пользовательский интерфейс, отражение и переменные среды. До того, как управляемое приложение сможет получить доступ к любому из ресурсов на клиентском компьютере, оно должно получить на это разрешение .NET Framework Code Access Security (CAS). Разрешение в CAS является подклассом CodeAccessPermission; CAS реализует один подкласс для каждого ресурса, к которому управляемые приложения могут получить доступ.

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

  • Мой компьютер. Приложения запускаются с компьютера клиента (Максимально надежные).

  • Локальная Интрасеть. Приложения запускаются из интрасети (частично надежные).

  • Интернет. Приложения запускаются из интернета (Наименьшая надежность).

  • Надежные узлы. Приложения определяются надежным пользователем (Наименьшая надежность).

  • Ненадежные узлы. Приложения определяются надежным пользователем (Ненадежные).

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

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

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

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

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

Следующий рисунок иллюстрирует связь между зонами, наборами разрешений, разрешениями и ресурсами.

наборы разрешений управления доступом для кода

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

Рассмотрим XBAP приложение, описываемое ниже на странице:

            Dim fp As New FileIOPermission(PermissionState.Unrestricted)
            fp.Assert()

            ' Perform operation that uses the assert

            ' Revert the assert when operation is completed
            CodeAccessPermission.RevertAssert()
FileIOPermission fp = new FileIOPermission(PermissionState.Unrestricted);
fp.Assert();

// Perform operation that uses the assert

// Revert the assert when operation is completed
CodeAccessPermission.RevertAssert();

Чтобы выполнить этот XBAP, лежащий в основе WPF код должен выполнять больше функциональных возможностей, чем доступно для вызова XBAP, включая:

  • Создание дескриптора окна (HWND) для отрисовки

  • Диспетчеризация сообщений

  • Загрузка шрифта Tahoma

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

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

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

WPF делает это с помощью метода Assert разрешения. В следующем коде показано, как это происходит.

            Dim fp As New FileIOPermission(PermissionState.Unrestricted)
            fp.Assert()

            ' Perform operation that uses the assert

            ' Revert the assert when operation is completed
            CodeAccessPermission.RevertAssert()
FileIOPermission fp = new FileIOPermission(PermissionState.Unrestricted);
fp.Assert();

// Perform operation that uses the assert

// Revert the assert when operation is completed
CodeAccessPermission.RevertAssert();

Assert по существу предотвращает неограниченные разрешения, требуемые WPF из ограниченных разрешениями зоны интернета XBAP.

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

Развертывание ClickOnce

ClickOnce представляет собой полную технологию развертывания, которая входит в состав .NET Framework и интегрируется с Microsoft Visual Studio (подробные сведения см. на веб-странице Обзор развертывания ClickOnce). Отдельные WPF приложения могут развертываться используя ClickOnce, в то время как приложения обозревателя должны быть развернуты с ClickOnce.

Приложениям, развернутым с помощью ClickOnce предоставляется дополнительный слой безопасности через Code Access Security (CAS); фактически ClickOnce развернутые приложения запрашивают разрешения, которые им необходимы. Им предоставляются только эти разрешения, если они не превышают набора разрешений для зоны, из которой приложение развертывается. За счет уменьшения набора разрешений до самых необходимых, даже если они меньше, чем те, которые предоставляются набором разрешений из запускаемой зоны, число ресурсов, к которым приложение имеет доступ, уменьшается до самого минимума. Следовательно, если приложение перехвачено, вероятность повреждения компьютера клиента снижена.

Методология критической безопасности

WPF код, который использует разрешения чтобы включить изолированную зону Интернета для XBAP приложений, должен храниться на наивысшей возможной степени аудита и элемента управления безопасности. Для облегчения этого требования, .NET Framework обеспечивает новую поддержку для управляемого кода, который повышает права. В особенности, CLR позволяет вам определить код, который повышает права и помечает их SecurityCriticalAttribute; любой код, не помеченный SecurityCriticalAttribute становится прозрачным с помощью этой методологии. И наоборот, управляемому коду, который не отмечен SecurityCriticalAttribute, запрещено повышать права.

Методология Критической Безопасности позволяет организацию WPF-кода, которая повышает права доступа в ядре критической защиты, с оставшимся прозрачным кодом. Изоляция кода критической безопасности позволяет группе разработчиков WPF сконцентрироваться на дополнительном анализе безопасности и на элементе управления источника вышеупомянутого ядра критической защиты и выйти за пределы стандартных методов безопасности (см.: Стратегия безопасности WPF — проектирование безопасности).

Обратите внимание, что .NET Framework позволяет надежному коду расширить изолированную зону зоны Интернета XBAP, позволив разработчикам писать управляемые сборки, которые помечаются AllowPartiallyTrustedCallersAttribute (APTCA) и развертываются в глобальном кэше сборок (GAC) пользователя. Пометка сборки с APTCA является высоко чувствительной операцией безопасности, так как позволяет любому коду вызывать эту сборку, включая вредоносный код из Интернета. Крайняя осторожность и лучшие методы должны быть использованы при выполнении этой операции, и пользователи должны указывать, что доверяют этому программному обеспечению, для того, чтобы его установить.

Безопасность Microsoft Internet Explorer

Помимо сокращения вопросов безопасности и упрощения конфигурации безопасности, Microsoft Internet Explorer 6 (SP2) содержит несколько функций, которые являются улучшениями безопасности, которые повышают безопасность для пользователей XAML browser applications (XBAPs). Надежность этих функций пытается позволить пользователям больший контроль над обозреваемым ими содержимым.

Перед IE6 SP2, пользователи должны обратить внимание на любые из нижеперечисленных вещей:

  • Случайно всплывающие окна.

  • Сбивающие с толку скрипты перенаправления.

  • Многочисленные диалоговые окна безопасности на некоторых веб-узлах.

В некоторых случаях ненадежные веб-узлы будут пытаться обмануть пользователей путем имитации установки user interface (UI) или многократного отображения диалогового окна установки Microsoft ActiveX, возможно, даже если пользователь отменил ее. Следование этим методам, возможно, привело к тому, что значительное число пользователей обманным путем заставили принять неверные решения, что привело к установке шпионских программ.

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

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

Эти возможности также защищают пользователей, которые используют IE6 SP2 для перехода к веб-узлам, которые позволяют им загрузить и установить WPFприложения. В частности это происходит потому, что IE6 SP2 предлагает лучшие возможности пользователя, которые уменьшают вероятность для пользователей установить вредоносные или нелегальные приложения независимо от того, какая технология была использована для их построения, включая WPF. WPF добавляется к этим средствам защиты с помощью ClickOnce, чтобы облегчить загрузку приложений по Интернету. Поскольку XAML browser applications (XBAPs) выполняются в пределах изолированной зоны безопасности Интернета, они могут быть легко запущены. С другой стороны, автономные WPF приложения требуют полного доверия для выполнения. Для этих приложений, ClickOnce будет отображать диалоговое окно безопасности во время процесса запуска, чтобы убедиться в использовании дополнительных требований безопасности приложения. Тем не менее, оно должно быть инициировано пользователем, а также будет управляться логикой инициации пользователя, и может быть отменено.

Internet Explorer 7 объединяет и расширяет возможности безопасности IE6 SP2 как части нынешних обязательств, направленных на безопасность.

См. также

Основные понятия

Управление доступом для кода

Безопасность (WPF)

Безопасность частичного доверия в WPF

Стратегия безопасности WPF — проектирование безопасности

Другие ресурсы

Understanding Security in Microsoft Internet Explorer 6 in Windows XP SP2

Understanding and Working in Protected Mode Internet Explorer

Windows XP Service Pack 3

Windows Vista Security Guide