Управление доступом для кода для приложения ASP.NET 4

Статья
10/15/2014

Управление доступом для кода — это механизм обеспечения безопасности платформы .NET Framework ("песочница"), который используется приложением ASP.NET для принудительного ограничения возможности выполнения кода. Управление доступом для кода реализовано в ASP.NET, начиная с версии ASP.NET 1.1, с помощью понятия уровней доверия.

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

Ниже перечислены вопросы, которые рассматриваются в этом разделе.

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

В данном разделе предполагается, что пользователь знаком с понятиями управления доступа для кода .NET Framework и уровней доверия в ASP.NET. Сведения об этих темах см. в следующих документах.

How to: Use Medium Trust in ASP.NET 2.0
Using Code Access Security with ASP.NET
Изменения системы безопасности в платформе .NET Framework 4
Серия блогов Фаркаса Шона (Shawn Farkas), посвященных политике разграничения доступа кода и среде CLR
В этом разделе содержатся следующие подразделы:
Обзор модели управления доступом для кода ASP.NET 4
Однородные домены приложений
Условный оператор APTCA
Прозрачность для безопасности и принципы ее работы в ASP.NET 4

Обзор модели управления доступом для кода ASP.NET 4

В ASP.NET 4 реализовано несколько фундаментальных изменений управления доступом для кода по сравнению с ASP.NET 3.5 и более ранними версиями. Часть этих изменений описана ниже.

По умолчанию домены приложений ASP.NET 4 с частичным доверием являются однородными. Таким образом создается ограниченный набор возможных разрешений для кода, выполняющегося в домене приложения с частичным доверием. Это также означает, что граница доверия домена приложения сама связана с набором прав частичного доверия. В однородных доменах приложений политика безопасности не пересекается с политиками разграничения доступа кода уровня компьютера, пользователя или предприятия.

Примечание

Набор файлов декларативной политики доверия ASP.NET, необходимый для новой модели однородного домена приложения, немного отличается от файлов политики, используемых в более ранних версиях ASP.NET.В результате, после установки ASP.NET 4 на компьютере содержатся два набора файлов политики частичного доверия ASP.NET.Один набор предназначен для новой модели управления доступом для кода, а второй набор применяется, если приложения настроены для использования модели управления доступом для кода ASP.NET до версии 4.
В более ранних версиях ASP.NET атрибут AspNetHostingPermission указывался почти во всех открытых классах, относящихся к ASP.NET, чтобы запретить использование типов ASP.NET в средах с частичным доверием, не связанных с Интернетом. Например, наличие атрибута AspNetHostingPermission запрещало использование большинства классов ASP.NET в приложении ClickOnce с частичным доверием. (Сведения об управлении доступом для кода в приложениях ClickOnce см. в разделе Управление доступом для кода для приложения ClickOnce.) Вместо атрибута AspNetHostingPermission, для достижения того же результата в ASP.NET 4 используется другая технология управления доступом для кода, которая называется условным атрибутом APTCA (основанным на типе AllowPartiallyTrustedCallersAttribute). Вследствие этого атрибут AspNetHostingPermission был удален из большинства типов и членов ASP.NET.
В ASP.NET 4 многие системные сборки были обновлены для использования модели прозрачности для безопасности среды CLR. Модель прозрачности в ASP.NET 4 похожа на модель прозрачности, используемую в Silverlight. Дополнительные сведения о прозрачности кода см. в разделе Прозрачный для системы безопасности код.

Эффект указанных изменений проявляется при использовании пользовательских политик разграничения доступа кода среды CLR, созданных с помощью таких средств, как caspol.exe. Эти изменения также повлияют на веб-приложения с частичным доверием, которые основаны на сборках, развернутых в глобальном кэше сборок, для выполнения привилегированных операций, если в стеке вызовов активен только код ASP.NET или .NET Framework. В следующих подразделах рассматриваются изменения управления доступом для кода.

Однородные домены приложений

В этом подразделе описываются однородные домены приложений. В нем рассматриваются изменения поведения, произошедшие с версии ASP.NET 2.0, которые привели к возникновению однородных доменов приложений. Здесь также изучаются доступные для настройки параметры совместимости и изменения кода, которые можно выполнить для выполнения кода в однородных доменах приложений.

Сокращение количества возможных наборов разрешений

Однородные домены приложений — это домены приложений с частичным доверием, определяющие общий набор разрешений для выполнения кода. В однородном домене приложения, размещенном в ASP.NET 4, загружаемый код связан с одним из двух наборов разрешений. Код выполняется либо с полным доверием (код из глобального кэша сборок всегда выполняется с полным доверием), либо с набором разрешений частичного доверия, определенным текущим параметром trustLevel. (Дополнительные сведения см. в разделе Элемент trustLevel для элемента securityPolicy (схема параметров ASP.NET).)

Примечание

Для доменов приложений ASP.NET 4 по умолчанию задано полное доверие.Поведение однородного домена в ASP.NET 4 используется, только если для атрибута name элемента trustLevel задано значение, отличное от Full.

Это поведение отличается от приложений с частичным доверием в более ранних версиях ASP.NET. В более ранних версиях можно было создать несколько наборов разрешений, каждый из которых содержал собственный набор прав и собственные условия членства. Однородные домены приложений впервые появились в .NET Framework 4 из-за того, что стало сложно обрабатывать подобные сценарии, включающие смешанные разрешения. Было трудно создать несколько наборов разрешений, каждый из которых содержит различные уровни разрешений, а затем удостовериться, что эти различные уровни разрешений действительно применены, с учетом всех условий выполнения кода. Например код может выполняться с применением отражения, код с полным доверием может запускать другой код с полным доверием от имени вызывающего объекта с частичным доверием и т. д. В наборе разрешений приходилось учитывать все такие условия. Однородные домены приложений существенно упрощают решения относительно управления доступом для кода за счет сокращения возможных вариантов выбора. Либо коду присваивается полное доверие, либо он получает единственный строго определенный набор разрешений частичного доверия. В случае ASP.NET строго определенный набор разрешений частичного доверия — это набор, который применяется для указанного уровня доверия ASP.NET.

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

Применение только политики частичного доверия ASP.NET

Набор разрешений частичного доверия устанавливается для домена приложения только узлом, который отвечает за создание данного домена приложения. В ASP.NET 4 это означает, что набор разрешений частичного доверия определяется только содержимым файла конфигурации частичного доверия, который расположен в подкаталоге CONFIG каталога установки платформы .NET Framework. По умолчанию данные политики ASP.NET для доменов приложений ASP.NET 4 с частичным доверием больше не пересекаются с параметрами политики разграничения доступа кода уровня предприятия, компьютера или пользователя.

Сведения глобальной политики разграничения доступа кода (политики, разработанной с помощью таких средств, как caspol.exe или средства настройки MMC Mscorcfg.msc) теперь не применяются к однородным доменам приложений ASP.NET 4. (ASP.NET можно настроить для использования более ранней модели управления доступом для кода, в которой параметры ASP.NET пересекаются с политиками уровня предприятия, компьютера и пользователя. Это устаревшее поведение рассматривается далее в данном подразделе.)

Наиболее значительное изменение произошло для приложений ASP.NET 4 с частичным доверием, размещаемых в UNC-ресурсах. В предыдущих выпусках для обеспечения применения политик частичного доверия ASP.NET приходилось использовать средство caspol.exe для повышения уровня доверия общей UNC-папки до полного доверия. Это делалось по той причине, что в более ранних версиях ASP.NET сначала применялась политика разграничения доступа кода среды CLR уровня компьютера по умолчанию. В результате, приложения, размещаемые в UNC-ресурсах, получали ограниченный набор разрешений, связанный с зоной интрасети. Поскольку домены приложений ASP.NET 4 с частичным доверием устанавливают политику только из файлов политик ASP.NET, физическое расположение веб-приложения больше не влияет на набор разрешений, назначаемый приложению с частичным доверием.

Побочный эффект этого изменения проявляется в сценарии, когда администратор решает заблокировать веб-сервер, чтобы по умолчанию запретить разрешения на выполнение для любого управляемого кода, а затем предоставить права выполнения отдельным приложениям ASP.NET. В предыдущих версиях ASP.NET для этого требовалось применить малоизвестное решение, описанное в статье базы знаний ИСПРАВЛЕНИЕ. Если группа кода My_Computer_Zone не связана с набором разрешений "Полное доверие", то при попытке выполнить веб-приложение ASP.NET 2.0 выводится сообщение об ошибке: "Приложение сервера недоступно". В ASP.NET 4 администратор может заблокировать веб-сервер для запрета или предоставления разрешений на выполнение, выполнив следующие действия.

Создайте пользовательский уровень доверия ASP.NET, файл политики которого сопоставлен с набором разрешений Nothing (пустым набором разрешений), а затем настройте все приложения ASP.NET для использования этого уровня доверия по умолчанию. (Это выполняется в корневом файле Web.config.)
Выборочно свяжите отдельные приложения ASP.NET со встроенными или пользовательскими уровнями доверия, которые предоставляют управляемому коду разрешения на выполнение (и все другие необходимые разрешения). Для применения разрешений на уровне компьютера можно выборочно присвоить уровни доверия с помощью элементов location корневого файла Web.config.

Соглашения о расположении и именовании для файлов политик доверия

Соглашение о расположении и именовании в файлах политик разграничения доступа кода не отличается от аналогичного соглашения в предыдущих версиях ASP.NET. Уровнями доверия по умолчанию являются Full, High, Medium, Low и Minimal. Файлы политик, определяющие наборы разрешений частичного доверия для уровней с High по Minimal, расположены в подкаталоге CONFIG каталога установки платформы .NET Framework.

Имена файлов политик назначаются в соответствии со следующей схемой:

web_[trustlevelname]trust.config

Например, набор разрешений частичного доверия для уровня Medium содержится в файле с именем web_mediumtrust.config.

Изменения файлов политик доверия в ASP.NET 4

В большинстве случаев сведения в файлах политик разграничения доступа кода ASP.NET 4 не отличаются от данных, содержащихся в файлах политик предыдущих версий. Небольшие дополнения были внесены в функциональные возможности .NET Framework 3.5 и .NET Framework 4. Имя набора разрешений частичного доверия, связанного с однородным доменом приложения, — ASP.Net. Кроме того, по умолчанию любому коду, который находится в структуре каталога веб-приложения или каталога создания кода, предоставляются разрешения из набора разрешений с именем ASP.Net.

Файлы политик частичного доверия претерпели два изменения по сравнению с предыдущими версиями.

В конце каждого файла политики разграничения доступа кода ASP.NET 4 больше не указывается элемент CodeGroup, который сопоставляет полное доверие с ключом подписывания Майкрософт или ключом подписывания ECMA. Эти устаревшие записи были унаследованы из более ранних версий, в которых глобальному кэшу сборок не всегда по умолчанию предоставлялось полное доверие, и поэтому они удалены в версии ASP.NET 4.
Часть Assertion атрибута SecurityPermission удалена из всех файлов политик разграничения доступа кода ASP.NET 4. Фундаментальное изменение, внесенное в среде CLR платформы .NET Framework 4, состоит в том, что код с частичным доверием не может утверждать разрешения. Это означает, что выполнение кода с частичным доверием завершится неудачей даже при попытке утвердить уже имеющиеся у него разрешения.

Область частичного доверия

Границы однородных доменов приложений ASP.NET 4 являются частично доверенными. При выполнении приложения с частичным доверием требования безопасности приводят к проверке стека. Весь код в стеке оценивается относительно требуемых разрешений. В доменах приложений для ASP.NET 3.5 и более ранних версий выполнение ветвей кода, как правило, приводило к проверке стека вверх до границы домена приложения. Поскольку границам доменов приложений в версиях, предшествующих ASP.NET 4, по умолчанию предоставлялось полное доверие, проверки стека для некоторых ветвей кода могли завершаться успешно. В однородных доменах приложений ASP.NET 4 все проверки стека, достигающие границы домена приложения, оцениваются относительно набора разрешений частичного доверия, который теперь применяется для домена приложения.

Тот факт, что границы домена приложения теперь сами являются частично доверенными, — это наиболее часто встречающееся изменение управления доступом для кода, для которого, как правило, требуется изменение кода с полным доверием для обеспечения его работы в ASP.NET 4. Например, чтобы подавить требования безопасности и предотвратить их появление на границе домена приложения, команде разработки ASP.NET потребуется добавить целевые утверждения безопасности во множество внутренних ветвей кода. Если команда разработки не сделает этого, основные задачи, такие как компиляция страниц, завершатся неудачей, поскольку требования безопасности для подобных операций (например, разрешения файлового ввода-вывода для компиляции) не будут выполнены при сравнении с набором разрешений частичного доверия для таких уровней доверия, как Medium.

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

Ниже приведен список некоторых точек расширения ASP.NET, в которых может возникать подобная ситуация.

Пользовательский обработчик HTTP. Пользовательский обработчик вызывается на этапе выполнения обработчика в конвейере.
Пользовательский HTTP-модуль. Пользовательский HTTP-модуль вызывается в ходе любых событий конвейера, для которых зарегистрирован данный модуль.
Пользовательские поставщики построения и построители выражений. Эти типы вызываются приложением ASP.NET, когда оно выполняет синтаксический анализ и компиляцию исполняемого содержимого, такого как ASPX-файлы.
Поставщик диспетчеров ролей. Пользовательский поставщик может вызываться в ходе события AuthorizeRequest в конвейере.
Поставщик профиля. Пользовательский поставщик может вызываться для автоматического сохранения данных профиля в ходе события EndRequest.
Поставщик мониторинга работоспособности. Пользовательский поставщик может вызываться в произвольные моменты времени для сохранения собранных данных мониторинга работоспособности.

Изменение поведения управления доступом для кода демонстрируется на примере простого пользовательского обработчика HTTP. В следующем примере код обработчика пытается прочесть текстовый файл, расположенный в корневой папке диска C:\.

Public Class CustomHandler 
    Implements IHttpHandler 
    Public Sub ProcessRequest(ByVal context As HttpContext) 
        Dim data As String = File.ReadAllText("c:\testfile.txt") 
        context.Response.Write(data) 
    End Sub 
    
    Public Sub New() 
    End Sub 
    
    Public ReadOnly Property IsReusable() As Boolean 
        Get 
            Return False 
        End Get 
    End Property 
End Class

public class CustomHandler : IHttpHandler

{

public void ProcessRequest(HttpContext context)

{

string data = File.ReadAllText("c:\\testfile.txt");

context.Response.Write(data);

}

public CustomHandler() { }

public bool IsReusable { get { return false; } }

}

Если обработчик подписан, помечен атрибутом AllowPartiallyTrustedCallersAttribute и развернут в глобальном кэше сборок, то при использовании обработчика в приложении с уровнем доверия Medium в ASP.NET 3.5 или более ранней версии код будет успешно выполнен. Уровень доверия Medium выбран в этом примере потому, что при этом уровне набор разрешений частичного доверия позволяет операции ввода-вывода для чтения файла или записи в файл только в структуре каталога приложения. Полностью доверенный код, такой как код обработчика из показанного примера, способен получить доступ к другим расположениям файлов в ASP.NET 3.5 и более ранних версиях. Это происходит потому, что при выполнении обработчика в стек помещается только полностью доверенный код и границы домена приложения сами являются полностью доверенными. В результате, требование файлового ввода-вывода из вызова метода ReadAllText неявно выполняется, поскольку граница домена приложения является полностью доверенной.

Однако тот же код обработчика, используемый в приложении ASP.NET 4 с уровнем доверия Medium, завершится неудачей, поскольку вызов метода ReadAllText приведет к требованию файлового ввода-вывода для доступа к текстовому файлу с целью его чтения. Требование файлового ввода-вывода приведет к проверке стека, которая в конечном счете достигнет границы домена приложения. В ASP.NET 4 граница домена приложения связана с набором разрешений уровня доверия Medium, и этот набор разрешений не предоставляет доступ к корневой папке диска C:\. Поэтому требование файлового ввода-вывода не выполняется.

В ASP.NET 4 необходимо подавить проверку стека. Для этого используется атрибут SecurityAction.Assert атрибута FileIOPermission в методе ProcessRequest. В следующем примере показано использование атрибута FileIOPermission для этой цели.

[Visual Basic]

Public Class CustomHandler 
    Implements IHttpHandler 

    <FileIOPermission(SecurityAction.Assert, Read = "c:\testfile.txt")> _ 
    Public Sub ProcessRequest(ByVal context As HttpContext) 
        Dim data As String = File.ReadAllText("c:\testfile.txt") 
        context.Response.Write(data) 
    End Sub 
    
    Public Sub New() 
    End Sub 
    Public ReadOnly Property IsReusable() As Boolean 
        Get 
            Return False 
        End Get 
    End Property 
End Class

[C#]

public class CustomHandler : IHttpHandler

{

[FileIOPermission(SecurityAction.Assert, Read = "c:\\testfile.txt")]

public void ProcessRequest(HttpContext context)

{

string data = File.ReadAllText("c:\\testfile.txt");

context.Response.Write(data);

}

public CustomHandler() { }

public bool IsReusable { get { return false; } }

}

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

Настройка приложений ASP.NET 4 для использования модели управления доступом для кода ASP.NET 2.0

Приложения ASP.NET 4 можно настроить для использования поведения управления доступом для кода ASP.NET 1.0 и ASP.NET 2.0. В ASP.NET 4 элемент trust предоставляет новый атрибут legacyCasModel, для которого по умолчанию задано значение false. Задав для этого атрибута значение true, можно настроить приложение ASP.NET 4 для использования большинства аспектов (но не всех) поведения управления доступом для кода более ранних версий.

Задание значения true для атрибута LegacyCasModel приводит к следующему.

Границы домена приложения с частичным доверием используют полное доверие. Это означает, что в сценариях, когда полностью доверенный код выполняется со стеком, содержащим только полностью доверенный код, не требуется использовать утверждения для подавления требований безопасности.
Определенные для .NET Framework 4 параметры политик разграничения доступа кода уровней предприятия, компьютера и пользователя пересекаются с политикой разграничения доступа кода ASP.NET. Это означает, что применяются все пользовательские разрешения, созданные с помощью средства caspol.exe или Mscorcfg.msc в .NET Framework 4.

Примечание

Поскольку базовые файлы политики безопасности и средство caspol.exe для .NET Framework 4 находятся в каталоге, отличном от аналогичного каталога для .NET Framework 2.0, любая пользовательская политика безопасности, созданная для платформы .NET Framework 2.0, должна быть заново создана для .NET Framework 4 с помощью версии caspol.exe, предназначенной для платформы .NET Framework 4.
Можно указать несколько пользовательских наборов разрешений, применяемых к различным сборкам.

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

Сборки ASP. NET 4 по-прежнему помечаются условным атрибутом APTCA (условный атрибут APTCA описывается далее в этом разделе). Условный атрибут APTCA нельзя вернуть в устаревший режим, поскольку это привело бы к удалению атрибута AspNetHostingPermission из большинства общедоступных API ASP.NET 4. Невозможно эффективным образом добиться того, чтобы данное разрешение применялось к общедоступным API ASP.NET, выполняемым в устаревшем режиме управления доступом для кода, и не применялось, когда сборки выполняются в новой модели управления доступом для кода.
Коду с частичным доверием больше не позволяется утверждать разрешения. Код, которому ранее было предоставлено частичное доверие, мог вызвать метод Assert и успешно утвердить любое предоставленное ему разрешение. В .NET Framework 4 код с частичным доверием больше не может выполнять утверждения безопасности, независимо от модели управления доступом для кода, установленной для приложения ASP.NET.

Чтобы отделить наборы разрешений, применяемые в устаревшей модели управления доступом для кода, от единственного набора разрешений, применяемого в новой модели управления доступом для кода, в ситуации, когда для атрибута LegacyCasModel элемента trust задано значение true, ASP.NET 4 считывает данные политики разграничения доступа кода из другого набора файлов конфигурации частичного доверия. Предусмотрено две версии каждого файла политики доверия, существующего для встроенных уровней доверия ASP.NET. ASP.NET считывает одну версию для новой модели управления доступом для кода и другую версию для устаревшей модели управления доступом для кода. Например, при выполнении в устаревшем режиме с уровнем доверия Medium приложение ASP.NET 4 считывает файл политики с именем legacy.web_mediumtrust.config. Обратите внимание, что в начале имени файла стоит суффикс "legacy". ASP.NET 4 использует для всех файлов политик разграничения доступа кода то же соглашение об именовании, что и для встроенных уровней доверия ASP.NET. Основное отличие между устаревшими и новыми файлами политики разграничения доступа кода заключается в том, что устаревшие файлы содержат определение CodeGroup, которое ссылается на ключ подписывания Майкрософт и ключ подписывания ECMA.

Поскольку можно настроить приложение для использования старой модели управления доступом для кода для существующих приложений, может потребоваться установить значение true для параметра LegacyCasModel и таким образом избежать внесения каких-либо изменений. Однако важно понимать, что устаревший параметр предназначен главным образом для упрощения переноса существующих приложений в модель управления доступом для кода ASP.NET 4. В будущем команды среды CLR и приложения ASP.NET будут осуществлять разработку и создание кода преимущественно для новой модели управления доступом для кода.

Приложение Silverlight 2 стало первой функциональной областью .NET Framework, которая перешла на новую модель. Целью платформы .NET Framework является перенос всех сценариев частичного доверия для настольных компьютеров и серверов в новую модель управления доступом для кода. В результате, рекомендуется прилагать усилия для восстановления работоспособности приложений в новой модели управления доступом для кода. Аналогичным образом, администраторы, которые ранее применяли средства caspol.exe и Mscorcfg.msc, должны вместо этого заниматься настройкой файлов политики частичного доверия и назначений разрешений ASP.NET.

Настройка назначения набора разрешений в модели управления доступом для кода ASP.NET 4

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

Можно настроить файл политики частичного доверия для отдельного уровня доверия (этот метод применялся и в предыдущих версиях ASP.NET).
Можно статически настроить полностью доверенные сборки ASP.NET 4.
Можно использовать тип HostSecurityPolicyResolver ASP.NET 4 для ограниченного доступа к функциям класса HostSecurityManager среды CLR.

Первые два метода позволяют выполнять декларативные настройки, а третья возможность позволяет вносить изменения в код.

Настройка файлов политики для уровня доверия

Первый метод изменения файлов политики частичного доверия ASP.NET не отличается от аналогичного метода в предыдущих версиях ASP.NET: можно изменить набор разрешений в именованном наборе разрешений ASP.NET. Можно также добавить дополнительные определения CodeGroup, содержащие пользовательские условия членства. Как отмечалось выше, новые настройки управления доступом для кода должны выполняться в файлах политики частичного доверия, таких как web_mediumtrust.config. Файлы, имена которых начинаются с суффикса "legacy", анализируются и используются в том случае, если для атрибута LegacyCasModel элемента trust задано значение true.

В ASP.NET 4 все пользовательские определения CodeGroup должны сопоставляться с одним из трех возможных наборов разрешений: FullTrust, ASP.Net (набор разрешений частичного доверия) и Nothing. Поскольку домены приложений ASP.NET 4 с частичным доверием являются однородными по умолчанию, оценка пользовательских записей политики должна приводить к использованию ограниченного подмножества наборов разрешений. Несмотря на кажущуюся возможность определения самых разных именованных наборов разрешений в модели управления доступом для кода ASP.NET 4, выполнение любого кода, оценка которого приводит к использованию набора разрешений, отличного от FullTrust, ASP.Net или Nothing, завершится исключением SecurityException. Это означает, что среда CLR не распознает результирующий набор разрешений.

Набор разрешений FullTrust означает, что код выполняется с полным доверием. Набор разрешений ASP.Net — это именованный набор разрешений частичного доверия, который, как правило, используется для доменов приложений с частичным доверием. Как описывалось выше, набор Nothing нельзя считать полноценным набором разрешений, распознаваемым средой CLR, поскольку он является пустым. Если среда CLR определяет, что сборка связана с пустым набором разрешений, среда CLR вызывает исключение SecurityException и не загружает сборку.

Кроме того, ASP.NET 4 позволяет изменить имя набора разрешений ASP.Net с помощью атрибута PermissionSetName элемента trust. Можно задать другое имя для атрибута PermissionSetName. Во время выполнения ASP.NET 4 выполнит поиск элемента PermissionSet с тем же именем в файле политики частичного доверия. Затем этот именованный набор разрешений будет использоваться в качестве набора разрешений частичного доверия для однородного домена приложения. Однако выполнение этой задачи скорее всего не потребуется. Тем не менее возможность изменения имени набора разрешений частичного доверия на значение, отличное от ASP.Net, была добавлена для поддержки сред внешнего размещения, таких как SharePoint, которые определяют собственный именованный набор разрешений как сущность, отличную от набора разрешений ASP.NET по умолчанию. (Не забывайте, что в новой модели управления доступом для кода больше нельзя задать несколько именованных наборов разрешений, определяющих разрешения частичного доверия.) Несмотря на то что имя набора разрешений частичного доверия можно изменить на значение, отличное от ASP.Net, к приложению по-прежнему может применяться только один набор разрешений частичного доверия.

Указание сборок, которым будет предоставлено полное доверие

Второй метод декларативной настройки политики впервые появился только в ASP.NET 4; он позволяет явно задать список удостоверений сборок, которым будет всегда предоставляться полное доверие. Элемент конфигурации securityPolicy содержит новый дочерний раздел конфигурации fullTrustAssemblies. Раздел FullTrustAssembliesSection — это обычная коллекция, поддерживающая операции добавления, удаления и очистки и позволяющая указать один или несколько идентификаторов сборок, которым предоставляется полное доверие во время выполнения. В следующем примере демонстрируется раздел конфигурации fullTrustAssemblies.

<system.web>

<add assemblyName="MyCustomAssembly"

version="1.0.0.0"

publicKey="a 320 hex character representation

of the public key blob used with a

signed assembly"

</fullTrustAssemblies>

</securityPolicy>

</system.web>

Каждая запись в элементе fullTrustAssemblies определяет сборку по ее имени и версии, а также по 320-символьной строке, которая является шестнадцатеричным представлением открытой половины ключа подписывания.

Примечание

В будущем новые сборки .NET Framework смогут использовать 2048-битовые ключи подписывания.При выпуске новых сборок, использующих 2048-битовые ключи подписывания, будут созданы шестнадцатеричные строки длиной 576 символов.

Расположение сборки в определении не указывается. За поиск и загрузку сборок отвечает конкретная среда внешнего размещения (такая как ASP.NET 4). Если загруженная сборка соответствует сведениям, указанным в одном из элементов add раздела fullTrustAssemblies, сборке предоставляется полное доверие.

Раздел fullTrustAssemblies следует использовать для сборок, которые не развертываются в глобальном кэше сборок, но всегда предназначены для выполнения с полным доверием. Поскольку сборки, перечисленные в разделе fullTrustAssemblies, можно настроить в любом месте иерархии конфигурации (от корневого файла Web.config до отдельных файлов Web.config уровня приложения), использование данного параметра является более простым и гибким способом, чем применение условия членства и группы кода в файле политики частичного доверия. Списки fullTrustAssemblies для приложений можно настраивать путем указания разных данных для отдельных приложений. Это можно сделать в файлах Web.config уровня приложения или в корневом файле Web.config с помощью элементов location.

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

Программная настройка разрешений

Связь набора разрешений со сборкой можно также изменить программно путем создания пользовательской реализации типа HostSecurityPolicyResolver ASP.NET 4. Во время выполнения ASP.NET 4 использует собственную реализацию типа HostSecurityManager среды CLR. Объект HostSecurityManager вызывается средой CLR при каждой загрузке сборки. Одна из функций свойства HostSecurityManager заключается в возвращении объекта PermissionSet, который должен быть связан с указанной сборкой и набором свидетельств. ASP.NET 4 позволяет настроить этот процесс путем вызова пользовательского объекта HostSecurityPolicyResolver каждый раз, когда среда CLR запрашивает у ASP.NET 4 решение относительно набора разрешений.

Пользовательский объект HostSecurityPolicyResolver можно настроить с помощью атрибута HostSecurityPolicyResolverType элемента trust. Если ASP.NET 4 определяет, что пользовательский объект HostSecurityPolicyResolver настроен для приложения, то каждый раз, когда среда CLR запрашивает решение относительно набора разрешений, вызывается метод ResolvePolicy пользовательского сопоставителя. Однако, в отличие от объекта HostSecurityManager, объект HostSecurityPolicyResolver может возвращать ASP.NET 4 только ограниченное подмножество возможных решений. Метод ResolvePolicy может возвращать только следующие значения из перечисления HostSecurityPolicyResults.

DefaultPolicy. Указывает, что ASP.NET 4 следует использовать собственную логику для определения подходящего набора разрешений для сборки. Значение DefaultPolicy следует возвращать для сборок в тех случаях, когда не требуется, чтобы решение о наборе разрешений принималось объектом HostSecurityPolicyResolver. При возвращении значения DefaultPolicy ASP.NET определяет набор разрешений, предоставляемый сборке, на основе декларативных групп кода и условий членства, которые указываются в файле политики частичного доверия для текущего уровня доверия ASP.NET.
FullTrust. Сборке должно быть предоставлено полное доверие.
AppDomainTrust. Сборке должен быть предоставлен набор разрешений частичного доверия, связанный с доменом приложения. Это, как правило, означает, что сборке предоставляются разрешения, которые определены в именованном наборе разрешений ASP.Net.
None. Сборке будет предоставлен набор разрешений Nothing, который является пустым набором.

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

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

[Visual Basic]

Public Class MyCustomResolver 
    Inherits HostSecurityPolicyResolver 
    Public Overloads Overrides Function ResolvePolicy(ByVal evidence _
            As Evidence) As HostSecurityPolicyResults 
        Dim urlEvidence As Url = evidence.GetHostEvidence(Of Url)() 
        
        If (urlEvidence IsNot Nothing) AndAlso _
            (urlEvidence.Value.StartsWith("file:///C:/FullTrustExample_HSPR.dll")) Then 
            Return HostSecurityPolicyResults.FullTrust 
        End If 
        
        ' Specify that ASP.NET should perform its own logic.
        Return HostSecurityPolicyResults.DefaultPolicy 
    End Function 
End Class

public class MyCustomResolver : HostSecurityPolicyResolver
{ 
  public override HostSecurityPolicyResults 
                              ResolvePolicy(Evidence evidence)
  {
            Url urlEvidence = evidence.GetHostEvidence<Url>();
            if ( (urlEvidence != null)  && 
                 (urlEvidence.Value.StartsWith("file:///C:/FullTrustExample_HSPR.dll"))
               )
                return HostSecurityPolicyResults.FullTrust;

            // Specify that ASP.NET should perform its own logic.
            return HostSecurityPolicyResults.DefaultPolicy;
  }
}

Условный атрибут APTCA

В версиях платформы .NET Framework, предшествующих версии 4, многие полностью доверенной сборки (включая сборки ASP.NET), были помечены атрибутом AllowPartiallyTrustedCallersAttribute (APTCA). Этот атрибут предоставляет вызывающим объектам с частичным доверием доступ к открытым типам и членам, которые определены в сборках, помеченных таким образом. В платформе .NET Framework 4 среда CLR содержит вариант атрибута APTCA, который называется условным атрибутом APTCA (в краткой нотации условный атрибут APTCA обозначается как C-APTCA). Условный атрибут APTCA позволяет сборкам, помеченным атрибутом APTCA, сохранять характеристики APTCA только в определенных средах внешнего размещения. В результате, благодаря этому атрибуту в ASP.NET 4 упрощается процесс точного определения частично доверенных сред размещения, в которых вызывающие объекты с частичным доверием могут успешно вызывать общедоступные API ASP.NET 4.

Принцип работы условного атрибута APTCA

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

[assembly: AllowPartiallyTrustedCallers(PartialTrustVisibilityLevel=NotVisibleByDefault)]

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

Если сборка с условным атрибутом APTCA отсутствует в предоставленном средой размещения списке сборок, которые должны обрабатываться как помеченные атрибутом APTCA, сборка, тем не менее, загружается, но без характеристик APTCA. Фактическая доступность общедоступных API для частично доверенного пользовательского кода подобной сборки будет зависеть от того, является ли данная сборка на 100% прозрачной с точки зрения безопасности. Иными словами, доступность API для сборки определяется атрибутом SecurityTransparentAttribute уровня сборки. (Прозрачность для безопасности в ASP.NET 4 описана ниже в этом разделе.)

Ниже приведена обзорная информация о способах поведения общедоступных API в ASP.NET 4.

Для большинства сборок ASP.NET все общедоступные API становятся недоступными для вызывающих объектов с частичным доверием. По сути, это запрещает использование большинства общедоступных API ASP.NET 4 в любых средах с частичным доверием, отличных от веб-приложений.
Однако небольшое количество сборок ASP.NET, которые помечены как прозрачные на 100% с точки зрения безопасности, могут вызываться объектами с частичным доверием. Тем не менее, если ветви кода в этих сборках фактически достигнут остальную базу кода ASP.NET, вызов завершится неудачей. В результате получается такое же поведение, как в предыдущих выпусках ASP.NET, с той небольшой разницей, что вызовы интерфейсов API в сборках ASP.NET 4 продолжаются до сбоя.

Относительно сборок, помеченных как прозрачные с точки зрения безопасности, необходимо отметить следующее.
- Имеются только две сборки ASP.NET, которые помечены как прозрачные с точки зрения безопасности на уровне сборки: System.Web.DynamicData.dll и System.Web.RegularExpressions.dll.
- System.Web.Routing.dll не считается на 100% прозрачной с точки зрения безопасности в ASP.NET 4, поскольку все типы, которые были определены в этой сборке в предыдущих версиях ASP.NET, теперь перенесены в System.Web.dll. По сути, System.Web.Routing.dll в ASP.NET 4 — это сборка, содержащая только метаданные.

В ASP.NET 4 условный вариант атрибут APTCA находится на следующих сборках:

System.Web.dll.
System.Web.Extensions.dll.
System.Web.DynamicData.dll.
System.Web.DataVisualization.dll.
System.ComponentModel.DataAnnotations.dll.
System.Web.ApplicationServices.dll. Эта сборка впервые появилась в ASP.NET 4.
System.Web.Abstractions.dll. В ASP.NET 4 типы из этой сборки были перемещены в System.Web.dll.
System.Web.Routing.dll. В ASP.NET 4 типы из этой сборки были перемещены в System.Web.dll.

Сравнение условного атрибута APTCA и атрибутов разрешения на размещение ASP.NET

Условный атрибут APTCA позволил удалить атрибут AspNetHostingPermission из 99% общедоступных API ASP.NET 4. Атрибут AspNetHostingPermission по-прежнему используется в некоторых местах ASP.NET 4, но только там, где применение этого разрешения действительно имеет смысл. Во всех остальных случаях два показанных ниже способа использования атрибута AspNetHostingPermission вышли из употребления.

<AspNetHostingPermission(SecurityAction.LinkDemand,
                         Level=AspNetHostingPermissionLevel.Minimal)>
<AspNetHostingPermission(SecurityAction.InheritanceDemand,
                         Level=AspNetHostingPermissionLevel.Minimal)>

[AspNetHostingPermission(SecurityAction.LinkDemand,
                         Level=AspNetHostingPermissionLevel.Minimal)]
[AspNetHostingPermission(SecurityAction.InheritanceDemand,
                         Level=AspNetHostingPermissionLevel.Minimal)]

Эти определения разрешений использовались в более ранних версиях ASP.NET, чтобы запретить сборкам ASP.NET загружаться в средах с частичным доверием, отличных от Интернета. Самые большие проблемы вызывали частично доверенные управляемые элементы управления и управляемые приложения, загружаемые в браузеры, такие как Microsoft Internet Explorer и Mozilla Firefox. С помощью условного атрибута APTCA удается применить те же средства защиты, поскольку приложения ClickOnce и зависящие от браузера управляемые элементы управления не определяют сборки с условными атрибутами APTCA, которые должны обрабатываться как полностью доверенные сборки.

Настройка списка сборок с условными атрибутами APTCA в ASP.NET 4

Как указывалось выше, отдельные среды размещения могут предоставлять среде CLR список сборок с условным атрибутом APTCA, характеристики APTCA которых следует учитывать. ASP.NET 4 предоставляет среде CLR жестко закодированный список всех сборок ASP.NET 4. Если ASP.NET 4 не сделает этого, в веб-приложениях будет происходить ошибка при попытке выполнения первой строки внутреннего кода ASP.NET в домене приложения с частичным доверием.

В .NET Framework 4 условный атрибут APTCA является новым понятием управления доступом для кода, которое еще не реализовано в других частях платформы .NET Framework. Таким образом, вполне вероятно, что будущие версии .NET Framework будут включать дополнительные сборки с условным атрибутом APTCA. К тому же, по мере того как пользователи будут знакомиться с условным атрибутом APTCA и использовать его для собственных полностью доверенных сборок, набор сборок с условным атрибутом APTCA начнет увеличиваться. Поскольку ASP.NET 4 не может заранее знать все возможные сборки с условным атрибутом APTCA, в ASP.NET 4 предусмотрен раздел конфигурации, в который можно добавлять сборки с условным атрибутом APTCA.

Существующий раздел securityPolicy включает дочерний раздел конфигурации с именем partialTrustVisibleAssemblies. Это обычная коллекция, поддерживающая операции добавления, удаления и очистки и позволяющая указать один или несколько идентификаторов сборок, которые должны рассматриваться как APTCA (если они также помечены условным атрибутом APTCA). В следующем примере демонстрируется раздел partialTrustVisibleAssemblies.

<system.web>
  <securityPolicy>
    <partialTrustVisibleAssemblies>

      <add assemblyName="MyCustomAssembly"
           publicKey="a 320 hex character representation 
                      of the public key blob used with a 
                      signed assembly"
      />

    </partialTrustVisibleAssemblies>
  </securityPolicy>
</system.web>

Каждая запись в разделе partialTrustVisibleAssemblies определяет сборку по ее имени. Каждая запись также определяется 320-символьной строкой (например, 0x03FA4D...), которая является шестнадцатеричным представлением открытой половины ключа подписывания, используемого для сборки с условным атрибутом APTCA. Атрибут версии указывать не требуется. Для среды CLR требуются только имя сборки и маркер открытого ключа.

При включении сборки с условным атрибутом APTCA существенное влияние на производительность оказывает тот факт, что необходимо также включить транзитивное замкнутое выражение сборок с условным атрибутом APTCA. Например, если сборка A с условным атрибутом ATPCA зависит от сборки B с атрибутом APTCA, а сборка B с атрибутом APTCA зависит от сборки C с условным атрибутом ATPCA, при включении условного атрибута ATPCA для сборки А необходимо также включить условный атрибут APTCA для сборки C. В противном случае производительность приложения может снизиться. Например, если не включить полное замкнутое выражение условного атрибута ATPCA, совместное использование кода и образы NGen будут отключены.

Влияние условного атрибута APTCA на частично доверенные приложения, отличные от веб-приложений

В версиях ASP.NET, предшествующих ASP.NET 4, некоторые типы и пространства имен не были помечены атрибутом AspNetHostingPermission. Это позволяло вызывать такие типы из частично доверенных сред, отличных от ASP.NET, например из приложений ClickOnce. Ниже перечислены типы и пространства имен, которые можно было вызывать таким образом.

Типы пространства имен System.Web.ClientServices.
Типы пространства имен System.Web.ClientServices.Providers.
Тип HttpUtility.

Типы System.Web.ClientServices нельзя использовать в частично доверенных средах .NET Framework 4, таких как ClickOnce. Поскольку содержащая эти типы сборка (System.Web.Extensions.dll) является сборкой ASP.NET 4, помеченной условным атрибутом APTCA, а технология ClickOnce не разрешает использовать атрибут APTCA для сборок с условным атрибутом APTCA, ни один из типов клиентских служб не может быть вызван из частично доверенных приложений ClickOnce.

Подобное поведение обусловлено несколькими причинами. Во-первых, платформа .NET Framework 4 разделена на клиентский и расширенный SKU, и предполагается, что многие приложения ClickOnce будут предназначены для клиентского SKU. Для рефакторинга типов клиентских служб ASP.NET в клиентский SKU потребуются значительные усилия.

Во-вторых, сложно определить, каким образом сохранить требуемые границы условного атрибута APTCA при рефакторинге клиентских типов. Поэтому в .NET Framework 4 типы клиентских служб доступны только для полностью доверенных сред, отличных от ASP.NET, например для приложений ClickOnce, которые настроены для выполнения с полным доверием при использовании расширенного SKU платформы .NET Framework 4.

Для типа HttpUtility влияние условного атрибута APTCA зависит методов, которые использовались пользователем, как показано в следующих сценариях.

Частично доверенный код вызывал метод HtmlEncode или HtmlDecode класса WebUtility. Тип WebUtility содержит реализации кодирования и декодирования HTML-кода ASP.NET, но они были переработаны и перемещены в пространство имен System.Net и теперь включены в сборку System.dll. Сборка System.dll доступна во всех частично доверенных средах размещения, поэтому нет никаких проблем с доступом методов типа WebUtility к частично доверенным приложениям, отличным от ASP.NET.
Частично доверенный код вызывал один из методов класса WebUtility. В этом случае возникают те же проблемы, которые были описаны выше для типов клиентских служб. То есть в платформе .NET Framework 4 класс WebUtility доступен только для полностью доверенных вызывающих приложений, отличных от ASP.NET.

Прозрачность для безопасности в ASP.NET 4

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

Прозрачность для безопасности является мощным средством для таких компонентов .NET Framework, как ASP.NET. Она позволяет ASP.NET указывать среде CLR, что блоки кода ASP.NET никогда не будут утверждать разрешения и код никогда не будет реализовывать или выполнять важные с точки зрения безопасности операции, такие как вызовы PInvoke машинного кода. Благодаря этому код .NET Framework может существенно сократить уязвимости безопасности большого количества общедоступных и внутренних API, которые возникают несмотря на то, что код .NET Framework находится в полностью доверенном глобальном кэше сборок.

Прозрачность для безопасности можно применить ко всей сборки или только к подмножеству кода в сборке. Безусловно, в идеальном случае следовало бы полностью помечать сборки как прозрачные для безопасности, однако часть кода .NET Framework имеет совершенно законное право на выполнение важных с точки зрения безопасности задач. Сборки, содержащие на 100% прозрачный для безопасности код, помечаются атрибутом SecurityTransparentAttribute уровня сборки.

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

Поведение классов, не помеченных атрибутами, является сложным. Тем не менее, говоря простым языком, не помеченные атрибутами типы сборок ASP.NET 4, в которых реализована новая модель прозрачности, считаются прозрачными для безопасности. Типы сборок ASP.NET 4, которые не содержат атрибуты прозрачности и не реализуют новую модель прозрачности, считаются надежными с точки зрения безопасности.

Прозрачность для безопасности на практике и наборы правил безопасности

Поскольку большая часть базы кода ASP.NET 4 содержится в сборке System.Web.dll, преобразование всего кода ASP.NET 4 в новую модель прозрачности не является целесообразным. Вместо этого можно разделить код ASP.NET 4 на следующие категории.

Код, который не реализует новую модель прозрачности и включает код в следующих сборках.
- System.Web.dll.
- System.Web.ApplicationServices.dll.
- System.Web.Mobile.dll. Типы этой сборки помечены как устаревшие в ASP.NET 4. Хотя эта сборка по-прежнему существует, рекомендуется прекратить использование ее типов в ближайшем будущем.
Код, который реализует новую модель прозрачности и включает код в следующих сборках.
- System.Web.Extensions.dll.
- System.Web.DynamicData.dll (на 100% прозрачная для безопасности).
- System.Web.RegularExpressions.dll (на 100% прозрачная для безопасности).
- System.ComponentModel.DataAnnotations.dll.
- System.Web.DataVisualization.dll.
Содержащие только метаданные сборки, типы которых были перемещены в другую сборку ASP.NET, в том числе следующие сборки.
- System.Web.Abstractions.dll. Типы, которые содержались в этой сборке в предыдущих версиях ASP.NET, перемещены в сборку System.Web.dll. В результате, сборка Sytem.Web.Abstractions.dll содержит только метаданные в ASP.NET 4.
- System.Web.Routing.dll. Типы, которые содержались в этой сборке в предыдущих версиях ASP.NET, перемещены в сборку System.Web.dll. В результате, сборка System.Web.Routing.dll содержит только метаданные в ASP.NET 4.

В среде CLR платформы .NET Framework 4 представлено новое понятие, которое называется набором правил безопасности. Предусмотрено два уровня конфигураций SecurityRuleSet: уровень один и уровень два. Конфигурация SecurityRuleSet для всех типов задается с помощью атрибута SecurityRulesAttribute уровня сборки. Сборки ASP.NET 4, которые реализуют новую модель прозрачности, помечаются следующим атрибутом уровня сборки:

System.Security.SecurityRules(RuleSet=System.Security.SecurityRuleSet.Level2)

Сборки ASP.NET 4, которые используют модель прозрачности, унаследованную из .NET Framework 2.0 (что в действительности означает для ASP.NET полное отсутствие прозрачности, поскольку в версиях ASP.NET, предшествующих ASP.NET 4, никогда не использовались понятия прозрачности), помечаются следующим атрибутом уровня сборки:

System.Security.SecurityRules(RuleSet=System.Security.SecurityRuleSet.Level1)

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

Все общедоступные API сборок ASP.NET, которые не приняли новую модель прозрачности (не считая устаревшие сборки или сборки с перенаправленными типами), могут вызываться из частично доверенного пользовательского кода и внутренне выполнять важные с точки зрения безопасности операции. Комбинация открытого доступа для частично доверенных вызывающих приложений и возможности выполнения важных с точки зрения безопасности операций приводит к тому, что более старый код ASP.NET 4 нуждается в тщательной проверке. Однако, поскольку большинство новых функций ASP.NET реализовано в более новых сборках, таких как System.Web.Extensions.dll и System.Web.DynamicData.dll, или в отдельных выпусках, например в ASP.NET MVC, большинство нового кода ASP.NET является прозрачным для безопасности и, вследствие этого, по умолчанию более безопасным по сравнению со старым кодом.

По умолчанию среда CLR считает общедоступные API всех сборок ASP.NET 4, помеченных атрибутом SecurityRuleSet.Level1, безопасными (что эквивалентно применению атрибута SecuritySafeCriticalAttribute), если среда внешнего размещения предоставляет сборке атрибут APTCA. Если атрибут APTCA не предоставляется, среда CLR инициирует требование ссылки для полного доверия, которое завершается неудачей, если в стеке содержится частично доверенный пользовательский код. Другими словами, если сборке ASP.NET, помеченной атрибутом SecurityRuleSet.Level1, не предоставляется атрибут APTCA, возникает то же поведение, которое существовало в предыдущих выпусках .NET Framework, когда частично доверенный код пытался вызвать полностью доверенную сборку, не помеченную атрибутом APTCA.

По умолчанию среда CLR считает общедоступные API всех сборок ASP.NET 4, помеченных атрибутом SecurityRuleSet.Level2, прозрачным для безопасности (что эквивалентно применению атрибута SecurityTransparentAttribute), если среда внешнего размещения предоставляет сборке атрибут APTCA. В противном случае возникает следующее поведение.

Если атрибут APTCA не предоставлен и сборка, помеченная атрибутом Level2, не является на 100% прозрачной для безопасности, среда CLR считает открытую контактную зону критической с точки зрения безопасности. В результате, в работе любого частично доверенного вызывающего приложения, которое пытается использовать открытую контактную зону, скорее всего произойдет сбой с исключением MethodAccessException, TypeAccessException или FieldAccessException.
Если атрибут APTCA не предоставлен и сборка, помеченная атрибутом Level2, является на 100% прозрачной для безопасности, частично доверенные вызывающие приложения смогут успешно вызвать любой общедоступный API данной сборки. На практике это означает, что исключение SecurityException возникает позднее в пути вызова, когда код из сборки, на 100% прозрачной для безопасности, фактически вызывает сборку ASP.NET уровня 1 или сборку ASP.NET уровня 2, которая не является на 100% прозрачной для безопасности.

Прозрачность и компиляция ASP.NET

Реализация новой модели управления доступом для кода и новой модели прозрачности для безопасности в ASP.NET 4 также оказала влияние на выходные данные, создаваемые системой компиляции ASP.NET. Это относится к таким элементам, как сборки страниц, прекомпилированные сборки и скомпилированные результаты каталога App_Code. Система компиляции изменяет свое поведение в зависимости от настройки атрибута LegacyCasModel элемента trust.

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

Настройка атрибута legacyCasModel	Уровень доверия веб-сайта	Атрибуты, применяемые к скомпилированным сборкам
False (новая модель управления доступом для кода)	Полное доверие	SecurityRules(SecurityRuleSet.Level2)
	Уровень доверия High или ниже	SecurityRules(SecurityRuleSet.Level2)
SecurityRules(SecurityRuleSet.Level2)
True (старая модель управления доступом для кода)	Полное доверие	SecurityRules(SecurityRuleSet.Level1)
	Уровень доверия High или ниже	SecurityRules(SecurityRuleSet.Level1)

Поскольку система компиляции ASP.NET 4 изменяет свое поведение в зависимости от настройки атрибута LegacyCasModel элемента trust, могут налагаться ограничения на совместное использование скомпилированного кода различными приложениями ASP.NET 4 с частичным доверием. В целом, пользователи не должны заметить каких-либо изменений в поведении приложений. Однако в некоторых сценариях скомпилированные артефакты, созданные из частично доверенного приложения, для атрибута LegacyCasModel которого задано значение false (то есть использующего новую модель управления доступом для кода), не работают надлежащим образом при использовании с другими приложениями. В результате, в некоторых сценариях (например, в случае общей библиотеки скомпилированных элементов управления ASCX, которые подписаны, помечены атрибутом ATPCA и развернуты в глобальном кэше сборок), может потребоваться явно применить атрибуты безопасного и критического кода к части кода библиотеки, если она помечена атрибутом Level2.

См. также

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

Безопасность приложений ASP.NET в средах выполнения

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