Segurança de acesso a código em aplicativos ASP.NET 4

Código access segurança (CAS) é o.NET Frameworkmecanismo desegurança "(o" sandbox) que é usado por ASP.NET para impor restrições na capacidade de executar o código. ASP.NET implementou o segurança de acesso do código desde ASP.NET 1.1 usando o conceito de níveis de confiança.

Este tópico descreve o funcionamento do CAS no ASP.NET 4, com uma ênfase específica em como ele foi alterado desde as versões anteriores. Se você for novo para ASP.NET, as alterações, provavelmente não são de interesse. No entanto, este tópico inclui informações sobre como o CAS funciona na versão atual do ASP.NET, que pode afetar o design de novos aplicativos.

Este tópico discute os seguintes assuntos:

• Por que os níveis de diretiva de CAS não são mais usados e como isso afeta os cenários típicos, como a ativação parcial- ASP.NET aplicativos para execução a partir de compartilhamentos UNC.

• Como personalizar CAS o comportamento em ASP.NET 4.

• Problemas de compatibilidade quando você habilita o código confiável trabalhar com autoridades de certificação em ASP.NET 4.

Este tópico pressupõe que você entenda.NET Framework CAS e ASP.NET níveis de confiança. Para obter informações sobre esses tópicos, consulte os seguintes documentos:

• How to: Use Médio Confiar em ASP.NET 2.0

• Usando a segurança de acesso de Código com ASP.NET

• Alterações de segurança na.NET Framework 4

• Série de blog sobre a diretiva de CAS e o CLR, por Shawn Farkas

• This topic contains the following information:

• Visão geral sobre o ASP.NET modelo de segurança de acesso de Código 4

• Domínios de aplicativo homogêneos

• APTCA condicional

• Transparência da segurança e como ele funciona em ASP.NET 4

Visão geral sobre o ASP.NET modelo de segurança de acesso de Código 4

Em ASP.NET 4, houve várias alterações fundamentais para autoridades de certificação de ASP.NET versões 3.5 e versões anteriores, incluindo o seguinte:

• Por padrão, ASP.NET 4 parcial-domínios de aplicativo de confiança são homogêneos. Isso resulta em um conjunto restrito de conjuntos de permissão de possíveis para o código que está sendo executado em um parcial-domínio de aplicativo de confiança. Isso também significa que o limite de confiança de domínio de aplicativo é associado a um parcial-conjunto de conceder confiança. Em domínios de aplicativo de homogêneos, a diretiva de segurança não interseção com a computador-nível de usuário-nível ou diretivas de autoridades de certificação de nível de empresa-.

  Dica

  O novo modelo de domínio de aplicativo de homogêneos requer um conjunto de ASP\ de ASP.NET confiar em arquivos de diretiva que os arquivos de diretiva usados nas versões anteriores do ASP.NET.Como resultado, após você instalaroASP.NET 4, o computador contém dois conjuntos de ASP.NETparcial-confiar em arquivos de diretiva. O novo modelo de CAS usa um conjunto e o outro conjunto é usado quando os aplicativos são configurados para usar o préASP.NET 4 modelo de CAS.

• Em versões anteriores do ASP.NET, o AspNetHostingPermission atributo foi usado em público de quase todos os ASP.NET-classes relacionadas para evitar ASP.NET tipos sejam usadas em não-Web parcial-confiar em ambientes. Por exemplo, a presença da AspNetHostingPermission atributo impediu o uso da maioria dos ASP.NET classes em um parcial- ClickOnce aplicativode confiança. (Para obter informações sobre CAS em aplicativos de ClickOnce , consulte Código Acesso de segurança para <>>aplicativos ClickOnce.) Em vez de depender de AspNetHostingPermission atributo, ASP.NET 4 usa uma tecnologia diferente de autoridades de certificação que é conhecida como APTCA condicional (baseia o AllowPartiallyTrustedCallersAttribute tipo) para realizar o mesmo resultado. Como resultado, o AspNetHostingPermission atributo foi removido da maioria dos ASP.NET tipos e membros.

• Em ASP.NET 4, muitos dos assemblies do sistema foram atualizados para usar o modelo detransparência desegurançado CLR. O modelo de transparência em ASP.NET 4 é muito semelhante ao modelo de transparência , o que é usado no Silverlight. Para obter mais informações sobre o código de transparência, consulte Código Transparent de segurança.

Se você dependia de políticas personalizadas de CAS de CLR que foram criadas usando ferramentas como Caspol. exe, você verá os efeitos dessas alterações. As alterações também afetarão parcial-confiar em aplicativos Web que dependem de assemblies que são implantados no GAC para realizar operações privilegiadas, quando somente ASP.NET ou.Código do NET Framework foi ativo em uma pilha de chamadas. As seções a seguir discutem as alterações de CAS.

Domínios de aplicativo homogêneos

Esta seção descreve os domínios de aplicativo de homogêneos. Ele discute as alterações de comportamento desde ASP.NET 2.0 que resultam de domínios de aplicativo de homogêneos. Ele também aborda as opções de compatibilidade que você pode definir e alterações de código que você pode fazer para executar o código em domínios de aplicativo de homogêneos.

Reduziu o Número de conjuntos de permissões possível

Domínios de aplicativo de homogêneos são parcial-conjunto de domínios de aplicativo de confiança que definem uma permissão de compartilhada para a execução de código. Em um domínio homogêneos aplicativo hospedado no ASP.NET 4, o código que pode ser carregado está associado um dos dois conjuntos de permissão . TantoCódigo é executado com confiança total (código doGAC sempre é executado em confiança total), ou o código é executado com o parcial-confiar o conjunto de permissão é definido pela atual trustLevelconfiguração. (For more information, see trustLevel elemento para securityPolicy (<>ASP\>.NETConfigurações Schema).)

Dica

ASP.NET 4 domínios de aplicativo padrão para confiança total.O comportamento homogêneo em ASP.NET 4 tem efeito somente após a trustLevel do elemento name atributo está definido como um valor diferente de Full.

Esse comportamento é diferente do parcial-confiar nos aplicativos em versões anteriores do ASP.NET. Em versões anteriores, você poderia criar vários permissão define que cada um tinham conceder diferentes conjuntos e associação de diferentes condições. Domínios de aplicativo de homogêneos foram introduzidos na .NET Framework 4 causa da dificuldade de lidar com cenários de misto permissão como essas. Era difícil criar conjuntos de permissão de vários que cada um tinha a diferentes níveis de permissões e, em seguida, para provar que os níveis de permissões diferentes foram realmente sendo aplicados, após levando em conta todas as condições sob as quais o código pode ser executado. Por exemplo, o código pode ser executado em reflexão, confiança total-, código pode ser executado em outro completo-código de confiança em nome de um parcial-o chamador de confiança e assim por diante. O conjunto de permissão tinha para levar em conta todas essas condições. Domínios de aplicativo de homogêneos simplificam consideravelmente as decisões de CAS, reduzindo os possíveis resultados. Código tem confiança total ou ela tem bem simples,-definido parcial-conjunto de permissões de confiança. Para ASP.NET, bem-na definição parcial-conjunto de permissão de confiança é o que se aplica a um ASP\ de ASP.NET nível de confiança.

Há um terceiro estado possível para o código que tenta carregar em um domínio de aplicativo de homogêneos. (Isso não é considerado separados permissão definida pelo CLR). O terceiro conjunto de permissão é o conjunto de permissão de vazio, que é definido como o Nothing permissão é definida em todos os ASP.NET parcial-confiar em arquivos de configuração . Tudo o código que é avaliada como o Nothingconjunto depermissão é considerado não carregável. Como resultado, qualquer tentativa de carregar assemblies que possuem o Nothing permissão definida em resultados homogêneos aplicativo um domínio um SecurityException exceção.

Somente ASP\ de ASP.NET parcial-Confiar diretiva se aplica

O parcial-conjunto de permissão de confiança de um domínio de aplicativo de homogêneos é estabelecida somente pelo host que é responsável pela criação do domínio de aplicativo . Em ASP.NET 4, isso significa que o parcial-conjunto de permissão de confiança é definido apenas pelo conteúdo de um parcial-arquivo de configuração de confiança é encontrado no subdiretório CONFIG do.NET Framework installation. Por padrão, ASP.NET informações sobre a diretiva ASP.NET 4 parcial-domínios de aplicativo de confiança não se sobrepõe a configurações de diretiva de autoridades de certificação de empresa, computadorou usuário .

Informações de diretiva de CAS globais (a política que os desenvolvedores anteriormente gerenciado usando ferramentas como Caspol. exe ou a ferramenta de configuração do MMC de Mscorcfg. msc) não tem qualquer influência na ASP.NET domínios de aplicativo de homogênea de 4. (Você pode configurar o ASP.NET para usar o modelo anterior de autoridades de certificação, no qual ASP.NET configurações interseção com a diretiva de empresa, computadore usuário . Esse comportamento herdado é explicado em uma seção posterior.)

A alteração mais óbvia é para o UNC-hospedado parcial- ASP.NET 4 aplicativos. Em versões anteriores, você tinha usar Caspol. exe para elevar os compartilhamentos UNC para confiança total para permitir ASP.NET parcial-confiar as diretivas sejam efetivadas. Isso era porque nas versões anteriores do ASP.NET, a computadordo padrão-diretiva de autoridades de certificação de nível CLR fizeram efeito primeiro. Como resultado, os aplicativos hospedado em UNC-tinham um conjunto restrito de permissão que estava associado à zonade Intranet. Porque ASP.NET 4 parcial-domínios de aplicativo estabelecer diretiva somente a partir de ASP.NET arquivos de diretiva, o local físico de umaplicativo de Webnão tem qualquer influência sobre o conjunto de permissão está associado a um parcial- aplicativode confiança.

Um efeito colateral desta alteração é ilustrado por um cenário onde um administrador quiser bloquear um servidor Web para baixo para negar permissões de executar para todos os códigos gerenciado por padrão e, em seguida, conceder direitos de executar para selecionado ASP.NET aplicativos. Em versões anteriores do ASP.NET, isso exigia uma solução conhecida de pouco-, conforme documentado no artigo KB Corrigir: Mensagem de erro ao tentar executar um ASP.NET Web2.0aplicativo se você não associar o grupo de códigos de My_Computer_Zone "confiança total" conjunto depermissão : "Server Application Unavailable. Em ASP.NET 4, um administrador pode bloquear para baixo grand executar permissões ou de um servidor Web para negar seguindo estas etapas:

1. Crie uma personalizada ASP.NET nível de confiança , cujo arquivo de diretiva mapeia todo o código para o Nothing permissão (um conjunto de permissão de vazio) e, em seguida, configurar todos os ASP.NET aplicativos para usar esse nível de confiança por padrão. (Isso é feito no arquivo raiz Web. config).

2. Associe seletivamente o indivíduo ASP.NET aplicativos com-criado em ou em níveis de confiança personalizado concedem permissões de executar (e qualquer outra permissão são necessários) para código gerenciado . computador-ampla aplicação, você pode atribuir seletivamente os níveis de confiança usando location elementos raizWeb. config arquivo.

Local e as convenções de nomenclatura para arquivos de diretiva de Confiar

O local e a convenção de nomenclatura dos arquivos de diretiva de CAS é o mesmo como nas versões anteriores do ASP.NET. Os níveis de confiança padrão são Full, High, Medium, Low, e Minimal. Os arquivos de diretivas que definem o parcial-conjuntos de permissão de confiança para High por Minimal localizado no subdiretório CONFIG do.NET diretório de instalação do Framework .

Os arquivos de diretiva são nomeados usando o seguinte padrão:

web_[trustlevelname]trust.config

Por exemplo, o parcial-confiar a permissão definida para Medium é de confiança no arquivo chamado web_mediumtrust.config.

Alterações nos arquivos de diretiva Confiar para ASP.NET 4

Na maior parte, as informações em ASP.NET arquivos de diretiva de CAS 4 é o mesmo que as informações encontradas nos arquivos de diretiva em versões anteriores. No entanto, houve pequenas adições para ambos .NET Framework 3.5 e .NET Framework 4 funcionalidade. O nome do parcial-conjunto de permissão de confiança que está associado um domínio de aplicativo de homogêneo é ASP.Net. Além disso, por padrão, todo o código que está localizado em qualquer umaplicativo Webdirectory estrutura ou na estrutura de diretório de código-geração é permissões concedidas nomeadas ASP.Netconjunto depermissão .

Há duas alterações de versões anteriores do parcial-confiar em arquivos de diretiva:

• No final de cada ASP\ de ASP.NET arquivo de diretiva de CAS 4, não existe mais um CodeGroup o elemento que mapeia os confiança total para uma chave de assinatura de Microsoft e a chavede assinatura de ECMA. Essas entradas foram removidas em ASP.NET 4 porque as entradas foram um legado de versões anteriores ao GAC não foi considerado sempre implicitamente ter confiança total.

• O Assertion parte o SecurityPermission atributo foi removido de todas as ASP.NET 4 arquivos de diretiva de CAS. Uma mudança fundamental feita pelo CLR na .NET Framework 4 é que parcial-código de confiança não pode declarar permissões. Isso significa parcial-código de confiança falhará mesmo que ele tenta declarar permissões já possui.

Escopo de Confiarparcial

Domínios de aplicativo de homogêneos significam que ASP.NET aplicativode 4-os limites de domínio são parcialmente confiável. Quando um aplicativo é executado em confiança parcial , segurança exige a resultam em um stack walk. Tudo o código na pilha é avaliado em relação as permissões solicitadas. Em domínios de aplicativo ASP.NET 3.5 e anteriores, era comum os caminhos de código para resultar em uma movimentação de pilha até o aplicativo-limites do domínio. Porque o aplicativo-limites de domínio em versões anteriores do ASP.NET 4 implicitamente foram confiança total, movimentações de pilha para alguns caminhos de código seriam bem-sucedida. Em ASP.NET qualquer stack walks que atinjam o aplicativo, de domínios de aplicativo de homogênea de 4-limite de domínio avaliará contra o parcial-conjunto de permissão de confiança que está atualmente em vigor para o domínio do aplicativo .

O fato de que o aplicativo-limite de domínio agora está se parcialmente confiável é a alteração de CAS mais comuns que geralmente exige que você altere total-código de confiança para torná-lo a trabalhar no ASP.NET 4. Por exemplo, o ASP.NET a equipe de desenvolvimento tinha que adicionar declarações de segurança de destino em vários caminhos de código interno para suprimir as exigências de segurança e impedir que a propagação o aplicativo-limites do domínio. Se a equipe de desenvolvimento não tinha feito isso, as tarefas básicas, como a compilação de página teria falhado porque a segurança exige para tais operações (por exemplo, permissões de arquivo e/S para compilação) falhará quando comparado a parcial-confiar a permissão definida para os níveis de confiança como Medium.

Há pontos de extensibilidade dentro de ASP.NET que pode levar à fully\ código totalmente confiável que está sendo carregado e executado quando somente ASP.NET é de código na pilha. Nesses cenários, apenas ASP.NET é o código na pilha inicialmente quando ASP.NET chamadas em um tipo personalizado que implementa a algum tipo de ponto de extensibilidade . Se o tipo personalizado totalmente confiável (o que deve ocorrer somente se o tipo é implantado no GAC), o resultado é que toda a pilha de chamadas consiste em código totalmente confiável . Em um domínio de aplicativo de homogêneos, se qualquer código em um tipo deextensibilidade totalmente confiávelaciona uma demanda de segurança , que exigem atingirá, eventualmente, o aplicativo-limites do domínio. Em seguida, falhará quando a verificação de segurança ocorre contra o parcial-conjunto de permissão de confiança.

Veja a seguir uma lista de alguns ASP.NETpontos deextensibilidade em que essa situação é possível:

• Personalizar manipulador HTTP. Um manipulador personalizado é invocado durante a execução do manipulador fase do pipeline.

• Personalizar módulo HTTP. Um personalizado módulo HTTP é invocado durante qualquer pipeline o módulo de eventos foi registrado.

• Provedores e construtores de expressões de compilaçãoPersonalizar . Esses tipos serão chamados pelo ASP.NET quando ele analisa e compila oconteúdo do executável, como arquivos. aspx.

• Gerenciador de função provedor. Um provedor de personalizado pode ser chamado durante a AuthorizeRequestoevento no pipeline.

• provedorde perfil. Um provedor de personalizado pode ser chamado para salvar dados de analisar automaticamente durante a EndRequest evento.

• provedorde monitoramento de integridade. Um provedor de personalizado pode ser chamados em momentos arbitrários para armazenar acumulada-monitoramento de integridade dados.

Um exemplo simples de um personalizado manipulador HTTP ilustra a alteração no comportamento de CAS. O exemplo a seguir, o código do manipulador tenta ler um arquivo de texto está localizado na raiz da unidade 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; } }

}

Se o manipulador for assinado, é marcado com o AllowPartiallyTrustedCallersAttributedeatributoe é implantado no GAC, o código terá êxito quando o manipulador é usado em um aplicativo de confiança média em ASP.NET 3.5 ou anterior. Confiança média é escolhida para este exemplo, porque na relação de confiança média, o parcial-conjunto de permissão de confiança permite a leitura/gravação e/S de arquivos somente a estruturado diretório do aplicativo. Código totalmente confiável, como, por exemplo, o manipulador de exemplo é capaz de acessar outros locais de arquivos de ASP.NET 3.5 e versões anteriores. Isso ocorre porque quando o manipulador é executado, somente o código de totalmente confiável é na pilha e o aplicativo-limite de domínio propriamente dito é totalmente confiável. Como resultado, a e/S de arquivo exigem da ReadAllText chamada implicitamente satisfeita por aplicativo-limite de domínio sendo na confiança total.

No entanto, se o mesmo código de manipulador é usado em uma relação de confiança média- ASP.NET 4 de aplicativo, ele falhará, pois a chamada para ReadAllText resulta em um arquivo por demanda de e/S para acesso de leitura ao arquivo de texto. O demanda de e/S de arquivo resultará em um stack walk que finalmente alcança o aplicativo-limites do domínio. Em ASP.NET 4, o aplicativo-limite de domínio está associada com o conjunto de permissão de confiança média, e esse conjunto de permissão não concede acesso à raiz da unidade C:\. Portanto, o demanda de e/S de arquivo falhará.

Para ASP.NET 4, você deverá suprimir a stack walk. Para fazer isso, use o SecurityAction.Assert atributo da FileIOPermission atributo o ProcessRequest método. O exemplo a seguir mostra como usar um FileIOPermission atributo para essa finalidade.

[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; } }

}

Você pode usar asserts declarativa (conforme mostrado no exemplo) ou através de programação de declarações. É uma melhor prática declarativamente declarar permissões mais estreito que são necessárias para obter um bloco de código em funcionamento. Embora possa parecer assim uma solução simples para adicionar irrestrito de segurança em todos os lugares, declara que abordagem não deve ser usada. As falhas de segurança causadas pelo novo comportamento de domínio homogêneos aplicativo onde projetada para solicitar a você para analisar completo-código de confiança e compreender quais operações privilegiadas completo-código de confiança requer. Depois você pode declarar seletivamente o conjunto mais estreito de permissões necessárias para re-ativar completo-código de confiança.

Configurando a ASP\ de ASP.NET 4 aplicativos para usar o ASP.NET modelo de CAS 2.0

É possível configurar o ASP.NET 4 aplicativos para usar o ASP.NET ASP\ 1.0 e ASP.NET de CAS 2.0 comportamentos. Em ASP.NET 4, o trust elemento fornece uma nova legacyCasModel atributo, que é definido como false por padrão. Configuração desse atributo como true configura uma ASP.NET 4 aplicativo para usar a maioria (embora não todos) a ASP.NET comportamento de CAS de versões anteriores.

Quando o LegacyCasModel atributo está definido como true, os seguintes comportamentos ocorrer:

• Limites de domínio de aplicativo de confiança parcial-usam a confiança total. Isso significa que cenários onde confiança total-, o código é executado com total apenas-código de confiança na pilha, você não precisará usar asserts para suprimir as demandas de segurança .

• Configurações de diretivas de CAS de empresa, computadore usuário que são definidos para o.NET Framework 4 se cruzam com ASP.NET diretiva CAS. Isso significa que todas as permissões personalizadas que são criadas usando o.Efeito Caspol. exe NET Framework 4 ou Mscorcfg. msc.

  Dica

  Porque a ferramenta os arquivos de diretiva de segurança de base e o Caspol. exe para o.NET Framework 4 estão em um diretório diferente daquelas para o.NET Framework 2.0, qualquer diretiva personalizada de segurança que foi criada para o.NET Framework 2.0 deve ser re-criado para o.NET Framework 4 usando o.NET Framework 4 versão do Caspol. exe.

• Você pode especificar vários personalizada permissão define que aplicar a assemblies diferentes.

As seguintes autoridades de certificação-relacionadas comportamentos não são alterados, mesmo no modo herdado de CAS:

• ASP. Ainda, os assemblies do NET 4 são marcados como APTCA condicional. (APTCA condicional é descrita neste tópico). APTCA condicional não pode ser revertido para o modo herdado, porque poderia envolver a remoção de AspNetHostingPermissionoatributo da maioria público ASP.NET 4 APIs. Não há nenhuma maneira eficiente para que essa permissão aplicar a ASP.NET APIs públicas quando estiver executando no modo herdado do CAS, mas não aplicar quando os assemblies são executados no novo modelo de CAS.

• Código de confiança parcial-não é mais permitido para declarar qualquer permissão. Código que anteriormente foi concedida confiança parcial poderia chamar o Assert método e declarar qualquer permissão que parcialcom êxito-código de confiança já foi concedido. No.NET Framework 4, independentemente do modelo de autoridades de certificação que está em vigor para um ASP.NET parcial, deaplicativo-declarações de código não é mais permitido para executar a segurança de confiança.

Para distinguir a permissão define que aplicar modelo legado CAS do conjunto único de permissão que se aplica no novo modelo de CAS, quando o LegacyCasModeldeatributo da trust elemento está definido como true, ASP.NET diretiva de CAS de leituras de 4 a partir de um conjunto diferente de parcial-confiar em arquivos de configuração . Para cada arquivo de diretiva de confiança que existe o ASP.NET criado-em níveis de confiança, duas versões do arquivo existe. ASP.NET lê uma versão para o novo modelo de CAS e ele lê a outra versão para o modelo herdado do CAS. Por exemplo, para confiança média, quando ASP.NET 4 é executado no modo herdado, ele lê o arquivo de diretiva é denominado legacy.web_mediumtrust.config. Observe que o início do nome do arquivo é "legado". ASP.NET 4 usa a mesma convenção de nomenclatura para todos os arquivos de diretiva de autoridades de certificação para o-criado em ASP.NET níveis de confiança. A principal diferença entre herdados e não-arquivos de diretiva de CAS herdados é que os arquivos legados incluem o CodeGroup definição que faz referência a Microsoft a assinatura de chave e a chavede assinatura do ECMA.

Porque você pode configurar um aplicativo para usar o antigo modelo de CAS, para aplicativos existentes, talvez você queira definir o LegacyCasModel opção de true e, portanto, evite fazer alterações. No entanto, é importante entender que a opção de legado existe principalmente para facilitar a transição de aplicativos existentes para o ASP.NET 4 modelo de CAS. No futuro, o CLR e o ASP.NET equipes enfatizará a criação e a codificação com o novo modelo de CAS.

Silverlight 2 foi a primeira de recurso área da.NET Framework que são movidos para o novo modelo. A meta para o.NET Framework é mover todos os área de trabalho e servidores parcial-cenários para executar o novo modelo de CAS de confiança. Como resultado, recomendamos que você investe no esforço para re-habilitar os aplicativos para trabalhar no CAS modelar. Da mesma forma, os administradores que anteriormente dependiam Caspol. exe e Mscorcfg. msc devem depender em vez disso, personalizando o ASP.NET parcial-atribuições de permissão e de arquivos de diretiva de confiança.

Personalizando a permissão definida atribuição em que o ASP.NET 4 modelo de CAS

Embora ASP.NET os domínios de aplicativo de homogêneos 4 restringir o código para ambos confiança total ou a ASP.NET parcial-conjunto de permissão , desenvolvedores e administradores podem influenciar o processo pelo qual um conjunto de permissão está associado um assemblyde confiança. As seguintes abordagens permitem personalizar o processo de associar um conjunto de permissão um pedaço de execução de código:

• Você pode personalizar o parcial-arquivo de diretiva de confiança para um nível de confiançade individuais. (Essa abordagem era possível nas versões anteriores do ASP.NET.)

• Você pode configurar estaticamente ASP.NET 4 completo de assemblies de confiança de-.

• Você pode usar o ASP.NET 4 HostSecurityPolicyResolver tipo para acessar a funcionalidade do CLR HostSecurityManageraclasse em uma maneira restrita.

Os dois primeiros essas abordagens permitem fazer personalizações declarativamente e a terceira opção lhe permite fazer personalizações no código.

Personalizando os arquivos de diretiva para um nível de Confiar

A primeira abordagem à modificação de ASP.NET parcial-arquivos de diretiva de confiança é o mesmo como nas versões anteriores do ASP.NET: Você pode modificar o conjunto de permissões do ASP.NET chamado conjunto de permissão . Você também pode adicionar mais CodeGroup definições que tenham condições de associação de personalizado. Como observado anteriormente, novas personalizações de autoridades de certificação devem ser feitas no parcial-confiar em arquivos de diretiva como Web_mediumtrust. config. Os arquivos que começam com "legado" em seus arquivos de nomes são analisados em usados quando o trust elemento LegacyCasModel atributo está definido como true.

Para ASP.NET 4, tudo personalizado CodeGroup definições devem mapa para uma das três conjuntos de permissão de possíveis: FullTrust, ASP.Net (ou seja, o parcial-conjunto de permissão de confiança), ou Nothing. Porque ASP.NET 4 parcial-domínios de aplicativo de confiança são homogêneos, por padrão, as entradas de diretiva personalizada devem ser avaliada como um conjunto restrito de conjuntos de permissão . Apesar de parecer que você pode definir conjuntos de permissão diferente de nomeado quando você usa o ASP.NET 4 modelo de CAS, qualquer código que é avaliada como uma permissão diferente de definir FullTrust, ASP.Net, ou Nothing resultará em um tempo de execução- SecurityException exceção. Isso indica que o CLR não reconheceu o conjunto de permissão de avaliado.

O conjunto depermissãoFullTrustindica que o código seja executado em confiança total. O ASP.Netconjunto depermissão é o nome parcial-conjunto de permissão que é normalmente usado para parcialde confiança-domínios de aplicativo de confiança. Conforme descrito anteriormente, Nothing é não um conjunto de permissão de real reconhecido pelo CLR; em vez disso, ele é o conjunto de permissão de vazio. Se o CLR determina que um assembly está associado um conjunto de permissão de vazio, o CLR lança um SecurityException exceçãoe o CLR fará com que não carregar o assembly.

Além disso, o ASP.NET 4 lhe permite alterar o nome da ASP.Netpermissão definida usando o PermissionSetNameoatributo da trust elemento. Você pode definir um nome diferente para o PermissionSetNamedeatributo. Em tempo de execução, ASP.NET 4 irá procurar o parcial-arquivo de diretiva de confiança para um PermissionSet o elemento de mesmo nome. Que conjunto de permissão nomeado será usado como o parcial-confiar a permissão definida para um domínio de aplicativo de homogêneos. É improvável que você teria que fazer isso. No entanto, a capacidade de alterar o nome do parcial- permissão de confiança definido como algo diferente de ASP.Net foi adicionado acomodar ambientes de hospedagem , como o SharePoint definir sua própria chamada de permissão definido como uma entidade distinta de ASP.NET padrão conjunto de permissão . (Lembre-se de que no novo modelo de CAS, ele não é mais possível ter vários conjuntos de permissão de nomeadas que definem parcial-permissões de confiança.) Embora você possa alterar o nome do parcial- permissão de confiança definido como algo diferente de ASP.Net, ainda pode haver apenas um parcial-confiar a permissão definida em vigor para um aplicativo.

Especificando os Assemblies que serão concedidos aConfiar Completo

A personalização de diretiva declarativa a segunda é nova no ASP.NET 4 e permite que você explicitamente estabelecer uma lista de identidades de assembly sempre serão concedidas confiança total. O securityPolicyconfiguração contém um novo filho fullTrustAssembliesseção deconfiguração . O FullTrustAssembliesSection seção é um padrão coleção que oferece suporte para adicionar, remover e desmarque as operações, e onde você pode especificar um ou mais identidades do assembly que serão concedidas a confiança total em tempo de execução. A exemplo a seguir mostra um fullTrustAssembliesseção deconfiguração .

<system.web>

<securityPolicy>

<fullTrustAssemblies>

<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>

Cada entrada do fullTrustAssemblies elemento identifica um assembly por seu nome de assembly e aversãodo assemblye por uma seqüência de caracteres-320 é a representação hexadecimal do caractere a metade pública da chavede assinatura.

Dica

No futuro, o novo.Assemblies do NET Framework podem usar chaves de assinatura de bit de 2048-.Se forem lançados novos assemblies que usam chaves de assinatura de bit de 2048-, que resultará em um 576 seqüências de-caracteres hexadecimais.

Nãolocal doassembly é especificado na definição. Cabe a individuais de hospedagemdoambiente (como ASP.NET 4) para localizar e carregar assemblies. Se um assembly de carregado correspondem às informações contidas em um do add elementos no fullTrustAssemblies, o assembly é concedido a confiança total.

Você deve usar fullTrustAssemblies para assemblies que não são implantados no GAC, mas que têm como objetivo sempre é executado em confiança total. Porque os assemblies listados na fullTrustAssemblies podem ser personalizados em qualquer ponto da hierarquia de configuração (do arquivo raiz Web. config individuais de aplicativo-nível de arquivos do Web. config), usando essa configuração é mais fácil e flexível para conceder confiança total que o uso de uma condição de associação e o grupo de códigos em um parcial-confiar no arquivo de diretiva. Você pode personalizar o fullTrustAssemblies a lista de aplicativos individuais, especificando informações diferentes para diferentes aplicativos. Isso pode ser feito tanto no aplicativo-nível de arquivos do Web. config, ou no arquivo raiz Web. config usando location elementos.

O conjunto de full-assemblies de confiança é estabelecido imediatamente no momento um parcial-domínio de aplicativo de confiança é criada. Como resultado, se um parcial-arquivo de diretiva de confiança inclui informações que resulta em uma concessão diferente definida para um assembly que está listado na fullTrustAssemblies elemento, as informações serão ignoradas e o assembly é concedido a confiança total.

Personalizar permissões programaticamente

Também programaticamente, você pode alterar a associação de uma permissão definida para um assembly , criando uma implementação personalizada da ASP.NET 4 HostSecurityPolicyResolver tipo. Em tempo de execução, ASP.NET 4 usa sua própria implementação do CLR HostSecurityManager tipo. A HostSecurityManager objeto é chamado pelo CLR , sempre que um assembly é carregado. Uma das funções da HostSecurityManageré depropriedade para retornar um PermissionSetoobjeto que devem ser associadas a um assembly de especificado e um conjunto de evidência. ASP.NET 4 permite a você personalizar esse processo , chamando um personalizado HostSecurityPolicyResolver objeto sempre que o CLR pede ASP.NET 4 para uma permissão-defina decisão.

Você pode configurar um personalizado HostSecurityPolicyResolverobjeto usando o HostSecurityPolicyResolverTypedeatributo da trust elemento. Se ASP.NET 4 determina que um personalizado HostSecurityPolicyResolver objeto é configurado para um aplicativo, ele chama o ResolvePolicy método o resolvedor personalizado sempre que o CLR solicita uma permissão-defina decisão. No entanto, diferentemente de um HostSecurityManager objeto, um HostSecurityPolicyResolver objeto pode retornar apenas um conjunto restrito de decisões possíveis para ASP.NET 4. O ResolvePolicyvalor retornado dométododeve ser um dos seguintes valores da HostSecurityPolicyResultsenumeração:

• DefaultPolicy. Isso especifica que ASP.NET 4 deve usar sua própria lógica para determinar apropriada permissão definida para o assembly. Você deve retornar DefaultPolicy para assemblies onde você não deseja que o HostSecurityPolicyResolveroobjeto para tomar uma decisão sobre o conjunto de permissão . Retornando DefaultPolicy faz com que o ASP.NET para determinar um assembly permissão conceder o conjunto com base nos grupos de código declarativo e as condições de associação são definidas no parcial-arquivo de diretiva de confiança atual ASP.NET nível de confiança.

• FullTrust. O assembly deve ser concedido a confiança total.

• AppDomainTrust. O assembly deve ser concedido a parcial-conjunto de permissão está associado ao domínio do aplicativo de confiança. Geralmente, isso significa que o assembly serão concedidas as permissões que são definidas no nomeada ASP.Netconjunto depermissão .

• None. A permissão definida para o assembly será definido como o Nothing o conjunto de permissões, que é um

Porque a base de HostSecurityPolicyResolverclasse tem uma demanda de herança irrestrita segurançapermissãoe um personalizado HostSecurityPolicyResolverobjeto deve ser carregável sem a necessidade de outro HostSecurityPolicyResolveroobjeto para estabelecer a confiança total, concretas de implementações de um HostSecurityPolicyResolverclasse sempre devem ser assinados e implantados no GAC.

O exemplo a seguir mostra um personalizado HostSecurityPolicyResolver objeto que concede confiança total para todos os assemblies são carregados a partir de um diretório específico. Isso pode ser um cenário para organizações que adicionar assemblies compilados em um local específico no disco (não no GAC) e de que deseja que todos os arquivos desse local para executar automaticamente com confiança total. Em ordem para ASP.NET aplicativos para poder carregar assemblies de fora a estrutura do diretório de uma Web aplicativo, você deve adicionar explícito do assembly-redirecionamentos associar o assembly identidades locais de disco físico diferente de ligação.

[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 condicional

Nas versões do.NET Framework anterior à versão 4, muitos assemblies totalmente confiável (incluindo ASP.NET assemblies) foram marcados com o AllowPartiallyTrustedCallersAttribute (APTCA) atributo. Este atributo dá parcial-acesso de chamadores de confiança para tipos públicos e membros que são definidos em assemblies que são marcados dessa forma. No.NET Framework 4, o CLR inclui uma variação do APTCA é conhecido como APTCA condicional. (A notação abreviada para APTCA condicional é APTCA de c-). APTCA condicional permite que os assemblies que são marcados com o atributo do APTCA para manter as características APTCA em somente em determinados ambientes hospedados. Como resultado, o APTCA condicional facilita para ASP.NET 4 para o controle no exatamente quais parcial-confiar host ambientes parcial-chamadores de confiança será capazes de ASP.NET 4 APIs.

Como condicional funciona APTCA

Ambos os parcial-ambientes de host de confiança e totalmente confiável de módulos (assemblies) desempenha um papel fazendo o trabalho APTCA condicional. Ambientes de host de confiança parcial-onde os conjuntos de permissões são importantes podem fornecer uma lista de módulos (assemblies) deve ter sempre a sua configuração de APTCA respeitadas ao CLR . Assemblies totalmente confiáveis que devem ter suas características APTCA habilitadas apenas em certos ambientes de host indicam isso usando a variação abaixo do nível do assembly APTCA atributo:

[assembly: AllowPartiallyTrustedCallers(PartialTrustVisibilityLevel=NotVisibleByDefault)]

Em tempo de execução quando o CLR é solicitado a carregar um assembly está marcado como condicionalmente APTCA, o CLR verificará a lista de válido condicional-assemblies APTCA, fornecidos peloambientede host. Se o assembly está na lista, o CLR tratará todo o código exposto publicamente no assembly como se o assembly foi marcado com o APTCA de atributo em versões anteriores do.NET Framework.

Se uma condicional APTCA assembly não estiver na lista de hostdeambientede módulos (assemblies) deve ser tratado como o APTCA, o assembly ainda é carregado, mas sem suas características APTCA. A disponibilidade real de APIs públicas para parcial-código de confiança do usuário em um assembly irá variar dependendo se o assembly é 100% segurança transparente ou não. Ou seja, ele depende se o assembly está marcado com um assembly-nível SecurityTransparentAttribute atributo. (De segurança de transparência em ASP.NET 4 é descrita em uma seção posterior deste tópico.)

Em resumo, as APIs públicas na ASP.NET 4 pode comportar-se em uma das seguintes maneiras:

• Para mais de ASP.NET assemblies, todas as APIs públicas indisponíveis para parcial-chamadores de confiança. Na verdade, isso impede que a maioria das APIs públicas na ASP.NET 4 sejam usadas em qualquer parcial-ambientes diferentes de aplicativos Web de confiança.

• Algumas poucas ASP.NET assemblies que são marcados como 100% segurança transparente são ainda podem ser chamados de parcial-chamadores de confiança. No entanto, se eventualmente alcancem os caminhos de código nesses assemblies para o restante da ASP.NET codebase, as chamadas falharem. O resultado é o mesmo comportamento como nas versões anteriores do ASP.NET lançamentos, com a diferença mínima que chama APIs em ASP.NET 4 assemblies de progresso serão ainda mais antes de falhar.

  Observe o seguinte sobre assemblies que são marcados segurança transparente:

  • Há apenas dois ASP.NET assemblies que são marcados segurança transparente no nível do assembly : Sistema.Web.DynamicData.dll e o sistema.Web.RegularExpressions.dll.

  • Sistema.Web.Routing.dll não é considerado 100% segurança transparente na ASP.NET 4 porque os tipos definidos no assembly em versões anteriores do ASP.NET foram movidas para o sistema.. Dll daWeb. Na verdade, em ASP.NET 4, de sistema.Web.Routing.dll é um metadados- assembly.

Em ASP.NET 4, a variação de atributo APTCA condicional encontra-se sobre os seguintes módulos:

• Sistema.. Dll daWeb

• Sistema.Web.Extensions.dll

• Sistema.Web.DynamicData.dll

• Sistema.Web.DataVisualization.dll

• System.ComponentModel.DataAnnotations.dll

• Sistema.Web.ApplicationServices.dll. Este assembly é novo no ASP.NET 4.

• Sistema.Web.Abstractions.dll. Tipos neste assembly foram movidos para o sistema.Web. dll para ASP.NET 4.

• Sistema.Web.Routing.dll. Tipos neste assembly foram movidos para o sistema.Web. dll para ASP.NET 4.

Condicional APTCA versus ASP.NET Atributosde permissão de hospedagem.

Condicional APTCA tornou prático remover o AspNetHostingPermissionoatributo de 99% das APIs públicas no ASP.NET 4. O AspNetHostingPermission atributo ainda é usado em alguns locais na ASP.NET 4, mas somente naqueles lugares onde a permissãoda intenção realmente faz sentido. Todos os outros locais, os dois seguintes usos de AspNetHostingPermission atributo desapareceram:

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

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

Essas definições de permissão foram usadas nas versões anteriores do ASP.NET para evitar ASP.NET assemblies sejam carregados no não-Web parcial-ambientes de confiança. O ambiente de maior preocupação era parcialmente confiávelo controlesgerenciado e aplicativos gerenciado que estavam sendo carregados em navegadores, como o Microsoft Internet Explorer e Mozilla Firefox. Usando o APTCA condicional, efetivamente as mesmas proteções são aplicadas porque ClickOnce aplicativos e controles gerenciado do baseado em navegador-define qualquer condicional-os assemblies APTCA para tratamento como APTCA completo.

Personalizando o ASP.NET 4 condicional APTCA Lista

Como mencionado anteriormente, os ambientes de host de individuais podem fornecer para o CLR uma lista de condicional-assemblies APTCA, cujas características APTCA devem ser respeitadas. ASP.NET 4 fornece uma lista embutido em código para o CLR que contém todos os ASP.NET 4 assemblies. Se ASP.NET 4 não fez isso, aplicativos Web falhará imediatamente quando a primeira linha de ASP.NET código interno tentou executar em um parcial-domínio de aplicativo de confiança.

No.NET Framework 4, APTCA condicional é um novo conceito de CAS que ainda não foi implementado em outras partes da.NET Framework. Portanto, é provável que as futuras versões do.NET Framework incluirá mais condicionais assemblies APTCA-. Além disso, como você a respeito de APTCA condicional e usá-lo para seu próprio completo-assemblies de confiança, o conjunto de condicional-assemblies APTCA crescerá. Porque é impossível que ASP.NET 4 saber antecipadamente todos os possíveis condicional-assemblies APTCA, ASP.NET 4 inclui uma seção de configuração onde condicional assemblies APTCA de-podem ser adicionados.

O existente securityPolicy seção tem uma seção deconfiguração do filhochamada partialTrustVisibleAssemblies. Este é um padrão coleção oferece suporte para adicionar, remover e limpar as operações e onde você pode especificar um ou mais identidades do assembly que devem ser tratados como APTCA (se eles também são marcados para APTCA condicional). A exemplo a seguir mostra um partialTrustVisibleAssemblies seção.

<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>

Cada entrada do partialTrustVisibleAssemblies seção identifica um assembly por nome de assembly . Cada entrada também é identificado por uma seqüência de caracteres-320 (por exemplo, 0x03FA4D...) ou seja a representação hexadecimal do caractere a metade pública da assinatura chave que é usada em condicional-APTCA atribuído assembly. Não é necessário especificar umatributode versão. Somente o nome de assembly e o token de chave de pública são necessários pelo CLR.

Uma implicação importante de desempenho quando você habilita uma condicional APTCA assembly é que você deve habilitar também o fechamento transitivo de condicional-assemblies APTCA. Por exemplo, se condicional-ATPCA assembly a depende do APTCA assembly b e, por sua vez depende do APTCA assembly b condicional-ATPCA assembly C, quando você habilita o ATPCA condicional para um, você deve habilitar também APTCA condicional para c. Caso contrário, o desempenho do seu aplicativo pode ser afetada. Por exemplo, o compartilhamento de código e as imagens NGen será desabilitado se o total condicional-o fechamento ATPCA não está habilitado.

Como não afeta o APTCA condicional-aplicativos deConfiar parcial doWeb-

Em versões do ASP.NET anterior de ASP.NET 4, alguns tipos e namespaces não foram marcados com o AspNetHostingPermission atributo. Isso permitiu que esses tipos de ser chamado a partir de ASP\ de não-ASP.NET parcial-confiar em ambientes como, por exemplo, aplicativos de ClickOnce . Os tipos e namespaces que poderia ser chamado dessa maneira foram o seguinte:

• Digita o System.Web.ClientServices namespace.

• Digita o System.Web.ClientServices.Providers namespace.

• O HttpUtility tipo.

O System.Web.ClientServices tipos não podem ser utilizados em.NET Framework 4 parcial-confiar em ambientes como, por exemplo, ClickOnce. Porque o assembly contendoWeb.Extensions.dll) é um ASP.NET 4 assembly que está marcado para APTCA condicional e porque ClickOnce não permitir APTCA qualquer condicional-assemblies APTCA, nenhum dos tipos de serviços de cliente são chamados de parcial- ClickOnce aplicativos de confiança.

Há várias razões para esse comportamento. Primeiro, o.NET Framework 4 foi dividida em um cliente e em um SKU estendido e a suposição é que muitos aplicativos de ClickOnce serão destino o SKU do cliente. Ele exigiria um esforço considerável para refatorar ASP.NET tipos de serviços de cliente para o cliente SKU.

Segundo, é complexo para determinar como o cliente para refatorar tipos mantendo condicional necessária-limites APTCA. Portanto, o.NET Framework 4, os tipos de serviços de cliente estão disponíveis apenas para nãoASP.NET completo de ambientes de confiança de-, incluindo aplicativos de ClickOnce configurados para serem executados em confiança total usando o extended.SKU do NET Framework 4.

Para o HttpUtility tipo, o efeito de APTCA condicional depende em quais métodos você estava usando, como mostrado nas seguintes situações:

• Código de confiança parcial-foi chamada ou o HtmlEncode ou HtmlDecodeométodo da WebUtilityclasse. O o tipo deWebUtility contém o ASP.NETHTMLdecodificação e decodificação implementações, mas eles foram refatorados e movidos para a System.Netnamespace e que está contida em System. dll. Porque a dll está disponível em todos os parcial-confiar em ambientes de host , não há nenhum problema com os métodos da tipo deWebUtility nãoASP.NETparcial-confiar em aplicativos.

• Código de confiança parcial-foi chamar qualquer um dos outros métodos da WebUtility classe. Nesse caso, o mesmo emitir conforme descrito anteriormente para os serviços de cliente aplica a tipos. Ou seja, WebUtility só está disponível para nãoASP.NET total-chamadores de confiança na.NET Framework 4.

Transparência da segurança em ASP.NET 4

transparência da segurança permite que você indicar para o CLR se um bloco de código nunca realizará uma segurança-operação sensível. Código Transparent pode nunca declarar permissões, satisfazer a demanda de link, contêm o código, chamar código nativo ou chamada de segurança-código critical. Isso é verdadeiro independentemente de código transparente totalmente confiável (por exemplo, no GAC) ou parcialmente confiável.

transparência da segurança é um recurso poderoso para.NET Framework de recursos como o ASP.NET. Ele permite que ASP.NET para indicar ao CLR que partes de ASP.NET código nunca irá declarar permissões e que o código nunca implementar ou realize operações confidenciais de segurança , como PInvoke chamadas para código nativo . Isso permite.NET Framework a fim de reduzir a exposição de segurança de um grande número de APIs internas e públicas embora substancialmente.Código de Framework NET está em totalmente confiável GAC.

transparência da segurança pode aplicar a um assembly de inteiro ou apenas um subconjunto do código no assembly. Embora um assembly de toda a marcação detransparência da segurançaé o ideal caso, alguns códigos na.Código do NET Framework tem uma necessidade legítima para realizar a segurança-tarefas confidenciais. Assemblies que contêm a 100% de segurança- códigotransparente marcados usando um assembly-nível SecurityTransparentAttribute atributo.

Os assemblies que contêm uma mistura de transparente e não - códigotransparente não possuem um assembly-nível de transparênciadeatributo. Em vez disso, classes individuais no assembly podem ser marcados, usando o SecuritySafeCriticalAttributel atributo ou o SecurityCriticalAttribute atributo.

O comportamento das classes unattributed é complexo. No entanto, em termos simples, tipos de unattributed em ASP.NET 4 assemblies que adotaram o novo modelo de transparência são considerados segurança transparente. Tipos de ASP.NET 4 assemblies que não são atribuídos e não adotaram o novo modelo de transparência são considerados de segurança-safe-crítico.

Transparência da segurança em prática e o conjunto de regras de segurança

Porque grande parte do que o ASP.NET é de 4 da base de código no sistema.Web. dll, não foi prático para converter todos os ASP.NET código 4 para o novo modelo de transparência . Em vez disso, ASP.NET código 4 pode ser particionado nas seguintes categorias:

• Código que não adotar o novo modelo transparência , que inclui o código nos assemblies do seguintes:

  • Sistema.. Dll daWeb

  • Sistema.Web.ApplicationServices.dll

  • Sistema.Web.Mobile.dll. Os tipos neste assembly foram marcados como obsoleto em ASP.NET 4. Apesar do assembly ainda existe, a expectativa é que você irá parar de usar os tipos neste assembly ao longo do tempo.

• OCódigo que estava usa o novo modelo transparência , que inclui o código nos assemblies do seguintes:

  • Sistema.Web.Extensions.dll

  • Sistema.Web.DynamicData.dll (100% segurança transparente)

  • Sistema.Web.RegularExpressions.dll (100% segurança transparente)

  • System.ComponentModel.DataAnnotations.dll

  • Sistema.Web.DataVisualization.dll

• Assemblies que são metadados e cujos tipos foram movidos para um ASP\ de ASP.NET assembly, incluindo os assemblies a seguir:

  • Sistema.Web.Abstractions.dll. Os tipos que estavam neste assembly em versões anteriores do ASP.NET foram movidos para o sistema.. Dll daWeb. Como resultado, Sytem.Web.Abstractions.dll é um metadados-somente assembly no ASP.NET 4.

  • Sistema.Web.Routing.dll. Os tipos que estavam neste assembly em versões anteriores do ASP.NET foram movidos para o sistema.. Dll daWeb. Como resultado, System.Web.Routing.dll é um metadados-somente assembly no ASP.NET 4.

No.NET Framework 4, o CLR introduziu um novo conceito que é conhecido como a regra de segurança definida. Há dois níveis de SecurityRuleSet as configurações, o nível um e o nível dois. O SecurityRuleSetaconfiguração para todos os tipos é especificado usando o SecurityRulesAttributeassembly-nível de atributo. ASP.NET 4 assemblies que adotaram o novo modelo de transparência são marcados usando o seguinte assembly-nível de atributo:

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

ASP.NET 4 assemblies que usam a transparência do modelam da.NET Framework 2.0 (que para ASP.NET significa sem transparência, pois ASP.NET antes para ASP.NET 4 nunca usou os conceitos de transparência ) são marcadas usando o seguinte assembly-nível de atributo:

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

Para ASP.NET assemblies que adotaram o novo modelo transparência (e os tipos públicos em assemblies), a maioria do código é considerada segurança transparente. Uma pequena quantidade de código nesses assemblies executa segurança-operações confidenciais e que o código está marcado como código crítico ou crítica de segurança de-.

Para ASP.NET assemblies não adotar o novo modelo de transparência (deixando aside obsoleto ou tipo de-assemblies redirecionados) a todas as APIs públicas podem ser chamadas de parcial-confiar em código de usuário e pode executar internamente segurança-operações confidenciais. A combinação de em aberto acesso parcial-confiar chamadores e o potencial de segurança-operações confidenciais significa que ASP\ de ASP.NET código 4 requer um grau maior de fiscalização. No entanto, porque a maioria dos ASP.NET recursos são implementados em assemblies mais recentes como o sistema.Web.Extensions.dll e o sistema.Web.DynamicData.dll, ou em versões separadas, como ASP.NET MVC, a maioria dos ASP.NET código de segurança transparente e, portanto, é mais seguro do que o código mais antigo por padrão.

Por padrão, o CLR trata as APIs públicas de todos os ASP.NET 4 assemblies que são marcados como SecurityRuleSet.Level1 como crítica safe-(que é, como o equivalente ao que está sendo marcado com o SecuritySafeCriticalAttributeatributo), contanto que oambiente de hospedagemrespeita o atributode APTCA. Se o APTCA não é respeitada, o CLR aciona uma demanda de link para confiança total, que falhará quando não houver qualquer parcial-código do usuário na pilha de confiança. Em outras palavras, quando APTCA não é respeitada para um ASP.NET assembly que está marcado como SecurityRuleSet.Level1, você vê o mesmo comportamento como nas versões anteriores do.NET Framework quando parcial-confiança código tentou chamar completo-de confiança assembly não foi marcado com o atributode APTCA.

Por padrão, o CLR trata a API pública de todos os ASP.NET 4 assemblies que são marcados como SecurityRuleSet.Level2 como segurançatransparente (ou seja, o equivalente ao que está sendo atribuído com SecurityTransparentAttribute), contanto que oambiente de hospedagemrespeita o atributode APTCA. Caso contrário, é definido o seguinte comportamento:

• Se o APTCA não é respeitada e uma assembly que está marcado como Level2 não é 100% segurança transparente, o CLR trata a área de superfície pública como sendo de segurança críticos. Como resultado, qualquer parcial-chamadores de confiança que tentam usar a área de superfície pública provavelmente falhará com um MethodAccessException, TypeAccessException, ou FieldAccessException exceção.

• Se o APTCA não é respeitada e uma assembly que está marcado como Level2 é 100% segurança transparente, parcial-chamadores de confiança será capazes de chamar qualquer uma das APIs públicas com êxito no assembly. Na prática, isso significa que uma SecurityException exceção ocorre posteriormente no caminho da chamada quando o código a 100% de segurança-transparente assembly eventualmente chama em um nível-1 ASP.NET assembly ou um nível de-2 ASP.NET assembly que não é 100% segurança transparente.

ASP\ de ASP.NET compilação

Saída criada pelo ASP.NET sistema de compilação também é afetado pela ASP.NET 4 adoção tanto o novo modelo de CAS e do novo modelo detransparência da segurança. Isso inclui itens como assemblies de página, assemblies pré-compilados e os resultados compilados do diretório App_Code. O sistema de compilação varia de seu comportamento com base na configuração da LegacyCasModeldeatributo da trust elemento.

A tabela a seguir descreve como dinamicamente objetos compilados são marcados em ambas as CAS modelo legado e no modelo mais recente do CAS.

configuraçãodo atributolegacyCasModel	Site deWeb nível de confiança	Atributos aplicados a assemblies compilados
False(novo modelo de CAS)	Full trust	SecurityRules(SecurityRuleSet.Level2)
	Confiança alto ou baixo	SecurityRules(SecurityRuleSet.Level2)
SecurityRules(SecurityRuleSet.Level2)
True(modelo antigo de CAS)	Full trust	SecurityRules(SecurityRuleSet.Level1)
	Confiança alto ou baixo	SecurityRules(SecurityRuleSet.Level1)

Porque o ASP.NET varia de sistema de compilação 4 seu comportamento com base nas configurações da LegacyCasModel atributo da trust elemento, pode haver restrições sobre como compartilhar o código compilado entre diferentes parcial- ASP.NET aplicativos 4. Em geral, você não verá nenhuma alteração no comportamento do aplicativo . No entanto, em alguns cenários, compilado artefatos que foram criados a partir de um parcial-confiança aplicativo tem o LegacyCasModel atributo definido como false (ou seja, que usa o novo modelo de CAS) não funcionam como esperado quando eles são usados com outros aplicativos. Como resultado, alguns cenários (por exemplo, um compartilhada biblioteca de compilado. ascx controles assinados, ATPCA-atribuídos e implantados no GAC), talvez você precise explicitamente aplicar atributos de seguros-e crítico para alguns dos seus códigos quando a biblioteca é marcado com Level2.

Consulte também

Outros recursos

Segurança de aplicativos ASP.NET em ambientes hospedados